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

Dd3f18c87b851137000c7427d7bd5d32?s=47 fwdays
November 18, 2014

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

Dd3f18c87b851137000c7427d7bd5d32?s=128

fwdays

November 18, 2014
Tweet

Transcript

  1. Выбираем поиск умом головы Андрей Аксёнов, http://sphinxsearch.com/ v.1.1, PHP Frameworks

    Day Kiev, 2014
  2. Про что доклад • Надо поиск, какой взять? • Дык

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

    и как DB-built-in 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* • Это экспертные оценки • Привычная со школы шкала от 1 до 5 • Получены методом ковыряния пальцем в носу • Нос был мой
  22. Правильно читаем таблицу • Типичная база • всегда хреновенькие скорость,

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

    любому параметру – это за свои же деньги • в целом не впечатляет • DIY • в общем (для всех задач) будет очень плохо • но в частностях, возможно, невероятно хорошо • хочешь круто угореть – спроси меня как!
  24. Внутренние различия Sphinx vs Lucene

  25. Sphinx vs Lucene • Поговорим немного про “а что внутри”

    • Какие сходства, откуда растут отличия • Sphinx = сервер, C++ • библиотека “как бы” есть • Lucene = библиотека, Java • Solr = сервер, Java • Elastic = сервер, Java
  26. Sphinx 2.x vs 3.x • Долго делаем, всякому научились •

    Теперь переделываем внутри много всего • Некоторые переделки Поменяют Всё, поэтому!
  27. Sphinx vs Lucene • Что одинаковое? • Идеология “инвертированный файл”

    • Всё начинается от текстового поиска • Отдельно довески про атрибутивку • Что это значит? • “Тупо поиск” работает принципально одинаково • Детали реализации, однако, могут Менять Всё
  28. Детали Меняют Всё • Пример, пока не забыл: поиск подстрок

    • Sphinx 1.x, преиндексируем всё • Sphinx 2.0, expansion с индексами • Sphinx 3.0, думаем про гибрид • Lucene ?.?, expansion без индексов • Lucene 4.?, expansion с индексами • Разница в скорости в 100 (сто) раз? Легко • Разница в памяти? Привет, “Журавлёв”
  29. Sphinx vs Lucene • Что разное внутри? • Формат хранения

    ключевиков, постингов • Формат хранения атрибутов • “Привычки” внутреннего кеширования • “Фокус” матчилки • Что это значит?
  30. Про формат постингов • Sphinx 2.x = общие словари и

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

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

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

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

    фиксированный бюджет памяти! • Lucene = не-не-не, булев матчинг и может BM25; памяти побольше тупо ставь • Sphinx 2.x = неидеально c булевым поиском • Sphinx 3.x = думаем про отдельный lightweight path… и убрать бюджетирование, муахахаха • Lucene = неидеально с ранкингом, позициями
  35. Итого • Концептуально одинаково (инвертированный файл) • Довольно разные реализации

    • Детали реализации иногда меняют всё, причем в разы
  36. Внешние различия

  37. Что на этаж выше? • Sphinx vs Solr/Elastic, что одинаковое?

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

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

  40. Идеала нет! • Мне не нравится, как устроен Sphinx 2.x

    • Мне не нравится, как устроен Lucene • И в Sphinx 3.0 мне тоже пока (?) не всё нравится!!!
  41. Очень много букв!

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

  44. None
  45. Как “правильно” бенчмаркать • На оценку 3 = берем разные

    системы, делаем к ним одинаковый запрос, сравниваем время • На оценку 4 = повторяем запрос N раз, считаем среднее время, чтобы кеш прогрело и не дрожало • На оценку 5 = выкидываем 1й прогон всегда и даже выкидываем outliers, считаем среднее без них
  46. None
  47. Тёплое != мягкое • Где ошибка? • “берем разные системы,

    делаем к ним одинаковый запрос”… • Одинаковый запрос •ОДИНАКОВЫЙ ЗАПРОС
  48. Marketing-driven defaults 1 • “Одинаковый запрос” очень разный • Sphinx

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

    считаем всё заново, кешируется только read(), и тот внутриOS • Lucene = на всех уровнях внутренние кеши, некоторые не отключить никак – Нужна долбежка многими разными запросами – Повтор 1 запроса подряд = обмеряем кеш – Повтор 10-20 запросов = в общем-то тоже
  50. Marketing-driven defaults 3 • Сниппеты, прям шедевр! – “А чё

    у вас в N раз медленнее, чем Solr?” – Sphinx, поддержка синтаксиса / Solr, тупорылый bag-of-words – Sphinx, произвольный текст / Solr, только преиндексированный – И ключевая “оптимизация” Solr... – Зачем честно подсвечивать всё, если можно быстро первые 64 KB?!
  51. Мы на горе всем буржуям • Поломаем совместимость!!! • Но

    исправим дефолты  • Учитесь на моих ошибках, кстати
  52. Что делать-то?

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

  54. Идеальная Ситуация • Определяем реальные ключевые требования • Слегка изучаем

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

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

    – Зато удобно (ничего не надо делать!!!) • Sphinx, Lucene et al = – Ср. быстро и функционально – Разные виды запросов могут сильно отличаться – Разный функционал и, похоже, “фокус” – Мерить нужное, иначе (уже+пока) никак
  57. Помним Общие Моменты • DIY = – Бюджетировать лучше бы

    годы – Результат может быть любой • Коммерческие = – Неожиданные подвохи везде – Хтоническая интеграция и поддержка – Шмотка +X к TCO, но зато +Y к откату • Дефолтные настройки могут удивить, везде
  58. И... делаем Правильный Выбор! • Выбираем систему X, т.к. –

    Друг Вася пользуется и Петя ещё хвалил! – На Хабре чота писали вроде крутое! – Есть интерн с опытом! (homepage) • Выбираем систему Y, т.к. – Она дорогая от известного мега-производителя – И деньги очень нужны имеет убедительные плюсы
  59. Вопросы? Для стеснительных: shodan@sphinxsearch.com