Документ обсуждает выбор систем поиска, таких как Sphinx, Lucene и другие, акцентируя внимание на их сравнительных характеристиках, включая производительность, функциональность, масштабируемость и интеграцию. Основные рекомендации направлены на выбор подходящей системы в зависимости от конкретных требований, а также на необходимость тестирования и бенчмаркинга. Подчеркивается, что различия между системами могут сильно влиять на результаты поиска, и важно ориентироваться на реальные потребности перед выбором.

1. Выбираем поиск
умом головы
Андрей Аксёнов, Sphinx

2. Про что доклад
• Надо поиск, какой взять?
– Дык в MySQL/Postgres/Mongo чота типа есть и агонь
– Взять Sphinx, C++ не подведёт
– Взять Lucene/Solr/Elastic, Java не подведёт
– Самим всё написать, мы ж мужики
– Купить крутейший коммерческий, например

3. Про что доклад
• Надо поиск, какой взять?
• Чем и как MySQL vs Postgres vs Mongo vs Sphinx vs
Lucene vs … оно всё внутри вообще отличается?
• Как правильно бенчмаркать?
• Что ещё нужно сравнивать?

4. Про что доклад
• Надо поиск, какой взять?
– Разумеется, Sphinx!
– Разумеется, с контрактом на поддержку!
– Разумеется, чем больше нулей, тем лучше!
– Всё, доклад окончен, расходимся

5. Варианты – в порядке
усложнения

6. Самописный поиск за 1 час
• create table X (
keyword varchar(255) not null,
docid integer primary key not null );
• insert into X values (“hello”, 123), (“world”, 123);
• select * from X a, X b where
a.keyword=“hello” and
b.keyword=“world” and
a.docid=b.docid

7. Самописный поиск за 1 вечер
• Можно даже успеть вкрутить еще всякое!
– Стеммер, libstemmer и его порты
– Морфология, pyrmophy2, phpmorphy (aot нельзя)
– Ранжирование, BM25
• alter table X add column termfreq integer
• create table D (keyword varchar(255), docfreq integer)
• select …

8. Встроенный в базу поиск
• Согласно вендору базы, Дичайше Круче Всех
• На самом деле, Неизбежно Выйдет Говнецо (*)
– Все базы в первую очередь про OLAP, ох
– Великие Древние ещё также умеют транзакции, ууух
– Типично муторно масштабировать
– Синтаксис, ранжирование, эффективность? Не, не слышали
(*) Разумеется, именно Ваш Любимый Вендор не такой!

9. Самописный поиск за 10 лет
• Можно успеть вкрутить ещё всякое!!!
– Внятный формат индекса
– Поддержка атрибутивки
– Синтаксис запросов
– Ранжирование
– Кластеризация
• Каждый пункт = N переделок, M лет

10. Внешний поиск
• FOSS (free, open source)
– Sphinx
– Lucene + сервера поверх (Solr, Elastic)
• Коммерческие
– FAST, Endeca, Autonomy, Verity… куча вендоров
– Отдельный мир, обязательно Sharepoint и 4-5 нулей
– Интеграция, поддержка, функционал часто хтонические

11. Так своё писать или как!?
• Как ни странно, иногда надо
– Core product (Google, Yandex, Bing…)
– Спецтребования (“хочу взлетать в 16 KB памяти…”)
• Ключевое, осознавать масштаб бедствия
– У нас вот получается довольно компактно
– Sphinx 0.1 = ~1K LOC, Sphinx 2.x = ~120K LOC
– Больше фичей и-или “сопливый” код = ~1..10M+ LOC

12. Так своё писать или как!?
• 99%, что вам – не надо
– Мало усилий => так себе и получится
– Много усилий => это зачем?
• Берите базу, берите Sphinx, берите Lucene & spawn
• Бегите от “заказчиков”, у которых нету $10 на VPS!!!

13. На что смотреть?

14. А чем НеСвои отличаются-то?
• Ууу…
• Отличаются метод доставки данных; форматы
индекса; скорость индексации; размеры индекса;
требования к RAM; механизмы масштабирования;
API доступа; функционал текстового поиска; скорость
текстового поиска, причем от вида запроса; скорость
НЕтекстового поиска; добавочные функции (геопоиск,
фасеты, подсказки, сниппеты); ранжирование;
расширяемость…

15. Отличается ВСЁ!!!

16. Но, хорошие новости!

17. Отличия в массе…

18. ПОФИГУ!!!

