Как распараллелить поисковый запрос для увеличения производительности?

Anton_D

Новичок
Как распараллелить поисковый запрос для увеличения производительности?

Итак, с чем имеем дело:
Таблица объемом около 10 млн записей varchar(255). И вот по этой таблице делается поиск по подстроке, типа SELECT * FROM TBL WHERE name like '%query%' Размер таблицы пока таков, что она еще лезет в память целиком - 1гб. Пусть в данный момент такой поиск занимает 1 сек. Прогнозируется увеличение количества записей в 10 раз.

Что нужно: сдержать время отклика на текущем уровне.

Первое что приходит в голову: тупо разделить таблицу на 10 частей, каждую из которых положить на свой сервер, сервера соединить сеткой, кидать им соответственно 10 одинаковых запросов, получать 10 рекордсетов, которые потом объединять в один. В результирующем рекордсетете обычно получается не более 1000 строк, так что проблем со 100 мбит сеткой не будет. Пишмашинки типа Cel D 2ггц стоят несравнимо дешевле настоящих серверов, их можно покупать десятками по мере необходимости. :)

А теперь вопрос: а как организовать 10 параллельных запросов из php скрипта? :confused: Запустить их exec-ом в виде внешних скриптов, организовать флажки/семафоры и мониторить все это хозяйство из основного скрипта на предмет результатов выполнения возврата результата? Бред или нет? Может быть я велосипед изобретаю? Буду благодарен за пинок в нужном направлении.
 

Anton_D

Новичок
Автор оригинала: _RVK_
Пинок:
Однако познавательно.
Этакий изощренный метод реплицирования с одновременным расчленением БД. Да, это решает проблему упихивания огромной БД в RAM. Однако я не нашел в мануале явных разъяснений, как обрабатываются запросы. Какую роль играет в обработке запросов SQL нода, а какую дата ноды?

В глоссарии сказано, что дата ноды занимаются лишь хранением кусков базы и репликацией, а sql ноды непосредственно запросами, обращаясь при этом просто к NDB стораджу вместо например MyISAM.

Нет явных пояснений распараллеливается ли процесс поиска и если да, то как.

Вообщем по простому, если у меня есть БД с временем фуллскана в 1 сек, получу ли я десятикратный выигрыш в скорости фуллскана, если сделаю NDB кластер из 10 дата нод?
 

_RVK_

Новичок
Anton_D
Признаюсь сам кластер на MySQL не делал, ибо фича новая, неизведанная. Но руководствуясь свими познаниями и представлениями о здравом смысле могу сказать что кластеры для того и существуют, что бы распределить нагрузку, а не только для повышения надежности. Судя по формуле вычисления требуемой памяти, весь объем данных распределяется равномерно. Отсюда сожно сделать вывод что запросы так же будут распаралеливаться на всех членов кластера. Хотя сам бы хотел бы услышать по этому поводу более авторитетное мнение чем мое.
 

Anton_D

Новичок
Автор оригинала: _RVK_
Но руководствуясь свими познаниями и представлениями о здравом смысле могу сказать что кластеры для того и существуют, что бы распределить нагрузку, а не только для повышения надежности.
Да, мой здравый смысл подсказывает тоже самое, но тем не менее.

С другой стороны, если абстрагироваться от вопросов крутизны, новизны и "правильности" решений, то моя конкретная задача легко решается достаточно тупым и узкоспециализированным способом, который я описал выше. И тут вопрос конкретно по специфике PHP: есть ли способ одновременно сделать N SQL запросов, кроме как запустив exec-ом N внешних приложений?
 

_RVK_

Новичок
Одновременно нет, кроме как запустить 10 скриптов.
Кстати я бы на твоем месте, имея сервера и время, все же бу попытался настроить класстер. Во первых интересно, во вторых опыт, в третьих поделился бы потом впечатленими.
 

Rammstein

PHPClub::News
Подобные решения лучше на PostgreSQL смотрятся, имхо.... Там и кластеры стандартная практика...
 

si

Administrator
Anton_D
помоему дня начала надо построить систему так чтобы использовались индексы.

-~{}~ 08.01.06 19:12:

_RVK_
кластер в mysql требует чтобы вся база помещалась в RAM что весьма сильно ограничивает сферу применения.

для распределения нагрузки весьма часто достаточно репликации master/multi slave
 

