Плагины ранжирования позволяют реализовать пользовательский ранжировщик, который получает все вхождения совпавших ключевых слов в документе и вычисляет значение WEIGHT(). Они могут вызываться следующим образом:

SELECT id, attr1 FROM test WHERE match('hello') OPTION ranker=myranker('option1=1');

Последовательность вызовов происходит следующим образом:

1. XXX_init() вызывается один раз на запрос для каждой таблицы, в самом начале. Ему передаются несколько опций, действующих на весь запрос, через структуру SPH_RANKER_INIT, включая строки пользовательских опций (например, "option1=1" в приведённом выше примере).
2. XXX_update() вызывается несколько раз для каждого совпавшего документа, при этом каждый раз передаётся в качестве параметра вхождение ключевого слова — структура SPH_RANKER_HIT. Вхождения внутри каждого документа гарантированно передаются в порядке возрастания значений hit->hit_pos.
3. XXX_finalize() вызывается один раз для каждого совпавшего документа, когда больше нет вхождений ключевых слов. Она должна вернуть значение WEIGHT(). Эта функция является единственной обязательной.
4. XXX_deinit() вызывается один раз на запрос, в самом конце.

Плагины фильтров токенов позволяют реализовать пользовательский токенизатор, который создает токены согласно пользовательским правилам. Существует два типа:

• Токенизатор во время индексации, объявляемый с помощью index_token_filter в настройках таблицы
• Токенизатор во время запроса, объявляемый с помощью директивы OPTION token_filter

В конвейере обработки текста фильтры токенов запускаются после базовой обработки токенизатором (которая обрабатывает текст из полей или запросов и создает из них токены).

Токенизатор во время индексации создается indexer при индексации исходных данных в таблицу или RT таблицей при обработке операторов INSERT или REPLACE.

Плагин объявляется как library name:plugin name:optional string of settings. Функции инициализации плагина могут принимать произвольные настройки, которые передаются в виде строки в формате option1=value1;option2=value2;...

Пример:

index_token_filter = my_lib.so:email_process:field=email;split=.io

Последовательность вызовов для фильтра токенов во время индексации следующая:

1. XXX_init() вызывается сразу после того, как indexer создает фильтр токенов с пустым списком полей, а затем после того, как indexer получает схему таблицы с актуальным списком полей. Должен возвращать ноль при успешной инициализации или описание ошибки в противном случае.
2. XXX_begin_document вызывается только для RT таблицы при INSERT/REPLACE для каждого документа. Должен возвращать ноль при успешном вызове или описание ошибки в противном случае. С помощью OPTION token_filter_options можно передать дополнительные параметры/настройки функции.

   INSERT INTO rt (id, title) VALUES (1, 'some text corp@space.io') OPTION token_filter_options='.io'

3. XXX_begin_field вызывается один раз для каждого поля перед обработкой поля базовым токенизатором, с номером поля в качестве параметра.
4. XXX_push_token вызывается один раз для каждого нового токена, созданного базовым токенизатором, с исходным токеном в качестве параметра. Должен возвращать токен, количество дополнительных токенов, созданных фильтром токенов, и дельту позиции для токена.
5. XXX_get_extra_token вызывается несколько раз, если XXX_push_token сообщает о дополнительных токенах. Должен возвращать токен и дельту позиции для этого дополнительного токена.
6. XXX_end_field вызывается один раз сразу после обработки исходных токенов из текущего поля.
7. XXX_deinit вызывается в самом конце индексации.

Обязательными для определения являются функции: XXX_begin_document, XXX_push_token и XXX_get_extra_token.

Токенизатор во время запроса создается при каждом поиске полнотекстового поиска для каждой задействованной таблицы.

Последовательность вызовов для фильтра токенов во время запроса следующая:

1. XXX_init() вызывается один раз для каждой таблицы перед разбором запроса с параметрами — максимальная длина токена и строка, заданная опцией token_filter

   SELECT * FROM index WHERE MATCH ('test') OPTION token_filter='my_lib.so:query_email_process:io'

   Должен возвращать ноль при успешной инициализации или описание ошибки в противном случае.

2. XXX_push_token() вызывается один раз для каждого нового токена, созданного базовым токенизатором, с параметрами: токен, созданный базовым токенизатором, указатель на необработанный токен в исходной строке запроса и длина необработанного токена. Должен возвращать токен и дельту позиции для токена.
3. XXX_pre_morph() вызывается один раз для токена непосредственно перед передачей его морфологическому процессору с ссылкой на токен и флагом стоп-слова. Может установить флаг стоп-слова, чтобы пометить токен как стоп-слово.
4. XXX_post_morph() вызывается один раз для токена после обработки морфологическим процессором с ссылкой на токен и флагом стоп-слова. Может установить флаг стоп-слова, чтобы пометить токен как стоп-слово. Должен возвращать флаг, ненулевое значение которого означает использование токена до морфологической обработки.
5. XXX_deinit() вызывается в самом конце обработки запроса.

Отсутствие функций допускается.

