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)

8,982 views

Published on

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

Published in: Engineering
  • Be the first to comment

Как устроен поиск / Андрей Аксенов (Sphinx)

  1. 1. Как устроен поиск Андрей Аксенов, Sphinx v.2.0
  2. 2. Поиск устроен вот так • Сначала индексация • Потом поиск • Ставить, конечно, Sphinx + мегаконтракт на поддержку • Всё, расходимся
  3. 3. Поиск устроен вот так • Индексация – Берем документы – Извлекаем ключевые слова – Строим спецструктуру, FT index • Поиск – Берем запрос, ищем по спецструктуре – Допобработка (where/order/group, кластер, реранжирование, …)
  4. 4. Данные решают все • FT index = – Словарь – Списки документов – Списки позиций – Формат хранения этого всего
  5. 5. А вот наноиндекс • Словарь + списки документов: Абыр => [ 123 ] Валг => [ 123 ] Васечкин=> [ 7, 40, 42, 1917, … ] Вася => [ 3, 141, 592, 653, … ] Петров => [ 1, 2, 3, 5, 8, 13, … ] Петя => [ 2, 4, 8, 16, … ]
  6. 6. Данные решают все • Элемент словаря на самом деле = – Слово – Указатель на документы/позиции • Или инлайн данные – Дополнительная метаинформация • Или никакой – Например, w=“Абыр”, docoff=1234, posoff=5678, ndocs=12, nposs=72, fieldmask=3, …
  7. 7. Данные решают все • Словарь = – Обычно сортированный вектор • Круто хеш, но прощай, поиск подстрок – Обычно пожат • Абыр, Абырр, Абыррр, Абырвалг! – Эффективно с инлайнигом • Зачем ndocs=1 docsoff=1234, если можно сразу docid=9876?! – Оп, и вот сразу детали ретализации
  8. 8. Данные решают все • Документы и позиции – Всегда сортированы (иначе не пересечь) Васечкин => [ 7, 40, 42, 1917, … ] Вася => [ 3, 141, 592, 653, … ] – Обычно пожаты (отдельная поднаука) – Хранятся и отдельно и вперемешку – Плюс спецфокусы! (Маски полей, битмапы, плоская нумерация, итд итп)
  9. 9. Данные решают все • Lucene = docids, tfs, postings • Sphinx 2 = docids+meta, postings • Sphinx 3 = ??? docids+postings • Google, Yandex, … = ??? 
  10. 10. The fuck we care?! • СКОРОСТЬ блин (и объем еще) • Например, “что” => [1,3,4,5,6,10,11,…] varint => [1,2,1,1,1,4, 1,…] x 8 bit gvi/pfd => [0,1,0,0,0,3, 0,…] x 0..2 bit • Про 0 bit тащемта не шутка!(Хотя такое щщасье случается оч редко)
  11. 11. Текста мало, дайте цифер • Еще есть атрибуты • Бывают schemaful, schemaless • Хранить можно как угодно, все знают – “relational”, JSON text, BSON, … • Lucene = ФлексиТормоз!!! – По меньшей мере, была и по дефолту • Sphinx = АдскаяСмесь!!! – relational + SphinxBSON
  12. 12. А к цифрам - еще цифер!!! • Атрибуты можно хранить – Тупо – Менее тупо • Со схемой: построчно, колоночно • Без схемы: K-V, иерархия, сжатие • Индексы: никаких, эмуляция, родные
  13. 13. А что еще (м.Строгино!!!) • Про ранжирование • Про сегменты и весь реалтайм • Про еще отличия физики S vs L • Про разницу подходов к снаряду • Про как бенчить надо, а как будут • Про жопки в реализациях – Как зажигал [abc*] • Плюс должно быть слово КЛАСТЕР
  14. 14. Про ранжирование • Если не нужно, ура, булев матчинг • Если лёгкое, BM25 (у нас +proximity) • Простая формула, ДВЕ переменные – TF, IDF по словам; плюс avg_doc_length • Если тяжёлое, всё весело – Например, 20 переменных. Или 800.
  15. 15. Про сегменты и весь RT • Как устроен т.н. “реалтайм”? (здесь короче картинка такая с лысым писюном из Матрицы и типа гнутой ложкой - ну хоть не дырявой, бггг) • Его нету, есть create/merge/purge • Sphinx еще умеет update атрибутивки
  16. 16. И еще про разную физику • Sphinx vs Lucene чота волнует всех • Концептуально все одинаково, но • Разные форматы индекса, атрибутов • S = общие словари, L = по полям • S = таблица атрибутов в памяти, L = документы на диске и кешкешкеш • S = микс schemaful/less, L = вроде только less
  17. 17. Про подходы к снаряду – (плюс детали реализации, ага) • S = надо все уметь быстро считать • L = надо уметь отдавать из кеша!!! • S = позиции, фикс RAM, итд итп • L = ненене, булев и BM25 и кеш/RAM • S = плохо, хрен включишь кеш • L = плохо, хрен сделаешь бенчмарк • Внезапно история про Xapian!!!
  18. 18. Про жопки в реализации • Здесь внезапная история про [abc*] и про старые версии – СЕГОДНЯ ВЕЗДЕ ВСЕ НОРМАЛЬНО • Старый Lucene жог, full scan словаря • Старый Sphinx жог, безлимитный expansion и “везде мелкие” буфера
  19. 19. Про как надо бенчить • На оценку 3 = разные системы, одинаковый запрос, смотрим время • На оценку 4 = повторяем запрос N раз, считаем среднее время, чтобы кеш прогрело и не дрожало • На оценку 5 = выкидываем 1й прогон всегда и даже выкидываем outliers, считаем среднее без них
  20. 20. Тёплое != мягкое • Где ошибка? • “берем разные системы, делаем к ним одинаковый запрос”… • Одинаковый запрос •ОДИНАКОВЫЙ ЗАПРОС, КАРЛ!
  21. 21. Marketing driven defaults 1 • Sphinx = типа быстрое strict-AND, зато medium rare proximity+bm15 ранжирование • Lucene = типа медленное OR, зато lightweight bm25 ранжирование • Xapian!!! • …и это еще цветочки!!!
  22. 22. Marketing driven defaults 2 • Повторные запросы? • Sphinx (*) = честно вычисляем всё заново, кешируется только дисковое чтение, и то у OS • Lucene = на всех уровнях есть внутренние кеши, некоторые невозможно отключить никак
  23. 23. Marketing driven defaults 3 • Сниппеты, прям шедевр! • “А чё у вас в N раз медленнее, чем Solr?” – Поддержка синтаксиса VS bag-of-words – Произвольный текст VS только преиндексированный – И ключевая “оптимизация” про 64KB!
  24. 24. Слово КЛАСТЕР похоже… • И тут внезапно такое м.Строгино
  25. 25. Итого
  26. 26. Вопросы? для стеснительных: shodan@sphinxsearch.com

×