какие такие бенчмарки? скажи как - я сделю. а так я писнул на пхпклубе статейку. http://phpclub.ru/talk/showthread.php?s ... did=110165
440Hz Главное не гоняй сложные запросы со всякими GROUP BY, сложными WHERE где по обе части от знаков сравнивания происходят вычисления и.т.д. Это я чисто так напоминаю, а то иногда забывается такое, а он с этим нормально не умеет работать Скачал сегодня кстати whitepaper по NDB кластеру от MySQL - хорошая штука
440Hz например, выборки по праймари ключу с условиями. Просто вариант > или < - посмотреть как датаноды ищут, вариант с функциями (какой-нить синус) - в этом случае sql нода будет выгребать все данные с датанод. Интересует, как это будет масштабироваться от увеличения датанод и от увеличения реплик
В догонку Интересно посмотреть как по примариkey будет получать ченить типа WHERE id IN (1, 2, 666, 1313 ... 156) особенно с эксплайнами. Было про крэзи у оптимизатора. Доходило до FORCE INDEX чтоб индексы заставить юзать.
EugeneTM, должно быть нормально. Выборка по праймари ключу вообще должна быть самая быстрая и масштабируемая, ибо там запрос шлется именно нужным дата-нодам сразу (ибо данные именно по хешу от праймари ключа раскидываются). О том, что IN работает так же - говорилось в докладе, на который я ссылку кидал.
это понятно. Вопрос как поведет себя оптимизатор в комбинации с 'IN' в теории должно быть Ок На практике все что угодно Типа такого http://sqlinfo.ru/forum/viewtopic.php?id=140
Именно это и интересно. Не поведет ли себя оптимизатор с 'IN'ом аналогично джойну. Естественно если в 'IN'е будут значения , а не сабселект. Если сабселект наверное помрет.
Не, с джойном другая проблема. Для того, что бы сделать джойн, нужно все данные по этим таблицам с дата-нод передать на SQL ноды и там уже сделать дджойн. А в случае с выборкой по одной таблице оптимизатор пытается выгребать с именно нужных датанод. Это верно и для IN. А вот если появляются какие-то функции - тут опять, полное выгребание.
Это в теории. На практике ... ... вплоть до внесения изменений в документацию в соответствии с всплывшими багами вместо их исправления. Крыли не так давно за такое Свету Смирнову. Вот и проверить не типа MySQL AG на заборе пишет, а на боевом кластере.