indextool — полезная утилита, которая извлекает различную информацию о физической таблице, исключая template или distributed таблицы. Вот общий синтаксис использования indextool:

indextool <command> [options]

Эти опции применимы ко всем командам:

• --config <file> (-c <file> для краткости) позволяет переопределить имена файлов конфигурации по умолчанию.
• --quiet (-q для краткости) подавляет вывод баннеров и подобного от indextool.
• --help (-h для краткости) отображает все параметры, доступные в вашей конкретной сборке indextool.
• -v отображает информацию о версии вашей конкретной сборки indextool.

Доступные команды:

• --checkconfig загружает и проверяет файл конфигурации, проверяя его валидность и наличие синтаксических ошибок.
• --buildidf DICTFILE1 [DICTFILE2 ...] --out IDFILE строит IDF файл из одного или нескольких дампов словарей (см. --dumpdict). Дополнительный параметр --skip-uniq пропустит уникальные слова (df=1).
• --build-infixes TABLENAME генерирует инфиксы для уже существующей таблицы dict=keywords (обновляет .sph, .spi на месте). Используйте эту опцию для устаревших файлов таблиц, которые уже используют dict=keywords, но теперь требуют поддержки инфиксного поиска; обновление файлов таблиц с помощью indextool может быть проще или быстрее, чем их пересоздание с нуля с помощью indexer.
• --dumpheader FILENAME.sph быстро выводит указанный файл заголовка таблицы без изменения других файлов таблицы или даже файла конфигурации. Отчет предоставляет подробный обзор всех настроек таблицы, особенно полный список атрибутов и полей.
• --dumpconfig FILENAME.sph извлекает определение таблицы из указанного файла заголовка таблицы в формате, (почти) совместимом с файлом manticore.conf.
• --dumpheader TABLENAME выводит заголовок таблицы по имени таблицы, при этом путь к заголовку ищется в файле конфигурации.
• --dumpdict TABLENAME выводит словарь. Дополнительный переключатель -stats добавит общее количество документов к дампу словаря. Это необходимо для файлов словаря, используемых при создании IDF файла.
• --dumpdocids TABLENAME выводит идентификаторы документов по имени таблицы.
• --dumphitlist TABLENAME KEYWORD выводит все вхождения указанного ключевого слова в заданной таблице, при этом ключевое слово задано как текст.
• --dumphitlist TABLENAME --wordid ID выводит все вхождения конкретного ключевого слова в заданной таблице, при этом ключевое слово представлено внутренним числовым ID.
• --dumpkilllist TABLENAME выводит содержимое kill-листа указанной таблицы, включая цели и флаги. Также может использоваться как --dumpkilllist FILENAME.spk.
• --docextract TBL DOCID выполняет стандартную проверку таблицы всей словарной базы/документов/вхождений и собирает все слова и вхождения, связанные с запрошенным документом. Затем все слова упорядочиваются по полям и позициям, и результат выводится, сгруппированный по полям.
• --fold TABLENAME OPTFILE Эта опция помогает понять, как токенизатор обрабатывает ввод. Вы можете передать indextool текст из файла, если он указан, или из stdin в противном случае. Вывод заменит разделители пробелами (на основе настроек charset_table) и преобразует буквы в словах в нижний регистр.
• --htmlstrip TABLENAME применяет настройки HTML-стриппера для указанной таблицы для фильтрации stdin и отправляет результаты фильтрации в stdout. Учтите, что настройки будут взяты из manticore.conf, а не из заголовка таблицы.
• --mergeidf NODE1.idf [NODE2.idf ...] --out GLOBAL.idf объединяет несколько .idf файлов в один. Дополнительный параметр --skip-uniq пропустит уникальные слова (df=1).
• --morph TABLENAME применяет морфологию к входным данным из stdin и направляет результат в stdout.
• --check TABLENAME проверяет файлы данных таблицы на ошибки согласованности, которые могут быть вызваны ошибками в indexer или аппаратными сбоями. --check также работает с RT таблицами, RAM и дисковыми чанками. Дополнительные опции:
  • --check-id-dups проверяет дубликаты идентификаторов документов в простой таблице и во всех дисковых чанках RT таблицы
  • --check-disk-chunk CHUNK_NAME проверяет только конкретный дисковый чанк RT таблицы. Аргумент — числовое расширение дискового чанка RT таблицы для проверки.
• --strip-path удаляет пути из всех имен файлов, на которые ссылается таблица (стоп-слова, словоформы, исключения и т.д.). Это полезно при проверке таблиц, собранных на другой машине с возможно отличающейся структурой путей.
• --rotate совместимо только с --check и определяет, проверять ли таблицу, ожидающую ротации, т.е. с расширением .new. Это полезно, если вы хотите проверить таблицу перед её фактическим использованием.
• --apply-killlists загружает и применяет kill-листы для всех таблиц, перечисленных в файле конфигурации. Изменения сохраняются в .SPM файлах. Файлы kill-листов (.SPK) удаляются. Это удобно, если вы хотите перенести применение таблиц с запуска сервера на этап индексирования.

