Sphinx и его применения для поиска в БД Андрей Аксенов shodan@shodan.ru. - презентация

1 Sphinx и его применения для поиска в БД Андрей Аксенов

2 Поиск в БД – зачем? Популярные СУБД недостаточно хорошо справляются с задачей поиска (в широком смысле) В частности, с полнотекстовым поиском –Скорость поиска –Скорость обновления таблицы –Релевантность В некоторых случаях, есть проблемы даже с обычными выборками –Подробности во второй части доклада

3 Поиск в БД – как? Sphinx –Система для организации полнотекстового поиска –Бесплатная –Открытая (open-source, GPL) –Изначально разработана для интеграции с БД О чем мы расскажем –Краткий обзор внутреннего устройства –Краткий обзор возможностей –Краткий обзор практических применений

4 Sphinx. Общие сведения Две основных программы –indexer, получает данные из источников (БД) и строит полнотекстовый индекс –searchd, отвечает на поисковые запросы при помощи построенных indexer-ом индексов Набор API для разных языков –Легковесные нативные клиенты к searchd –PHP, Python, Ruby, Perl, Java… SphinxSE –Встраиваемый в MySQL клиент –Storage engine для MySQL 5.0.x и 5.1.x

5 Sphinx. Терминология Документы Sphinx аналогичны записям в базе данных –Документ это набор текстовых полей и численных атрибутов плюс уникальный ID – аналог строки в таблице БД –Набор полей и атрибутов не меняется в пределах индекса – аналог таблицы в БД –По полям можно вести полнотекстовый поиск –По атрибутам можно дополнительно фильтровать, сортировать, группировать результаты поиска

6 Sphinx. Установка и использование Установка –./configure && make && make install –vi sphinx.conf –./indexer myindex –./searchd Использование –include ( sphinxapi.php ); –$cl = new SphinxClient (); –$res = new $cl->Query ( test, myindex );

7 Sphinx. Устройство индексов Полнотекстовые индексы хранятся в FS Имеют специально обученный формат Формат монолитный, обновление данных производится построением с нуля Проблема, но далеко не смертельная –Быстрая скорость индексации (4-8 MB/sec) –Partitioning индексов для снижения lag –Принципиально отсутствует фрагментация индекса –Атрибуты можно обновлять в реальном времени

8 Чуть подробнее про partitioning В простейшем случае, делаем 2 индекса для индексации одной и той же таблицы –Редко обновляемый main, содержащий основную массу данных –Часто обновляемый delta, содержащий обновления с момента последней индексации delta Зачастую, схема идеально согласуется с характером изменений данных –Форумы, блоги, mail/news архивы…

9 Источники данных В общем случае откуда угодно –Встроенные драйвера для MySQL, Postgres, XML файлов специального формата Источники разного типа можно комбинировать в одном индексе Данные для индексации поступают не из таблицы, а из выборки Т.е. можно делать дополнительную обработку в момент выборки – JOIN-ы, выбирать любой поднабор полей, итд.

10 Sphinx. Спец-возможности Помимо просто полнотекстового поиска, Sphinx умеет много гитик: –Поиск и ранжирование с учетом позиций слов и близости фраз –Произвольные атрибуты, в том числе MVA –Сортировка, фильтрация, группировка –Выдержки с подсветкой ключевых слов –Распределенный поиск –Оптимизация близких запросов –Географическое расстояние (geo-distance)…

11 Ранжирование с учетом фраз Типичный подход – ранжирование только на основании статистики по словам На больших коллекциях или не очень редких ключевых словах – работает плохо Основной фактор ранжирования Sphinx – max длина совпадения части фразы запроса с документом Точные цитаты ранжируются выше всего, качество в целом субъективно лучше Место для роста – quorums, frequencies…

12 Поддержка атрибутов Произвольное количество численных (либо 1-32 bit unsigned integer, либо float) атрибутов Необходимы для эффективной (!) фильтрации, сортировки, группировки результатов поиска Иначе (при хранении в БД), уже при K найденных документов получается неприемлемо медленно Extern, Inline, MVA

