Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

fynda пишет:
> И там и там есть свои проблемы с эффективностью. Но их сейчас усиленно
> фиксят, и к v3 вроде обещают сделать архитектуру, избавленную от
> "детских болезней". Так что с 10 годами Yo явно погорячился.

Вот, поэтому я в FB и не верю. Если их еще сейчас фиксят, зачем мне
это надо ? Я лучше буду использовать то, что не надо было фиксить,
что было сделано изначально правильно.

Posted via ActualForum NNTP Server 1.4

21 фев 08, 15:29    [5323323]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Tauler
Мое мнение - для мелкого и среднего бизнеса Файрберда вполне достаточно, он бесплатный, легкий в освоении и администрировании.


Мое мнение, для мелкого и среднего бизнеса, вполне достаточно SQL Server 2005 Express Edition, который "бесплатный, легкий в освоении и администрировании". И не надо потом будет иметь головняков (при расте бизнеса) о поиске СУБД на замену птичке.
21 фев 08, 15:34    [5323365]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
fynda
Member

Откуда: Пенза
Сообщений: 2785

MasterZiv пишет:

> Вот, поэтому я в FB и не верю. Если их еще сейчас фиксят, зачем мне
> это надо ? Я лучше буду использовать то, что не надо было фиксить,
> что было сделано изначально правильно.

Список живых СУБД, в который ничего не фиксится - в студию!

Posted via ActualForum NNTP Server 1.4

21 фев 08, 16:05    [5323720]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

fynda wrote:
> Список живых СУБД, в который ничего не фиксится - в студию!
Критерии для "живых"?

Posted via ActualForum NNTP Server 1.4

21 фев 08, 16:17    [5323838]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
fynda
Member

Откуда: Пенза
Сообщений: 2785

locky пишет:

> > Список живых СУБД, в который ничего не фиксится - в студию!
> Критерии для "живых"?

С незамороженой разработкой

Posted via ActualForum NNTP Server 1.4

21 фев 08, 16:24    [5323901]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

fynda wrote:
> С незамороженой разработкой
Sybase :)
11,9,2, 12,х - не фиксятся, вроде :)
хотя сам по себе сайбейз - разрабатывается и поныне.

Posted via ActualForum NNTP Server 1.4

21 фев 08, 16:34    [5323990]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
fynda

И там и там есть свои проблемы с эффективностью. Но их сейчас усиленно
фиксят, и к v3 вроде обещают сделать архитектуру, избавленную от
"детских болезней". Так что с 10 годами Yo явно погорячился.
Posted via ActualForum NNTP Server 1.4

прежде чем фиксить "детские болезни" мое глубокое имхо нужно пофиксить "особености". что за особености тут уже не раз пережевывалось, у интербейзников неадекватная реакция на них, так, что не будем будить буйных - перейдем к 10 годам:
SMP в Superserver обещали еще лет пять назад воткнуть, проэкт Vulcan благополучно заканселили, типа подождем 3.0 и назначили Q3 2006 как дата выхода FB3, сегодня у нас 2008 ... т.е. в FB может быть появится то, что к примеру у MySQL в этой области (SMP) было отлажено еще времена 4.x (при этом до сих пор вылазят проблемы на более чем 4х процессорах) ... дальше если начнем копать в алгоритмах вытеснения кэша, async i/o, read ahead и выпрямление оптимизатора хотя бы до уровня сегоднешнего MySQL то как раз лет 10 и займет (судя по сегодняшним темпам развития FB). ну, а чтоб тягатся с лидерами и быть хотя бы с постгресом одной весовой категории еще туча фич понадобится ...
21 фев 08, 16:45    [5324109]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

fynda пишет:
> Список живых СУБД, в который ничего не фиксится - в студию!

Список живых СУБД, в которых есть баги в многопоточности в студию !

Posted via ActualForum NNTP Server 1.4

21 фев 08, 19:51    [5325277]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:
> прежде чем фиксить "детские болезни" мое глубокое имхо нужно пофиксить
> "особености". что за особености тут уже не раз пережевывалось, у
> интербейзников неадекватная реакция на них, так, что не будем будить
> буйных - перейдем к 10 годам:

Вот именно. Из-за этого в свое время начали проект Yaffel. Чтобы не
мешать им там "наслаждаца".

И по остальному тоже согласен.

Posted via ActualForum NNTP Server 1.4