19. Что сравнивать?
• Сравнивать надо фактически важное
– Не умеют не только лишь все
– Мало кто может это делать
• У каждого свои требования, они ортогональны
– Качество поиска VS супербыстрый булев поиск?
– Текстовый поиск VS атрибутивка?
– Масштабирование на терабайты VS индекс на 1 GB?

20. Про отличия чуть подробнее
• Совсем подробно нельзя – уйдет 3 дня
• Поэтому – очень кратко, по верхам
• 3 категории = (1) базы, (2) FOSS, (3) commercial
• 4 мегаоси = (1) эффективность, (2) функционал,
(3) масштабируемость, (4) интеграция

21. Performance Functions Scaling Integration
DBMS 1..2 1..2 1..3 5+
FOSS
(Sphinx, Lucene)
3..5 4..5 3..5 3..4
Commercial 1..5 1..5 1..5 3..4
DIY 1d..1m 1* 1* 1* 1*

22. Правильно читаем таблицу
• Типичная база = хреновенькие скорость, функционал,
масштабируемость… зато отличная интеграция!
• Типичный FOSS = хорошо или отлично С/Ф/М;
интеграция окей (но очевидно хуже встроенного)
• Commercial = возможны адовые попадосы по любому
параметру за свои же деньги, в целом не впечатляет
• DIY = в общем будет очень плохо; но в частностях,
возможно, невероятно хорошо

23. Внутренние различия,
Sphinx vs Lucene

24. Sphinx vs Lucene
• Поговорим немного про “а что внутри”
• Какие сходства, откуда растут отличия
• Sphinx = сервер, C++ (библиотека “как бы” есть)
• Lucene = библиотека, Java
• Solr = сервер, Java
• Elastic = сервер, Java

25. Sphinx 2.x vs 3.x
• Долго делаем, всякому научились
• Теперь переделываем внутри много всего
• Некоторые переделки Поменяют Всё, поэтому!

26. Sphinx vs Lucene
• Что одинаковое?
– Идеология “инвертированный файл”
– Всё начинается от текстового поиска
– Отдельно довески про атрибутивку
• Что это значит?
– “Тупо поиск” работает принципально одинаково
– Детали реализации, однако, могут менять всё

27. Sphinx vs Lucene
• Что разное внутри?
– Формат хранения ключевиков, постингов
– Формат хранения атрибутов
– “Привычки” внутреннего кеширования
– “Фокус” матчилки
• Что это значит?

28. Про формат постингов
• Sphinx 2.x = общие словари, списки по всем полям
• Lucene = отдельные по каждому полю
– Матчинг в “редком” поле = Lucene “О-быстрее”
– Матчинг по куче полей = Lucene “О-медленнее”
– Матчинг со взвешиванием = Lucene “О-медленнее”
– Нумерация полей = Sphinx 2.x ограничен 256 полями,
индекс “О-больше” по размеру
– Куча полей, куча уникальных “слов” = плохо везде (словарь)

29. Про формат атрибутов
• Sphinx 2.x = in-memory, row-based attr-only table
• Lucene = on-disk, row-based docstore + кеш кеш кеш
– Доступ в Sphinx = in-memory hash lookup
– Доступ в Lucene = как бы disk read, поэтому кеш кеш кеш
– Sphinx = можно смешать schemaful/schemaless
– Lucene = полный schemaless, поэтому кеш кеш кеш 
– Зато у нас в 2.x дурацкие исторические ограничения 

30. Про формат документов
• Lucene = хранилка документов есть
• Sphinx 2.x = хранилки документов нет
• Sphinx 3.x = хранилка документов тоже есть
– Тоже перерастаем в странную СУБД
– Тоже disk based, тоже LZ4
– Принципиально улучшить не удалось

31. Про кеширование
• Sphinx = запрос надо уметь считать адово быстро
• Lucene = скорость вторична, всё закешируем!
– Sphinx = внутренних кешей почитай нет 
– Lucene = кешируется ВСЁ, местами хрен отключишь
– Делать адекватные бенчмарки это местами АД
• Xapian (внезапно) = оптимизация под дефолтный,
непрактичный юзкейс

32. Про “фокус” матчилки
• Sphinx 2.x = позиции! ранжирование! релевантность!
фиксированный бюджет памяти!
• Lucene = не-не-не, булев матчинг и может BM25;
памяти побольше тупо ставь
– Sphinx 2.x = неидеально c булевым поиском
– Sphinx 3.x = думаем про отдельный lightweight code path…
и убрать бюджетирование, муахахаха
– Lucene = неидеально с ранжированием/позициями

33. Итого
• Концептуально одинаково (инвертированный файл)
• Довольно разные реализации
• “Детали реализации” меняют всё, в разы

