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

• Токенизатор во время индексации, объявляемый с помощью 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 здесь.

В Manticore мы собираем различные анонимные метрики для улучшения качества наших продуктов, включая Manticore Search. Анализируя эти данные, мы можем не только повысить общую производительность нашего продукта, но и определить, какие функции стоит приоритетно развивать, чтобы предоставить пользователям ещё большую ценность. Система телеметрии работает в отдельном потоке в неблокирующем режиме, делая снимки и отправляя их раз в несколько минут.

Мы серьёзно относимся к вашей конфиденциальности, и вы можете быть уверены, что все метрики полностью анонимны и никакая чувствительная информация не передаётся. Однако, если вы всё же хотите отключить телеметрию, у вас есть такая возможность:

• Установить переменную окружения TELEMETRY=0
• Или установить telemetry = 0 в секции searchd вашего конфигурационного файла

Ниже приведён список всех собираемых метрик:

Символ ⏱️ указывает, что метрика собирается периодически, в отличие от других метрик, которые собираются на основе конкретных событий.

Метрика	Описание
invocation	Отправляется при запуске Manticore Buddy
plugin_*	Указывает, что плагин с данным именем был выполнен, например, plugin_backup для выполнения резервного копирования
command_*	⏱️ Все метрики с этим префиксом отправляются из запроса show status демона Manticore
uptime	⏱️ Время работы демона Manticore Search
workers_total	⏱️ Количество воркеров, используемых Manticore
cluster_count	⏱️ Сколько кластеров обрабатывает этот узел
cluster_size	⏱️ Сколько узлов во всех кластерах
table_*_count	⏱️ Количество созданных таблиц каждого типа: plain, percolate, rt или distributed
*_field_*_count	⏱️ Количество каждого типа полей для таблиц типов rt и percolate
columnar	⏱️ Указывает, что использовалась библиотека Columnar
columnar_field_count	⏱️ Количество полей, использующих библиотеку Columnar

Инструмент резервного копирования Manticore по умолчанию отправляет анонимные метрики на сервер метрик Manticore для помощи в улучшении продукта. Если вы не хотите отправлять телеметрию, вы можете отключить её, запустив инструмент с флагом --disable-metric или установив переменную окружения TELEMETRY=0.

Ниже приведён список всех собираемых метрик:

Метрика	Описание
invocation	Отправляется при запуске резервного копирования
failed	Отправляется в случае неудачного резервного копирования
done	Отправляется при успешном резервном копировании/восстановлении
arg_*	Аргументы, использованные для запуска инструмента (исключая имена индексов и т.п.)
backup_store_versions_fails	Указывает на ошибку сохранения версии Manticore в резервной копии
backup_table_count	Общее количество таблиц в резервной копии
backup_no_permissions	Ошибка резервного копирования из-за недостаточных прав на каталог назначения
backup_total_size	Общий размер полной резервной копии
backup_time	Продолжительность резервного копирования
restore_searchd_running	Ошибка запуска процесса восстановления из-за уже запущенного searchd
restore_no_config_file	Отсутствие конфигурационного файла в резервной копии при восстановлении
restore_time	Продолжительность восстановления
fsync_time	Продолжительность fsync
restore_target_exists	Возникает, если папка или индекс уже существует в каталоге назначения при восстановлении
terminations	Указывает, что процесс был завершён
signal_*	Сигнал, использованный для завершения процесса
tables	Количество таблиц в Manticore
config_unreachable	Указанный конфигурационный файл не существует
config_data_dir_missing	Не удалось распарсить data_dir из указанного конфигурационного файла
config_data_dir_is_relative	Путь data_dir в конфигурационном файле экземпляра Manticore является относительным

Каждая метрика сопровождается следующими метками:

Метка	Описание
collector	buddy. Указывает, что метрика собрана через Manticore Buddy
os_name	Название операционной системы
os_release_name	Название из /etc/os-release, если присутствует, иначе unknown
os_release_version	Версия из /etc/os-release, если присутствует, иначе unknown
dockerized	Запущено ли в среде Docker
official_docker	В случае Docker — флаг, показывающий, что используется официальный образ
machine_id	Идентификатор сервера (содержимое /etc/machine-id в Linux)
arch	Архитектура машины, на которой запущено ПО
manticore_version	Версия Manticore
columnar_version	Версия библиотеки Columnar, если она установлена
secondary_version	Версия вторичной библиотеки, если установлена библиотека Columnar
knn_version	Версия библиотеки KNN, если установлена библиотека Columnar
buddy_version	Версия Manticore Buddy