21 фев 08, 19:54    [5325292]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
мда. у оппонентов, все-таки, предвзятое и поверхностное мнение об IB/FB :-) Поэтому я бы попросил, без обладания достоверными знаниями по поводу Yaffil и Vulcan, не оценивать - что было, как и зачем.

начну с последнего. Yaffil создавался совсем не "потому". И проблема SMP в суперсервере в нем решена не была (и не собирались). Наоборот, Yaffil за 1.5 года до FB отладил классик до упора. Потому что классик был искорежен при выпуске IB 6 Борландом.

далее. по производительности на данный момент у FB что у классика что у супера достаточная, не хуже MySQL и PostgreSQL, а в ряде мест и получше. У IB с SMP-Суперсервером - то же самое.
То есть, InterBase просто избавился от необходимости развивать две ветки кода, а Firebird развивал сам сервер, SQL, оптимизатор и т.д., оставив вопрос SMP суперсервера на потом.

Для того чтобы делать прогнозы, надо знать кухню, в которой все это варилось и варится. А пока что Ваши слова находятся на уровне "я слышал, что ..., и поэтому, наверное ...".
21 фев 08, 21:48    [5325522]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Yo.!
проэкт Vulcan благополучно заканселили

он мертворожденный. Последствия чего сейчас благополучно огребают в MySQL...

Yo.!
выпрямление оптимизатора хотя бы до уровня сегоднешнего MySQL

это шутко такой? Пусть они его сначала доведут до уровня сегодняшнего FB.
21 фев 08, 23:01    [5325703]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
fynda
Member

Откуда: Пенза
Сообщений: 2785

MasterZiv пишет:

> Список живых СУБД, в которых есть баги в многопоточности в студию !

Все они. И не надо говорить, что кто-то знает, как писать абсолютно
безглючный код.

Posted via ActualForum NNTP Server 1.4

22 фев 08, 10:35    [5326742]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
dimitr
Yo.!
проэкт Vulcan благополучно заканселили

он мертворожденный. Последствия чего сейчас благополучно огребают в MySQL...
А можно список последствий?
22 фев 08, 11:24    [5327135]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
VoDA
А можно список последствий?

насколько уже отстает от сроков Falcon? Каково его качество? Недавно даже у Зайцева проскочила мысль, что возможно Maria окажется заменой Falcon-а после отбраковки последнего. Я, конечно, полагаю, что у MySQL (или уже Sun?) таки хватит сил довести его до ума, но что купили они сырую поделку - для меня факт.
22 фев 08, 13:04    [5328094]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
kdv

далее. по производительности на данный момент у FB что у классика что у супера достаточная, не хуже MySQL и PostgreSQL, а в ряде мест и получше.

ну тогда мы с нетерпением ждем рассказ о мегафичах которые способны компенсировать невозможность использования суперсервером более одного ядра. у меня вот фантазии не хватает, у mysql совсем недавно был затык на стыке linux и mysql приводивший к деградации перфоменса лишь на 4х ядрах (не знаю пофиксили ли), но до 4х ядер там вполне линейно маштабировалось.
то же самое с класиком, мегафичи FB в студию которые могут компенсировать отсутсвие единого кеша данных.

dimitr
это шутко такой? Пусть они его сначала доведут до уровня сегодняшнего FB.

а можно кратенький списочек где по вашему FB опередил, я вот сходу предполагаю, что кэш разобраных планов запросов в mysql 4.1 дает ему громадное преимущество.
22 фев 08, 13:13    [5328184]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Yo.!
до 4х ядер там вполне линейно маштабировалось

линии бывают под разным углом начертаны :-) Я довольно пессимистичен насчет производельности InnoDB под активной read-write нагрузкой, если база сильно больше размера кэша. И линейное масштабирование тут мало выручает.

dimitr
а можно кратенький списочек где по вашему FB опередил

например, эффективное использование множества индексов для одного потока выборки или выполнение IN как индексированного semi-join. Собственно, я еще не видел ни одного результата сравнительных тестов (нетривиальнее хотя бы benchw, а лучше TPC-R/H), в которых MySQL суммарно выигрывает у FB. Собственно, с точки зрения путей доступа к данным и оптимизации у InnoDB я вижу только одно заметное преимущество - возможность полного индексного покрытия.

я вот сходу предполагаю, что кэш разобраных планов запросов в mysql 4.1 дает ему громадное преимущество

