Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,131 views

Published on

Доклад Андрея Аксенова на HighLoad++ 2014.

Published in: Internet
  • Be the first to comment

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

  1. 1. Выбираем поиск умом головы Андрей Аксёнов, Sphinx
  2. 2. Про что доклад • Надо поиск, какой взять? – Дык в MySQL/Postgres/Mongo чота типа есть и агонь – Взять Sphinx, C++ не подведёт – Взять Lucene/Solr/Elastic, Java не подведёт – Самим всё написать, мы ж мужики – Купить крутейший коммерческий, например
  3. 3. Про что доклад • Надо поиск, какой взять? • Чем и как MySQL vs Postgres vs Mongo vs Sphinx vs Lucene vs … оно всё внутри вообще отличается? • Как правильно бенчмаркать? • Что ещё нужно сравнивать?
  4. 4. Про что доклад • Надо поиск, какой взять? – Разумеется, Sphinx! – Разумеется, с контрактом на поддержку! – Разумеется, чем больше нулей, тем лучше! – Всё, доклад окончен, расходимся
  5. 5. Варианты – в порядке усложнения
  6. 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. 7. Самописный поиск за 1 вечер • Можно даже успеть вкрутить еще всякое! – Стеммер, libstemmer и его порты – Морфология, pyrmophy2, phpmorphy (aot нельзя) – Ранжирование, BM25 • alter table X add column termfreq integer • create table D (keyword varchar(255), docfreq integer) • select …
  8. 8. Встроенный в базу поиск • Согласно вендору базы, Дичайше Круче Всех • На самом деле, Неизбежно Выйдет Говнецо (*) – Все базы в первую очередь про OLAP, ох – Великие Древние ещё также умеют транзакции, ууух – Типично муторно масштабировать – Синтаксис, ранжирование, эффективность? Не, не слышали (*) Разумеется, именно Ваш Любимый Вендор не такой!
  9. 9. Самописный поиск за 10 лет • Можно успеть вкрутить ещё всякое!!! – Внятный формат индекса – Поддержка атрибутивки – Синтаксис запросов – Ранжирование – Кластеризация • Каждый пункт = N переделок, M лет
  10. 10. Внешний поиск • FOSS (free, open source) – Sphinx – Lucene + сервера поверх (Solr, Elastic) • Коммерческие – FAST, Endeca, Autonomy, Verity… куча вендоров – Отдельный мир, обязательно Sharepoint и 4-5 нулей – Интеграция, поддержка, функционал часто хтонические
  11. 11. Так своё писать или как!? • Как ни странно, иногда надо – Core product (Google, Yandex, Bing…) – Спецтребования (“хочу взлетать в 16 KB памяти…”) • Ключевое, осознавать масштаб бедствия – У нас вот получается довольно компактно – Sphinx 0.1 = ~1K LOC, Sphinx 2.x = ~120K LOC – Больше фичей и-или “сопливый” код = ~1..10M+ LOC
  12. 12. Так своё писать или как!? • 99%, что вам – не надо – Мало усилий => так себе и получится – Много усилий => это зачем? • Берите базу, берите Sphinx, берите Lucene & spawn • Бегите от “заказчиков”, у которых нету $10 на VPS!!!
  13. 13. На что смотреть?
  14. 14. А чем НеСвои отличаются-то? • Ууу… • Отличаются метод доставки данных; форматы индекса; скорость индексации; размеры индекса; требования к RAM; механизмы масштабирования; API доступа; функционал текстового поиска; скорость текстового поиска, причем от вида запроса; скорость НЕтекстового поиска; добавочные функции (геопоиск, фасеты, подсказки, сниппеты); ранжирование; расширяемость…
  15. 15. Отличается ВСЁ!!!
  16. 16. Но, хорошие новости!
  17. 17. Отличия в массе…
  18. 18. ПОФИГУ!!!
  19. 19. Что сравнивать? • Сравнивать надо фактически важное – Не умеют не только лишь все – Мало кто может это делать • У каждого свои требования, они ортогональны – Качество поиска VS супербыстрый булев поиск? – Текстовый поиск VS атрибутивка? – Масштабирование на терабайты VS индекс на 1 GB?
  20. 20. Про отличия чуть подробнее • Совсем подробно нельзя – уйдет 3 дня • Поэтому – очень кратко, по верхам • 3 категории = (1) базы, (2) FOSS, (3) commercial • 4 мегаоси = (1) эффективность, (2) функционал, (3) масштабируемость, (4) интеграция
  21. 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. 22. Правильно читаем таблицу • Типичная база = хреновенькие скорость, функционал, масштабируемость… зато отличная интеграция! • Типичный FOSS = хорошо или отлично С/Ф/М; интеграция окей (но очевидно хуже встроенного) • Commercial = возможны адовые попадосы по любому параметру за свои же деньги, в целом не впечатляет • DIY = в общем будет очень плохо; но в частностях, возможно, невероятно хорошо
  23. 23. Внутренние различия, Sphinx vs Lucene
  24. 24. Sphinx vs Lucene • Поговорим немного про “а что внутри” • Какие сходства, откуда растут отличия • Sphinx = сервер, C++ (библиотека “как бы” есть) • Lucene = библиотека, Java • Solr = сервер, Java • Elastic = сервер, Java
  25. 25. Sphinx 2.x vs 3.x • Долго делаем, всякому научились • Теперь переделываем внутри много всего • Некоторые переделки Поменяют Всё, поэтому!
  26. 26. Sphinx vs Lucene • Что одинаковое? – Идеология “инвертированный файл” – Всё начинается от текстового поиска – Отдельно довески про атрибутивку • Что это значит? – “Тупо поиск” работает принципально одинаково – Детали реализации, однако, могут менять всё
  27. 27. Sphinx vs Lucene • Что разное внутри? – Формат хранения ключевиков, постингов – Формат хранения атрибутов – “Привычки” внутреннего кеширования – “Фокус” матчилки • Что это значит?
  28. 28. Про формат постингов • Sphinx 2.x = общие словари, списки по всем полям • Lucene = отдельные по каждому полю – Матчинг в “редком” поле = Lucene “О-быстрее” – Матчинг по куче полей = Lucene “О-медленнее” – Матчинг со взвешиванием = Lucene “О-медленнее” – Нумерация полей = Sphinx 2.x ограничен 256 полями, индекс “О-больше” по размеру – Куча полей, куча уникальных “слов” = плохо везде (словарь)
  29. 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. 30. Про формат документов • Lucene = хранилка документов есть • Sphinx 2.x = хранилки документов нет • Sphinx 3.x = хранилка документов тоже есть – Тоже перерастаем в странную СУБД – Тоже disk based, тоже LZ4 – Принципиально улучшить не удалось
  31. 31. Про кеширование • Sphinx = запрос надо уметь считать адово быстро • Lucene = скорость вторична, всё закешируем! – Sphinx = внутренних кешей почитай нет  – Lucene = кешируется ВСЁ, местами хрен отключишь – Делать адекватные бенчмарки это местами АД • Xapian (внезапно) = оптимизация под дефолтный, непрактичный юзкейс
  32. 32. Про “фокус” матчилки • Sphinx 2.x = позиции! ранжирование! релевантность! фиксированный бюджет памяти! • Lucene = не-не-не, булев матчинг и может BM25; памяти побольше тупо ставь – Sphinx 2.x = неидеально c булевым поиском – Sphinx 3.x = думаем про отдельный lightweight code path… и убрать бюджетирование, муахахаха – Lucene = неидеально с ранжированием/позициями
  33. 33. Итого • Концептуально одинаково (инвертированный файл) • Довольно разные реализации • “Детали реализации” меняют всё, в разы
  34. 34. Внешние различия
  35. 35. Что на этаж выше? • Sphinx vs Solr/Elastic, что одинаковое? – Везде некий API (SphinxQL, REST/XML, REST/JSON) – Везде завелись RT индексы – Везде развелся schemaless/JSON (в разной мере) – Везде как минимум агрегация результатов с кластера – Везде поддержка атрибутивки, ряда допфункций – Везде, что странно, “просто поиск” как-то работает!!! – Коммодитизация…
  36. 36. Что на этаж выше? • Sphinx vs Solr/Elastic, что разное? – S/E, репликация, автошардинг, REST, “реверсные” поиски, менеджмент кластера (почти всё тоже делаем для 3.0) – Sphinx, встроенная морфология, “сложное” ранжирование, считалка выражений • Всегда разный “эзотерический” (?) функционал – Sphinx, плохо помню! Zones, blend_chars, итп? – S/E, плохо знаю! Per-field mappings, nested docs итп?
  37. 37. Так где идеал?
  38. 38. Идеала нет!!! • Мне не нравится, как устроен Sphinx 2.x • Мне не нравится, как устроен Lucene • И в Sphinx 3.0 мне тоже пока не всё нравится!!!
  39. 39. Очень много букв!
  40. 40. Дай хоть забенчим!
  41. 41. Как “правильно” бенчмаркать • На оценку 3 = берем разные системы, делаем к ним одинаковый запрос, сравниваем время • На оценку 4 = повторяем запрос N раз, считаем среднее время, чтобы кеш прогрело и не дрожало • На оценку 5 = выкидываем 1й прогон всегда и даже выкидываем outliers, считаем среднее без них
  42. 42. Тёплое != мягкое • Где ошибка? • “берем разные системы, делаем к ним одинаковый запрос”… • Одинаковый запрос • ОДИНАКОВЫЙ ЗАПРОС
  43. 43. Marketing-driven defaults 1 • “Одинаковый запрос” по умолчанию очень разный • Sphinx, поиск по умолчанию = strict-AND, “среднее” proximity+bm15 ранжирование, анализ позиций • Lucene, поиск по умолчанию = OR (вроде), “легкое” bm25 ранжирование, почти булев поиск • Xapian (внезапно!) = top-N по ихнему bm25!!! • …и это еще цветочки!!!
  44. 44. Marketing-driven defaults 2 • Повторные запросы? • Sphinx = честно вычисляем всё заново, кешируется только дисковое чтение, да и то на уровне OS • Lucene = на всех уровнях есть внутренние кеши, некоторые невозможно отключить никак – Нужна долбежка многими разными запросами – Повтор 1 запроса подряд = обмеряем отдачу из кеша – Повтор пакета из 10-20 запросов = в общем-то тоже
  45. 45. Marketing-driven defaults 3 • Сниппеты, прям шедевр! • “А чё у вас в N раз медленнее, чем Solr?” – Поддержка синтаксиса VS bag-of-words – Произвольный текст VS только преиндексированный – И ключевая “оптимизация” Solr... – Зачем подсвечивать всё, если можно первые 64 KB?!
  46. 46. Мы на горе всем буржуям • Поломаем совместимость!!! • Но исправим дефолты 
  47. 47. Что делать-то?
  48. 48. Так как выбирать-то?!!! Все кандидаты... …хороши!
  49. 49. Идеальная Ситуация • Определяем реальные ключевые требования • Слегка изучаем все сравниваемые системы (увы!) • Делаем действительно сходные запросы • Моделируем боевую нагрузку, помним про кеши • Смотрим функционал (что реально критично?) • Прикидываем TCO
  50. 50. Помним Общие Моменты • База = забудь про функционал и скорость, но удобно • Sphinx, Lucene et al = ср. быстро и функционально; по разным виды запросов могут сильно отличаться – Несколько разный функционал и, похоже, “фокус” – Сравнивать и мерить нужное, иначе (уже+пока) никак • Коммерческие = неожиданные подвохи, TCO • Дефолтные настройки могут удивить
  51. 51. Делаем Правильный Выбор • Выбираем систему X, т.к. – Друг Вася пользуется! – Знакомый Петя хвалил! – На Хабре чота писали вроде крутое! – В компанию пришел интерн с опытом! (делал homepage) • Выбираем систему Y, т.к. – Она дорогая от известного мега-производителя – И деньги очень нужны имеет убедительные плюсы
  52. 52. Вопросы? Для стеснительных: shodan@sphinxsearch.com

×