Anton_D

Новичок
Автор оригинала: si
помоему дня начала надо построить систему так чтобы использовались индексы.
О каких индексах идет речь, если запрос "like '%query%'"? Или речь идет о полном редизайне системы с целью избавиться от фуллскана? И как от него избавиться? Перейти на поиск по словарю? Ну может быть, может быть, хотя это и не панацея, сильно зависит от данных.

И вот еще соображения: на редизайн, к примеру , потребуется $10к в виде з/п программеру(ам) и с полгода времени. А с распараллеливанием в эти 10к влезет 30 (тридцать) пишмашинок, что явно даст такой выигрыш по производительности, какого не даст никакой редизайн.

PS: Десяти серверов у меня пока нет ;) , только прицениваюсь. :D
 

_RVK_

Новичок
si
До, но во первых у автора видимо нет особых огранечений на количество серверов, во вторых уже вполне доступны 64 разрядные системы.

часто достаточно репликации master/multi slave
Кстати да. Но тут тоже сфера весьма ограничена, из-за того что slave read only. Все зависит от конкретной ситуации.
 

Anton_D

Новичок
Автор оригинала: _RVK_
si
До, но во первых у автора видимо нет особых огранечений на количество серверов
Попрошу только отметить, дешевых серверов! ;) Дорогих есть всего лишь пара и планируется еще один, не больше, и он в данной ситуации делу поможет мало. Поэтому так привлекательна идея использовать brute force в виде сверхдешевого кластера. В датацентре его же ставить не обязательно, можно хоть дома, в кладовке. :)

Кстати да. Но тут тоже сфера весьма ограничена, из-за того что slave read only. Все зависит от конкретной ситуации.
Вариант с репликацией и разделением базы на чтение/запись я рассматривал, но выигрыша это практически не даст, база в основном работает на чтение. И 90% нагрузки дает единственный запрос.
 

si

Administrator
Кстати да. Но тут тоже сфера весьма ограничена, из-за того что slave read only. Все зависит от конкретной ситуации.
собственно это особо не мешает обычно, пишем на мастер, читаем со slave. причем практика показывается что т.к на svale пишет в базу всего 1 процесс ему намного легче дышется чем мастеру при тойже нагрузке.
Вариант с репликацией и разделением базы на чтение/запись я рассматривал, но выигрыша это практически не даст, база в основном работает на чтение. И 90% нагрузки дает единственный запрос.
еще как даст. только начинать надо с индексов ...

-~{}~ 08.01.06 20:49:

во вторых уже вполне доступны 64 разрядные системы.
сколько стоят системы с 16/32G памяти знаете ?
 

Anton_D

Новичок
Автор оригинала: si
еще как даст.
В моем случае точно ничего не даст. Запись в базу делается всего несколько раз в сутки и объемы небольшие. 99.9% нагрузки - это чтение из базы.
 

si

Administrator
Anton_D
а то что читать можно паралельно на 2х серверах это ничего ?
 

Anton_D

Новичок
Автор оригинала: si
Anton_D
может вам fulltext подойдет ?
FULLTEXT в mysqlной реализации пробовал. Копошится долго. Но он принципиально не может заменить поиска по подстроке. Ведь это же все таки индекс и слова в словаре все равно индексируются с "начала" слова.

Мои данные, по которым производится поиск, не похожи на обычный текст типа "Привет, меня зовут Антон." Они похожи на "778GTY-5GG%221h" При этом, даже если разбивать по каким либо формальным признакам эту абракадабру на атомы, то все равно атомы тоже нужно обшаривать по подстроке. И вот этот вариант я уже давно обдумываю, но здесь все сильно зависит от степени избыточности данных, если она велика, то это даст сильнейшую прибавку в скорости поиска, а если не очень, то как бы не стало хуже.

-~{}~ 08.01.06 22:23:

Автор оригинала: si
Anton_D
а то что читать можно паралельно на 2х серверах это ничего ?
Не понял, что это может дать кроме соревнования кто быстрее. Хотя в принципе понятно, если поток запросов высок, напритмер 2 в секунду и каждый запрос выполняется 1 сек, то раскидывание запросов между двумя серверами даст реакцию в 1 секунду. Но в ситуации, когда запросы идут редко, но выполняются долго это не поможет. У меня именно такая ситуация.
 
Сверху