фича безусловно полезная, особенно под нагрузкой. Но каково по-вашему соотношение времени оптимизации к времени исполнения пусть даже коротких запросов в реальной жизни? Одна десятая? Одна сотая? Еще меньше? Как-то не выглядит это громадным преимуществом.
22 фев 08, 13:50    [5328487]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
dimitr

линии бывают под разным углом начертаны :-) Я довольно пессимистичен насчет производельности InnoDB под активной read-write нагрузкой, если база сильно больше размера кэша. И линейное масштабирование тут мало выручает.

откуда такой пессимизм ? я знаю только один тест заслуживающий доверия specjbb. там конечно примитивные запросы не встречающиеся в жизни, inndob в самом хвосте, но inndob не просел насмерть и вполне адекватно загрузил 4 ядра.

dimitr
а можно кратенький списочек где по вашему FB опередил

например, эффективное использование множества индексов для одного потока выборки или выполнение IN как индексированного semi-join.
[/quot]
хорошо, но это не настолько убойные фичи, чтоб компенсировать отсутствие SMP. наверника такая оптимизация нужна тяжелым приложениям, где mysql/innodb может противопоставить другие свои фичи. ну например FB как я понимаю если имеет индексы для предикатов никогда не пойдет на фулскан, mysql же учтет селективность и поступит гораздо мудрей. мне, например, кажется что такая ситуация гораздо чаще встречается.

dimitr

фича безусловно полезная, особенно под нагрузкой. Но каково по-вашему соотношение времени оптимизации к времени исполнения пусть даже коротких запросов в реальной жизни? Одна десятая? Одна сотая? Еще меньше? Как-то не выглядит это громадным преимуществом.


в оракле - громадная. если оракловое приложение не использует bind variables и оракл не понимает, что это одни и теже запросы и каждый раз парсит заново, то перфоманс на большом кол-ве одинаковых конкурентных запросах падает в разы. для такой ситуации даже параметр есть, который пытается угадать где в запросе переменные, чтоб закешировался план. большинство сообщали о улучшениях в разы на OLTP задачках.
22 фев 08, 14:30    [5328825]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Yo.!
откуда такой пессимизм ?

из практики

Yo.!
inndob в самом хвосте, но inndob не просел насмерть и вполне адекватно загрузил 4 ядра

я не отрицаю его способности грузить ядра, отнюдь. Лишь высказал мнение, что при невысокой базовой производительности хорошое масштабирование отнюдь не панацея.

Yo.!
хорошо, но это не настолько убойные фичи, чтоб компенсировать отсутствие SMP

бесспорно. Но меряться именно оптимизаторами вы первый начали :-)

Yo.!
например FB как я понимаю если имеет индексы для предикатов никогда не пойдет на фулскан, mysql же учтет селективность и поступит гораздо мудрей. мне, например, кажется что такая ситуация гораздо чаще встречается.

в отличие от mysql (и многих других), у FB выборка записей на основе индексного скана является sequential I/O, а не random. Это тут уже обсуждалось и да, в этом скрыты и недостатки тоже. Но в данном случае это таки достоинство. И вместо обычной оценки лимита отказа от range scan в ~30% от размера таблицы, в FB есть смысл оперировать порядком 70-80%. Лишь если кардинальность выборки еще больше этой цифры, тогда FB может уступить. В остальных случаях я бы еще подумал, на кого поставить. Резюмируя -- да, вы правы, есть такой недостаток у FB, но его значение в свете вышесказанного сильно преувеличено.

Yo.!
в оракле - громадная. если оракловое приложение не использует bind variables и оракл не понимает, что это одни и теже запросы и каждый раз парсит заново, то перфоманс на большом кол-ве одинаковых конкурентных запросах падает в разы

это может говорить и об относительной неторпливости ораклового парсера :-) Попробую поставить подобный эксперимент на FB.
22 фев 08, 15:34    [5329278]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
dimitr

я не отрицаю его способности грузить ядра, отнюдь. Лишь высказал мнение, что при невысокой базовой производительности хорошое масштабирование отнюдь не панацея.

он там отстал от постгреса всего на 10-15%, т.е. с i/o innodb относительно справился (запросы дубовые наверно оптимизатор особо не напрягался) и процы грузил не фатально глупее остальных субд из specjbb.

dimitr