13 Сортировка и фильтрация Сортировка –По комбинации атрибутов desc, user_rank desc) –Всегда оптимизируется с учетом top-N запрошенных документов Фильтрация –До 10+ раз быстрее, чем на стороне БД –3 вида фильтров: 1) набор значений, 2) диапазон значений, 3) geodistance –Произвольное количество фильтров –Exclude-фильтры

14 Группировка Бывает интересна агрегированная информация о результатах поиска Для этого в Sphinx сделана группировка Важное отличие – может быть неточной! –Исполняется в фиксированной памяти –Между распределенными узлами передаются только агрегатные значения –На практике, можно аккуратной настройкой добиться точных значений Зачастую, абсолютная точность не важна Можно выбирать лучший элемент в группе

15 Распределенный поиск Last but not least… Распределенные индексы позволяют параллельно запускать поиск на нескольких машинах –Запустили удаленные запросы –Последовательно обыскали локальные индексы –Считали все удаленные результаты –Объединили их вместе и вернули клиенту Можно использовать для multi-core

16 Пример 1.1. Просто поиск Mininova.org Заменили MySQL FT slaves K rows, MB, 4-5 M q/day Индексируем префиксы, а не сами слова Long query tail – top-N запросов в кэше на стороне приложения (20-30% из кэша, самый частый ~1-2%) 2 сервера с полными репликами индекса Loadavg (теперь) около

17 Пример 1.2. Просто поиск Boardreader.com 1B rows, 1.5 TB, 700K-1M q/day 6 серверов, 4xCPU + 16 GB RAM TB 4 копии searchd вместо одной (startup, HA) 4 обычных HDD вместо RAID (быстрее!) Активный partitioning по времени –Отдельные индексы 1-week, 3-month, all-time Распределенное горячее обновление версии –Критична обратная совместимость –В любой момент отсутствует ~1/24 документов

18 Пример 2. Обычные выборки Sahibinden.com 400K rows, 500M, 3M q/day 99 полей, проблема с MySQL индексами Sphinx использован и для полнотекстовых поисков, и обычных выборок –Добавляется ряд keywords при индексации –Оказалось быстрее и удобнее, чем MySQL… –Частая быстрая переиндексация, 9-15 секунд раз в 1 минуту на одном из 8+ CPUs PHP API overhead стал значимым –Сделали 2 индекса, на 34 и 99 атрибутов

19 Пример 3. Группировка Boardreader.com Потребовались отчеты по ссылкам – top доменов, на/с которых ссылались, и т.п Mrows, GB data, Kq –Запросы строго с группировкой и сортировкой по COUNT / COUNT DISTINCT –Много входных rows (1-10 M), при этом небольшой result set –Абсолютная точность не требуется MySQL исполнял прототипы до 300 секунд Распараллелили при помощи Sphinx

20 Пример 3. Группировка (contd) Группировка на 6x4 CPU кластере –Параллельно с другой нагрузкой –Распределенно, быстро, почти точно Предобработка индексируемых данных –UDF для выделения всех интересных подстрок в отдельные слова Потребовались доработки –COUNT DISTINCT –64-bit ids (из-за схемы нумерации и коллизий) Место для оптимизаций –Поскольку релевантность не важна…

21 Пример 4. MVA выборки Grouply.com N миллионов сообщений, M тегов Интересные применения для MVA Официальное для фильтрации по тегам Для экономии SQL выборок –БД сильно раздроблена на несколько физических серверов –JOIN в общем случае… нелегок –MVA для агрегации (в момент индексации), хранения, возврата ряда значений

22 Выводы Sphinx, понятно, не панацея Однако, для довольно широкого круга задач – неплохой выбор Кстати, ряд возможностей остался за бортом доклада… Пробуйте! Заходите – Пишите –