Как организовать поиск по 10 млн. документов?

Question

[IRuslan]

Есть сайт. В MySQL БД хранится порядка 10 000 000 записей.

Нужно сделать полнотекстовый поиск + что бы поиск был релевантным.


Использование поискового движка не спасает. Уже при 1 млн. задержка выдачи результатов с помощью ApacheSolr несколько секунд.

Пытались смотреть на www.elasticsearch.org и вообще связки с NoSQL (HSearch), но решения способного давать релевантную выдачу за приемлемое время не нашли. Вернее варианты есть, но пришлось бы реализовывать логику подсчета релевантности самим, для всех типов записей, а хотелось бы чего-нибудь готового.

Answer 1

[Евгений]

sphinxsearch.com

Comments

[IRuslan]

sphinx мы тоже рассматривали. Есть ли данные как он будет себя вести с таким объемом, и сколько он при этом выдержит хитов (запросов ожидается большое количество)?

[Евгений]

Странно что вы его рассматривали и не владеете этими данными. С объемом у него все в порядке, до 100млн документов, на счет количества запросов не вникал в этот факт, всегда хватало. Да и на хабре он стоит как поисковый движок.

[Искандер Гиниятуллин]

Searching performance. Searching through 1,000,000-document, 1.2 GB text collection that we use for everyday development and testing runs at 500+ queries/sec on a 2-core desktop machine with 2 GB of RAM.

sphinxsearch.com/about/sphinx/

если рассматривали то могли бы хотя бы уйти дальше главной страницы

[IRuslan]

Сайт проекта я читал, и на круглые циферки смотрел. Просто хотел услышать реальный опыт людей в этом вопросе.

Answer 2

[IRuslan]

Спасибо за информацию. Устроим тест-драйв сфинксу, тогда станет понятно подойдет ли он нам…

Answer 3

[Пума Тайланд]

До 100 запросов в секунду держит сфинкс.

Comments

[CKOPOBAPKuH]

до тысячи вообще-то

[Пума Тайланд]

Таких проектов в руках я пока что не держал, писал про то что встречал в реальной жизни.

Answer 4

[IRuslan]

В рамках поставленного вопроса, да сфинкс скорее всего бы спас.

Но ввиду того, что приложение на PHP + MySQL с таким объемом может не справиться, видится необходимость добавления NoSQL. И как следствие хотелось бы найти самый простой способ объединения NoSQL и поискового движка.
Идеальной была бы связка NoSQL + Search таким образом что бы поисковик отдавал список ключей по релевантности, а сами документы уже потом тянуть из NoSQL.

Comments

[Пума Тайланд]

А чем отличается связка пхп+мускул+ сфинкс от не пхп связки? И каким боком тут nosql?
У вас какие то странные представления о производительности.

[Искандер Гиниятуллин]

Если поисковик отдает список ключей то по большому счету без разницы тянуть их из mysql или nosql

[IRuslan]

Разве выборка по ключам из key-value хранилища не будет быстрее запроса с 5-6 джойнами на таблицы около 1 млн. записей каждая в MySQL?

Answer 5

[Aleks]

Xapian например

Answer 6

[Riateche]

Яндекс для сервера, как вариант.

Answer 7

[densilvio]

Мы для этой цели использовали Lucene

Answer 8

[Aleksey]

Использование поискового движка не спасает. Уже при 1 млн. задержка выдачи результатов с помощью ApacheSolr несколько секунд.

Вы что-то делаете не так.

• сколько индекс занимает на жестком диске?
• сколько памяти выделяете под виртуальную машину и сколько соотв-но остается под файловый кеш операционной системы?
• какое кол-во документов возвращает поисковый запрос?
• есть ли какие-то хитрые штуки вроде группировки документов или подсветки ключевых слов на огромных документах

Ну в вообще, если документы не огромные, то обьем вполне реальный, и даже не требует распределенного индекса, при увеличении нагрузки можно обойтись и репликацией.