Ранкер плагины позволя вам реализовам кастом ранкер который получа все совпаданс клю워д в документ и вычис WEIGHT() value. Они могут быть вызлд как фоллws:

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

The call workflow proceeds as follows:

1. XXX_init() is invoked once per query per table, at the very beginning. Several query-wide options are passed to it via a SPH_RANKER_INIT structure, including the user options strings (for instance, "option1=1" in the example above).
2. XXX_update() is called multiple times for each matched document, with every matched keyword occurrence provided as its parameter, a SPH_RANKER_HIT structure. The occurrences within each document are guaranteed to be passed in ascending order of hit->hit_pos values.
3. XXX_finalize() is called once for each matched document when there are no more keyword occurrences. It must return the WEIGHT() value. This function is the only mandatory one.
4. XXX_deinit() is invoked once per query, at the very end.

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

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

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

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

Плагин объявляется как имя библиотеки:имя плагина:необязательная строка настроек. Функции инициализации плагина могут принимать произвольные настройки, которые можно передать в виде строки в формате 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 проверяет дубликаты ID документов в обычной таблице и всех дисковых сегментах 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. Это может быть полезно, когда вам нужно составить списки слов для wordforms, так как она генерирует все возможные формы для вас.

Вот общий синтаксис:

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

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

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 здесь.