34. Внешние различия

35. Что на этаж выше?
• Sphinx vs Solr/Elastic, что одинаковое?
– Везде некий API (SphinxQL, REST/XML, REST/JSON)
– Везде завелись RT индексы
– Везде развелся schemaless/JSON (в разной мере)
– Везде как минимум агрегация результатов с кластера
– Везде поддержка атрибутивки, ряда допфункций
– Везде, что странно, “просто поиск” как-то работает!!!
– Коммодитизация…

36. Что на этаж выше?
• Sphinx vs Solr/Elastic, что разное?
– S/E, репликация, автошардинг, REST, “реверсные” поиски,
менеджмент кластера (почти всё тоже делаем для 3.0)
– Sphinx, встроенная морфология, “сложное” ранжирование,
считалка выражений
• Всегда разный “эзотерический” (?) функционал
– Sphinx, плохо помню! Zones, blend_chars, итп?
– S/E, плохо знаю! Per-field mappings, nested docs итп?

37. Так где идеал?

38. Идеала нет!!!
• Мне не нравится, как устроен Sphinx 2.x
• Мне не нравится, как устроен Lucene
• И в Sphinx 3.0 мне тоже пока не всё нравится!!!

39. Очень много букв!

41. Дай хоть забенчим!

43. Как “правильно” бенчмаркать
• На оценку 3 = берем разные системы, делаем к ним
одинаковый запрос, сравниваем время
• На оценку 4 = повторяем запрос N раз, считаем
среднее время, чтобы кеш прогрело и не дрожало
• На оценку 5 = выкидываем 1й прогон всегда и даже
выкидываем outliers, считаем среднее без них

45. Тёплое != мягкое
• Где ошибка?
• “берем разные системы, делаем к ним одинаковый
запрос”…
• Одинаковый запрос
• ОДИНАКОВЫЙ ЗАПРОС

46. Marketing-driven defaults 1
• “Одинаковый запрос” по умолчанию очень разный
• Sphinx, поиск по умолчанию = strict-AND, “среднее”
proximity+bm15 ранжирование, анализ позиций
• Lucene, поиск по умолчанию = OR (вроде), “легкое”
bm25 ранжирование, почти булев поиск
• Xapian (внезапно!) = top-N по ихнему bm25!!!
• …и это еще цветочки!!!

47. Marketing-driven defaults 2
• Повторные запросы?
• Sphinx = честно вычисляем всё заново, кешируется
только дисковое чтение, да и то на уровне OS
• Lucene = на всех уровнях есть внутренние кеши,
некоторые невозможно отключить никак
– Нужна долбежка многими разными запросами
– Повтор 1 запроса подряд = обмеряем отдачу из кеша
– Повтор пакета из 10-20 запросов = в общем-то тоже

48. Marketing-driven defaults 3
• Сниппеты, прям шедевр!
• “А чё у вас в N раз медленнее, чем Solr?”
– Поддержка синтаксиса VS bag-of-words
– Произвольный текст VS только преиндексированный
– И ключевая “оптимизация” Solr...
– Зачем подсвечивать всё, если можно первые 64 KB?!

49. Мы на горе всем буржуям
• Поломаем совместимость!!!
• Но исправим дефолты 

50. Что делать-то?

51. Так как выбирать-то?!!!
Все кандидаты...
…хороши!

52. Идеальная Ситуация
• Определяем реальные ключевые требования
• Слегка изучаем все сравниваемые системы (увы!)
• Делаем действительно сходные запросы
• Моделируем боевую нагрузку, помним про кеши
• Смотрим функционал (что реально критично?)
• Прикидываем TCO

53. Помним Общие Моменты
• База = забудь про функционал и скорость, но удобно
• Sphinx, Lucene et al = ср. быстро и функционально; по
разным виды запросов могут сильно отличаться
– Несколько разный функционал и, похоже, “фокус”
– Сравнивать и мерить нужное, иначе (уже+пока) никак
• Коммерческие = неожиданные подвохи, TCO
• Дефолтные настройки могут удивить

54. Делаем Правильный Выбор
• Выбираем систему X, т.к.
– Друг Вася пользуется!
– Знакомый Петя хвалил!
– На Хабре чота писали вроде крутое!
– В компанию пришел интерн с опытом! (делал homepage)
• Выбираем систему Y, т.к.
– Она дорогая от известного мега-производителя
– И деньги очень нужны имеет убедительные плюсы

55. Вопросы?
Для стеснительных:
shodan@sphinxsearch.com