indextool не может полностью проверить RT таблицу, которая в данный момент обслуживается демоном. При попытке проверить активную RT таблицу вы можете столкнуться с следующим предупреждением:

WARNING: failed to load RAM chunks, checking only N disk chunks

Чтобы избежать этих предупреждений и обеспечить корректную проверку RT таблицы, рассмотрите следующие подходы:

• остановите демон перед запуском indextool --check.
• убедитесь, что RT таблица не обслуживается демоном.
• проверьте отдельную копию RT таблицы вместо живой.

Если остановка демона невозможна, вы можете предотвратить нежелательные изменения RT таблицы, выполнив следующий MySQL-запрос перед запуском indextool --check:

SET GLOBAL AUTO_OPTIMIZE=0;

Эта команда предотвращает автоматическую оптимизацию демоном, гарантируя, что файлы RT таблицы останутся неизменными. После выполнения этого запроса дождитесь полного завершения потока оптимизации перед продолжением с indextool --check. Это гарантирует, что во время проверки не будут случайно изменены или удалены дисковые чанки. Если автооптимизация была включена ранее, вам следует вручную включить её снова после завершения проверки, выполнив:

SET GLOBAL AUTO_OPTIMIZE=1;

Команда spelldump предназначена для извлечения содержимого из файла словаря, использующего формат ispell или MySpell. Это может быть полезно, когда нужно составить списки слов для форм слов, так как она генерирует все возможные формы за вас.

Общий синтаксис выглядит так:

spelldump [options] <dictionary> <affix> [result] [locale-name]

Основными параметрами являются основной файл и файл аффиксов словаря. Обычно они называются [language-prefix].dict и [language-prefix].aff соответственно. Эти файлы можно найти в большинстве стандартных дистрибутивов Linux или в многочисленных онлайн-источниках.

Параметр [result] — это место, куда будет сохранён извлечённый словарь, а [locale-name] — параметр для указания нужных локалей.

Также есть необязательный параметр -c [file]. Эта опция позволяет указать файл с деталями преобразования регистра.

Вот несколько примеров использования:

spelldump en.dict en.aff
spelldump ru.dict ru.aff ru.txt ru_RU.CP1251
spelldump ru.dict ru.aff ru.txt .1251

В результате получится файл, в котором будут перечислены все слова из словаря, расположенные в алфавитном порядке и отформатированные как файл форм слов. Вы можете затем изменить этот файл в соответствии с вашими конкретными требованиями. Вот пример того, как может выглядеть выходной файл:

zone > zone
zoned > zoned
zoning > zoning

Инструмент wordbreaker предназначен для разбиения составных слов, часто встречающихся в URL, на отдельные компоненты. Например, он может разделить "lordoftherings" на четыре отдельных слова или разбить http://manofsteel.warnerbros.com на "man of steel warner bros". Эта возможность улучшает функциональность поиска, устраняя необходимость в префиксах или инфиксах. Например, поиск по слову "sphinx" не выдаст "sphinxsearch" в результатах. Однако, если применить wordbreaker для разбиения составного слова и индексировать отдельные элементы, поиск будет успешным без увеличения размера файла, связанного с использованием префиксов или инфиксов в полнотекстовом индексировании.

Вот несколько примеров использования wordbreaker:

echo manofsteel | bin/wordbreaker -dict dict.txt split
man of steel

Файл словаря -dict используется для разделения входного потока на отдельные слова. Если файл словаря не указан, Wordbreaker будет искать файл с именем wordbreaker-dict.txt в текущей рабочей директории. (Убедитесь, что файл словаря соответствует языку составного слова, с которым вы работаете.) Команда split разбивает слова из стандартного ввода и отправляет результаты в стандартный вывод. Команды test и bench также доступны для оценки качества разбиения и измерения производительности функции разбиения соответственно.

Wordbreaker использует словарь для определения отдельных подстрок в заданной строке. Чтобы различать несколько возможных вариантов разбиения, он учитывает относительную частоту каждого слова в словаре. Более высокая частота указывает на большую вероятность разбиения на это слово. Для создания такого файла можно использовать инструмент indexer:

indexer --buildstops dict.txt 100000 --buildfreqs myindex -c /path/to/manticore.conf

который создаст текстовый файл с именем dict.txt, содержащий 100 000 наиболее часто встречающихся слов из myindex вместе с их соответствующими количествами. Поскольку этот выходной файл является простым текстовым документом, у вас есть возможность вручную редактировать его в любое время. Не стесняйтесь добавлять или удалять слова по мере необходимости.

API Manticore Search документируется с использованием спецификации OpenAPI, которая может быть использована для генерации клиентских SDK. Машиночитаемый YAML-файл доступен по адресу https://raw.githubusercontent.com/manticoresoftware/openapi/master/manticore.yml

Вы также можете просмотреть спецификацию в визуализированном виде с помощью онлайн-редактора Swagger здесь.