Презентация на тему: Очевидное – невероятное (Sphinx tips-n-tricks)

Слово Sphinx похоже на search Слово Sphinx похоже на search Потому что такое же количество букв Бесплатный, открытый поисковой движок Специально обучен индексировать БД Специально обучен искать по тексту Еще умеет исполнять SQL-style запросы (не специально, само приползло)

Обзор – скучно! Обзор – скучно! Документация – скучно! Внутренняя архитектура – тоже скучно! См. доклад и видео с PHPconf’08 См. доклад с Highload’08 без ++ Поэтому…

Как иногда можно ускорить индексацию MySQL Как иногда можно ускорить индексацию MySQL Как иногда нужно замедлять индексацию Как индексировать результат работы MySQL SP Как бороться с MyISAM locks Как бороться с расходом памяти PgSQL client Как правильно обновлять версию в бою Как делать всякое со строками, не имея строк Как искать точные совпадения формы (а не стема) Как искать точные совпадения слова (а не маски) Как ранжировать полные совпадения поля повыше Как эмулировать regexp для wordforms Как искать по индексам с разными схемами Как и зачем делать SQL-style запросы Как искать связанные (related) документы Как делать исправление опечаток (suggestions) Как все это не делать

Заставляем протокол сжимать данные Заставляем протокол сжимать данные mysql_connect_flags=32 До +20% к общему (!) времени на 100 Mbps линке Может навредить на 1 Gbps линке Отключаем query cache sql_query_pre = SET SESSION query_cache_type=off Переносим UNCOMPRESS на клиент (0.9.9+) unpack_mysqlcompress = bodyc

Тормозим выборки Тормозим выборки Понаехали тут, DB сервер не резиновый! sql_ranged_throttle=100 Тормозим indexer IO max_iops=40 # типичный винт успевает ~100 max_iosize=1048576 # для эстетов

Опять магические флажки в протоколе: mysql_connect_flags=131074 Опять магические флажки в протоколе: mysql_connect_flags=131074 См. mysql_com.h CLIENT_MULTI_STATEMENT = 65536 CLIENT_MULTI_RESULTS = 131072 CLIENT_FOUND_ROWS = 2 Почему работает? Видимо, такие процедуры…

SELECT * FROM table – это удар в солнечное SELECT * FROM table – это удар в солнечное Понятное решение sql_query_range = 1000 sql_query = SELECT … WHERE id>= $start AND id<=$end Надо помнить – это НЕ число строк! При сквозной нумерации бывает интересно

SELECT * FROM table – это удар в мозг (RAM) SELECT * FROM table – это удар в мозг (RAM) Причина другая – мощный дизайн клиента Норовит вынуть ВЕСЬ result set сразу Понятное решение sql_query_range = 1000

Sphinx давно и успешно обратно совместим Sphinx давно и успешно обратно совместим Умеет читать старые конфиги Умеет читать старые индексы Умеет говорить со старыми клиентами API давно не меняется (планируем на 2009й) Но даже титановый шарик можно сломать

Обновить и перезапустить agent searchd(s) Обновить и перезапустить agent searchd(s) Обновить и перезапустить master searchd Обновить indexer Обновить API … PROFIT!!!

…не имея поддержки строковых атрибутов? …не имея поддержки строковых атрибутов? А что значит работать? Искать точное совпадение (WHERE str=‘abc’) Сортировать (ORDER BY str) Группировать (GROUP BY str)

Все, кроме сортировки, можно делать с CRC Все, кроме сортировки, можно делать с CRC Коллизии? MD5 + sql_attr_bigint (0.9.9+) Сортировать можно по sql_attr_str2ordinal Но сломается при UNION индексов в рантайме Сортировать можно по первым N байтам Но зорко следить за collation

В случае индексов со стеммингом? В случае индексов со стеммингом? 0.9.8 – делаем 2 индекса и… dog | (_iamexact “dog jump”) 0.9.9+ – опция index_exact_words dog | “=dog =jump” dog | “dog =jump”

В случае prefix/infix индексов? В случае prefix/infix индексов? Вариант 1. Магия в запросе highload | *highload* Вариант 2. Два индекса (но поможет, только если все слова совпали) $client->SetIndexWeights ( … ); Вариант 3. Дописать спец-фичу

Вариант 1. CRC32 + expr sort Вариант 1. CRC32 + expr sort $cl->SetSortMode ( SPH_SORT_EXPR, “@weight+IF(fieldcrc=XXX,1,0)” ) Вариант 2. Добавить маркеры $cl->Query ( “_begin test query _end” ); Удар по скорости, тк. _begin/_end будут везде Вариант 3. Дописать спец-фичу

Sphinx умеет wordforms Sphinx умеет wordforms Но вы НЕ ХОТИТЕ, чтобы там были regexes

Однако иногда вы таки хотите regexes Однако иногда вы таки хотите regexes eeeeeeeek -> eek, hiiiiiiiighload -> highload Или разные варианты записи SKU Кошерно – предобработка вне Sphinx Можно при индексации, см. xmlpipe2 Но лучше при вставке в базу (меньше нагрузка при индексации)