в отличие от mysql (и многих других), у FB выборка записей на основе индексного скана является sequential I/O, а не random.

хм ... тогда у меня предложение вам подратся с kdv т.к. пару страниц выше он утверждал что readfilescatter FB не умеет.
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=309764&pg=25#5101992

dimitr

Резюмируя -- да, вы правы, есть такой недостаток у FB, но его значение в свете вышесказанного сильно преувеличено.

может преувеличено, а может нет, нужно мерять. у mysql один из самых слабых оптимизаторов, но пока я не вижу, как он может помешать обгонять FB в разы за счет SMP.
к старте в mysql есть еще фича read ahead, когда он при скане читает больше блоков чем нужно в надежде, что "лишние" блоки кому-то пригодятся, есть что-то похожее у FB ?
22 фев 08, 16:12    [5329514]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Yo.!
хм ... тогда у меня предложение вам подратся с kdv т.к. пару страниц выше он утверждал что readfilescatter FB не умеет

не умеет. Я имел ввиду не многоблочное чтение, а чтение старниц в порядке хранения в файле БД. Т.е. индексный скан всегда выполнит чтение страниц данных в порядке 1..2..3..5..10..11..12, а не в случайном порядке.

Yo.!
у mysql один из самых слабых оптимизаторов, но пока я не вижу, как он может помешать обгонять FB в разы за счет SMP

если в MySQL каждый запрос будет выполняться в разы медленнее, то SMP в лучшем случае лишь обеспечит паритет :-) Но это все болтология, на практике все надо мерять.

Yo.!
в mysql есть еще фича read ahead, есть что-то похожее у FB?

пока нет, увы. Ну вот, нашли еще одно преимущество MySQL :-)
22 фев 08, 16:38    [5329686]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
dimitr

не умеет. Я имел ввиду не многоблочное чтение, а чтение старниц в порядке хранения в файле БД. Т.е. индексный скан всегда выполнит чтение страниц данных в порядке 1..2..3..5..10..11..12, а не в случайном порядке.

не догоняю. на сколько мне известно у всех субд индекс отсортирован
или вы имеете ввиду что при RANGE SCAN FB пойдет последовательно читать весь индекс не зависимо от того какой кусок от индекса реально нужен !?

dimitr

если в MySQL каждый запрос будет выполняться в разы медленнее, то SMP в лучшем случае лишь обеспечит паритет :-)

для того чтоб запрос выполнялся в РАЗЫ медленее у FB должна быть просто мегафича в оптимизаторе, я про такую пока не услышал.

вернемся к началу MySQL я взял как самого слабенького и теперь мы опять можем вернутся у вопросу сколько лет понадобится FB на особености, отладку smp, async i/o, read-ahead, sql cache которые уже сегодня есть у самых слабеньких ? подозреваю дольше, чем эволюция FB c 1.0 до 3.0 ...
22 фев 08, 17:40    [5329963]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Yo.!
не догоняю. на сколько мне известно у всех субд индекс отсортирован

читайте внимательнее. Речь про чтение страниц данных (а не индекса) в порядке хранения. В PGSQL 8.2 это называют bitmap index scan, аналогов в других СУБД я не знаю.
22 фев 08, 18:01    [5330044]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
dimitr

читайте внимательнее. Речь про чтение страниц данных (а не индекса) в порядке хранения. В PGSQL 8.2 это называют bitmap index scan, аналогов в других СУБД я не знаю.

читаю:
http://zeus.sai.msu.ru:7000/seminars/cbd2006/postgresql/
В отличие от обычного сканирования индекса, в котором за один раз из индекса считывается только один указатель на запись, по которому потом поднимается сама запись из таблицы, bitmap scan считывает все указатели за один раз (Bitmap Index Scan), сортирует их в памяти и потом считывает записи уже в локализованном на диске порядке (Bitmap Heap Scan).


FB так работает при RANGE SCAN ?
22 фев 08, 18:19    [5330111]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Yo.!
FB так работает при RANGE SCAN ?

да
22 фев 08, 18:27    [5330138]     Ответить | Цитировать Сообщить модератору
 Re: Firebird (Interbase) vs MS SQL 2005  [new]
Yo.!
Guest
я потрясен. точно так ? неважно какой RANGE заставит прочесть весь индекс !?
это же в 90% случаев неоптимально.
22 фев 08, 18:43    [5330181]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить