Зачем нужны Solr, Sphinx, и прочие системы поиска?

Question

[Twitt]

Никак не могу понять, я знаю что Solr используется допустим в интернет магазинах, и оттуда берутся данные вроде как. Но в чем смысл, если у меня в магазине есть своя БД с товарами? Я наслышан часто о Solr, Sphinx, ElasticSearch, но не могу понять - зачем они в принципе нужны? Что это такое? В гугле не забанен, просто не совсем понимаю
вопрос наверно больше - откуда он берет данные, этот Sphinx или Solr?
Мы даем какой-то запрос, и он по всему интернету ищет и возвращает в каком то формате?

Comments

[xmoonlight]

Есть такие, где можно просто дать данные списком и сразу же получить результат: здесь

Answer 1

[Дмитрий]

Я так понял, что основная непонятка в том, где поисковый движок берет данные?
Любой поисковый движок ищет инфу в своих индексах, которые строятся на основе данных, которые мы ему отдали. Очень грубый пример для сфинкса - например, у вас есть база с товарами и надо сделать поиск по названию и описанию. Если делать это средствами БД, то это будет что-то вроде

select id from products where name like '%search_phrase%' or description like '%search_phrase%'

(я не беру в расчет спец. средства разных бд для полнотекстового поиска). Ну и сразу понятно, что like будет выполняться адово долго. В итоге на 1 запрос у вас удйет от пары сек и до вечности.
И тут приходят поисковые движки. На примере сфинкса - скармливаем ему всю инфу о товарах (айди, название, описание). Как именно это делается зависит от типа индекса. Можно указать вообще sql запрос, который выполнит сфинкс, чтобы наполнить свой индекс. Далее он по своим алгоритмам строит индексы, оптимизированные для текстового поиска. И делаем уже выборку через него

select id from i_products where match('search_phrase')

(синтаксис примерный). И получаем айдишки найденных продуктов. В данном случае поиск выполняется очень быстро (если индекс правильно настроен) и вместо нескольких секунд получаем несколько миллисекунд.

Comments

[Twitt]

Вот, более менее прояснилось! Спасибо!!
Вопрос контрольный:
Solr работает в паре с MySQL, верно? То есть, Solr берет данные из бд, той же таблицы products, но намного быстрее чем это можно сделать через SQL, верно?

[Dmitry MiksIr]

Igor, нет, у него свой индекс, свое хранилище, это совсем отдельное ПО. Данные перегоняются текстом - селект из мускуля, запрос на добавление в Solr. А поскольку Solr или ElasticSearch (оба, кстати, построены на одном движке Lucene) не реляционные базы, структуры данных могут быть совсем другие, именно те, которые оптимальны для поиска. Т.е. это в мускуле у вас таблица продуктов, таблица заказов, таблица остатков, а в Эластик может попасть сводный документ со всеми этими данными сразу, а может и еще какими-то данными, взятыми из других источников (например, частота просмотров страниц может идти сразу в Эластик, так как там она нужна для аналитики, а в реляционной базе - просто не нужна). Ну, минус - приходится заботится об актуальности данных, копии которых хранятся в разных СУБД (и как правило это задача разработчика)

[Дмитрий]

Igor, как уже написали - там отдельный индекс/хранилище, mySql был просто для примера. А так мы в индекс поискового движка может данные запихнуть откуда угодно.
Проще всего представить аналогию с БД. Т.е. поисковый движок использует свою "БД", т.н. поисковый индекс, который оптимизирован для поиска. У него есть свои поля (которые могут отличаться от полей в исходной базе), которые используются для поиска. И закинуть данные с этот индекс мы можем как из одной таблицы/бд, так и из разных.
Как пример - тот же самый вариант с продуктами, но помимо названия и описания, которые хранятся в нашей базе можно добавить туда, например, информацию о товаре с сайта производителя. В таком случае мы уже не используем для наполнения индекса какой-то один запрос к базе, а сперва подготавливаем данные (выбираем товары из базы, получаем, для каких возможно, инфу с сайта производителя, через апи или тупо парсингом, на важно), а потом их закидываем в индекс любым из способов, которые доступны для данного конкретного поискового движка.
Ну и на счет скорости - он ищет быстрее, чем это можно сделать через SQL, а вот с какой скоростью данные попадают в индекс - тут все зависит от способа наполнения.

Answer 2

[Алексей]

Эти системы индексируют контент, что значительно ускоряет поиск. Можно дополнительно подключить модули, которые будут искать синонимы и исправлять ошибки ввода.

Comments

[Владимир Муковоз]

исправлять ошибки ввода

Было дело задавался этим вопросом, но ничего дельного не нашёл, поделитесь ссылочкой если она под рукой, буду признателен)

[Алексей]

Владимир Муковоз, Под рукой нет, надо ноут открыть, там поискать. Завтра поищу. Но там тоже не всё так гладко с русским языком. Нужны словари и то они не так хорошо работают.

[Владимир Муковоз]

Алексей, ну тогда боюсь в Вашей ссылке инфа которой я уже обладаю) Но всё же отправьте по возможности, гляну. Спасибо за отклик.

[Twitt]

Алексей, тогда я не совсем понимаю, смысл хранить товары в своей бд где то в MySQL если берутся из SOLR?

[Алексей]

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

[xmoonlight]

Владимир Муковоз, Вот этот ищет довольно качественно (там можно потестить) и строит индекс в "прозрачном" режиме.

Answer 3

[Владимир Муковоз]

Sphinx ставлю на битриксы, поиск становится шустрее и выдача по поиску более корректная. Я пользую его только для этого, но уверен плюсов у него должно быть больше)

Comments

[Twitt]

вопрос наверно больше - откуда он берет данные, этот Sphinx или Solr?
Мы даем какой-то запрос, и он по всему интернету ищет и возвращает в каком то формате?

[Владимир Муковоз]

Igor, ему их отдаёт битрикс в моём случае.

[Кирилл Несмеянов]

Igor, из основной БД: В фоне, например, синхронизирует и реструктуризирует для максимально быстрого поиска по неким полям A, B и C.

Answer 4

[lukoie]

Вы ставите их как "плагины" на своем сервере, для индексации контента, и дополнительных плюшек. Это такие себе глобальные системы поиска для вашего контента, вместо поисковых алгоритмов и систем поиска в ЦМС.

Answer 5

[Вячеслав Успенский]

Они нужны затем чтобы выполнять быстрый морфологический поиск по вашим данным.
Однако при наличии нормальной СУБД, как например PostgreSQL их полезность уже не так очевидна, поскольку у последнего есть FTS и n-грамм-индексы.

Answer 6

[xmoonlight]

Да просто попиариться: создали "подпорки" под CMS и всё.
А так - берёшь алгоритмы с википедии и делаешь тоже самое на любой БД.

Пример кода поиска подстроки в тексте вне зависимости от склонений, падежей, суффиксов и окончаний.