Т.е. одновременно искать по индексам с разными схемами? Т.е. одновременно искать по индексам с разными схемами? Минимизация схемы результата – вернет атрибуты, которые есть во всех индексах Фильтры по несуществующим атрибутам – будут тихо подавлены (subject to fixes)

Поиск по несуществующим полям – вернет ошибку, но Поиск по несуществующим полям – вернет ошибку, но Если запрос начинается с @@relaxed – “невозможные” части будут отброшены @title hello @author vasya @@relaxed @title hello @author vasya

А, главное, зачем? А, главное, зачем? Иногда быстрее, чем база (см. селективность) Иногда удобнее размазать по ядрам/машинам Запрос – пустая строка (форсирует full scan) Индекс – должен быть с docinfo=extern Фильтры/сортировка/группировка по вкусу

Когда можно, отключайте ранжирование Когда можно, отключайте ранжирование $client->SetRankingMode ( SPH_RANK_ NONE ); Используйте ключевые слова вместо фильтров для высоко-селективных фильтров $client->Query ( “_authorid123” ); Не используйте для низко-селективных! Не злоупотребляйте max_matches Аккуратнее с группировкой, она намеренно неточная, когда групп много (для скорости)

Пункт 13 – это и было “вкратце про тюнинг” Пункт 13 – это и было “вкратце про тюнинг”

Серебряной пули нет, только мелкая дробь Серебряной пули нет, только мелкая дробь Можно искать title и использовать кворум “Red Hat chases Redmond with HPC play”/3 Порог кворума выбирать ревчутьем Можно выбирать “интересные” слова Red Hat Redmond HPC

Интересные слова поможет выбирать BuildKeywords() – вернет статистику Интересные слова поможет выбирать BuildKeywords() – вернет статистику Можно анализировать статистику во времени, отдельными запросами (zeitgeist) Можно склеивать синонимы wordforms-ами Redmond > Microsoft Sphinx в целом (пока?) не коробочное решение, однако – поможет, чем сможет

Или “когда не хватает aspell” Или “когда не хватает aspell” Иногда хочется по локальному словарю Что советовать на слово Camara? В английском словаре, наверное, Camera На авто-сайте, наверное, Camaro (Chevrolet) В списке русских городов, наверное, Samara В бразильском yellow pages, наверное, ничего!

Построить личный частотный словарь Построить личный частотный словарь indexer --buildstops dict.txt 1000000 --buildfreqs Затем искать слова в нем Например, сделать словарь для aspell Например, обыскивать биграммы и триграммы Тем же Sphinx? Учитывать частоты, по ним сортировать

Есть секретный код, привожу PHP вариант Есть секретный код, привожу PHP вариант (*) или http://sphinxsearch.com/contact.html

Как работает поиск? Как работает поиск? Для каждого локального индекса Строим список кандидатов Фильтруем (аналог WHERE) Ранжируем (считаем веса документов) Сортируем (аналог ORDER BY) Группируем (аналог GROUP BY) Склеиваем результаты по всем индексам

Построение списка кандидатов Построение списка кандидатов 1 ключевое слово – 1+ IO (список документов) Булевы операции над списками документов Стоимость пропорциональна (~) длине списков Т.е., сумме частот всех ключевых слов При поиске фраз итп, еще и операции над списками позиций слов – более 2x IO/CPU Мораль “The Who” – очень плохая музыка

Дефолтный режим хранения, docinfo=extern Дефолтный режим хранения, docinfo=extern Атрибуты хранятся в отдельном файле (.spa) Загружаются в RAM при старте searchd Хэш по docid и затем бинарный поиск Фильтры перебираются линейно Стоимость ~ числу кандидатов, умноженному на число фильтров

Прямая – зависит от ранкера Прямая – зависит от ранкера SPH_RANK_NONE вообще ничего не стоит SPH_RANK_DEFAULT учитывает позиции слов, дорого Стоимость ~ числу результатов Косвенная – наводится в сортировке Важно для бенчмарков

Стоимость ~ числу результатов Стоимость ~ числу результатов Еще зависит от критерия сортировки Документы придут в порядке @id asc Поэтому по @id asc очень дешево сортировать! Еще зависит от max_matches Чем больше, тем хуже 1-10K нормально, 100K много, 10-20 мало

Где можно, ранжируйте попроще Где можно, ранжируйте попроще Сортировка не по весу? Ранжировать не надо Можно вкомпилировать ф-ю сортировки См. src/sphinxcustomsort.inl + @custom Можно (редко) оптимизировать сортировку Например, если есть корреляция между @id и timestamp

Вместо высоко-селективных (“редких”) фильтров – делайте ключевые слова Вместо высоко-селективных (“редких”) фильтров – делайте ключевые слова Вместо низко-селективных (“частых”) ключевых слов – делайте фильтры Benchmark, benchmark, benchmark

Мульти-запросы Мульти-запросы Всегда экономит round-trip Иногда оптимизируются внутри Особо частый случай – когда отличаются только режимы сортировки/группировки Это, кстати, как раз т.н. “фасеточный” поиск

Конечно Конечно Конечно, НЕТ partitioning, cutoff, max_query_time, block level rejects, index level rejects… consulting (да, это самореклама) Вот теперь у нас точно кончилось время