Привет Всем!! Работаю над поисковой системой. По началу использовался двиг. Sphinx и Mysql, в качестве хранилища. Количество данных растет, производительность выборок падает, да и хочется по уму развиваться. Поэтому решился перейти на нереляционные распределенные хранилища.

Из того, что нашел в сети: MemcacheDB, CouchDB, HBase, Hypertable

Посоветуйте, пожалуйста, что выбрать? И оправдан ли подход использовать такие хранилища?

phprusОпиши подробнее задачу.
Что ищет твоя поисковая система, в каком месте и как сильно падает производительность? Какие объемы данных?
Посмотри на этот раздел документации: 4.7. Distributed searching

По поводу найденного тобой в сети могу сказать, что CouchDB - тот еще тормоз. У меня он на данных, которые в SQL базе заняли мегабайт 10 создал своих файлов на 250 мегабайт, а при попытке запустить простую view, которая строила выборку так, что ключом было одно из полей хранящихся документов, а значением - сам документ CouchDB трудился занимая весь мой core2duo 2,4 в течении 10 часов, насоздавал файлов на гигабайт, но по внутренней статистике обработал менее 30% документов. В общем результата я так и не дождался, так что для каких-либо выборок, кроме выборок по ключу он явно подходит слабо.

Поисковая система ищет товары и услуги в Мускуле (сайт справочной). Размер таблиц в пределах 1 000 000 – 7 000 000 строк. Объем всей базы, около 10Гб.
Сайтик молодой совсем, но оперативно наполняется база. Наполнением занимаются менеджеры и партнеры. Вся база находится на 1 выделенном сервере. На нем находится и сайтец. Пока количество пользователей мало, до 500 хостов в день, работает все стабильненько.
С ростом базы, производительность падает на cелектах, по сути они только и используются. Спасаюсь Sphinx, тем, что часть поиска возлагал на него, а не БД. И естественно, кеширование.

Начальство может выделить для системы еще пару настольников. Вот и задумался, насчет распределенного хранилища данных. Хранилище пар ключ-значение, для этих целей вполне достаточно, плюс, удобство масштабирования. (Это все по материалам в сети).
С подобными системами не сталкивался, это мой первый опыт.

Спасибо за реальную информацию по CouchDB. Тогда не буду с этой СУБД связываться.

Балансировать чем ???

А чем плохи так хранилища то?

Dimitry Sibiryakov,

Спасибо!!! Как познавательный варинт, пригодится.

Вот только вопрос мучает. Как Mysql будет вести, когда информации будет уже на сотни гигабайт??? Если сама СУБД будет уже туго работать с такими объемами, то и балансировочные серваки особо не спасут, как я понимаю. Ведь выделяют тока пару настольников, а не "полноценные" сервера.

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

SERG1257Relarn Поэтому решился перейти на нереляционные распределенные хранилища.
То есть планы каждого селекта просмотрены и оптимизированы. Структура данных тоже уже заточена под запросы.
Relarn И оправдан ли подход использовать такие хранилища?Не выжав максимум из имеющейся системы (MySql) хвататься за другую? То есть вы уверены что хранилище все сделает за вас?

Структуру разрабатывал не я, этот человек уволился. Но надо отдать должное, сделал не плохо. Сама база очень простенькая, для справочной то больше и не надо. Решил переходить на хранилища, потому Мускул используется как хранилище "ключ-значение". (JOIN-ов нет почти, да и те, считанные, случаи которые есть - работают шустро ). Разве в этом случае хранилища не эффективнее по скорости выборки будут?

SERG1257Я наверное такой молоток который все проблемы рассматривает как гвозди.
Имеем - замедление селектов с ростом базы данных - сразу первое подозрение - что-то плохо проиндексировано.
Стало быть применяем классический алгоритм оптимизации.
Убедились что все нужные индексы созданы, ненужные убиты, все планы оптимальны, но производительности все равно не хватает - добавили железо (память или дополнительных сервера)
Технология отлажена, результат предсказуем, специалистов много, в случае чего подскажут.

Если у вас какая-то особая задача - пример LDAP - специальная база данных - смотрим в сторону специализированных средств. По моему мнению, поиск товаров и услуг - типичная задача для РСУБД, а у вас просто чешутся руки попробовать что-то другое крутое и экзотическое.

Если анализ не проведен, то введение дополнительных средств (фич базы данных, нереляционных хранилищ и т.д.) может привести к успеху только случайно.

Советую на соседнем форуме опубликовать схему данных, типичные тормозящие запросы и посмотреть что народ скажет.

Спасибо, так и поступлю:) А в целом, Вы, правы - действительно хотелось попробовать что-то новое.