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). ну, а чтоб тягатся с лидерами и быть хотя бы с постгресом одной весовой категории еще туча фич понадобится ...

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

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

dimitrэто шутко такой? Пусть они его сначала доведут до уровня сегодняшнего FB.
а можно кратенький списочек где по вашему FB опередил, я вот сходу предполагаю, что кэш разобраных планов запросов в mysql 4.1 дает ему громадное преимущество.

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

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

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

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

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

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

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

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

хм ... тогда у меня предложение вам подратся с kdv т.к. пару страниц выше он утверждал что readfilescatter FB не умеет.
/topic/309764&pg=25#5101992

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

может преувеличено, а может нет, нужно мерять. у mysql один из самых слабых оптимизаторов, но пока я не вижу, как он может помешать обгонять FB в разы за счет SMP.
к старте в mysql есть еще фича read ahead, когда он при скане читает больше блоков чем нужно в надежде, что "лишние" блоки кому-то пригодятся, есть что-то похожее у FB ?

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 ...

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 ?

я потрясен. точно так ? неважно какой RANGE заставит прочесть весь индекс !?
это же в 90% случаев неоптимально.