Конфигурация Manticore поддерживает синтаксис шебанга, позволяя писать конфигурацию на языке программирования и интерпретировать её при загрузке. Это даёт возможность динамических настроек, таких как генерация таблиц путём запроса к таблице базы данных, изменение настроек на основе внешних факторов или включение внешних файлов с объявлениями таблиц и источников.

Файл конфигурации разбирается указанным интерпретатором, и вывод используется как реальная конфигурация. Это происходит каждый раз при чтении конфигурации, а не только при запуске searchd.

Примечание: эта функция недоступна на платформе Windows.

В следующем примере используется PHP для создания нескольких таблиц с разными именами и для сканирования конкретной папки на наличие файлов с дополнительными объявлениями таблиц:

#!/usr/bin/php
...
<?php for ($i=1; $i<=6; $i++) { ?>
table test_<?=$i?> {
  type = rt
  path = /var/lib/manticore/data/test_<?=$i?>
  rt_field = subject
  ...
 }
 <?php } ?>
 ...
 <?php
 $confd_folder='/etc/manticore.conf.d/';
 $files = scandir($confd_folder);
 foreach($files as $file)
 {
         if(($file == '.') || ($file =='..'))
         {} else {
                 $fp = new SplFileInfo($confd_folder.$file);
                 if('conf' == $fp->getExtension()){
                         include ($confd_folder.$file);
                 }
         }
 }
 ?>

Файл конфигурации Manticore Search поддерживает комментарии, которые помогают предоставить пояснения или заметки внутри файла конфигурации. Символ # используется для начала комментария. Вы можете разместить символ комментария либо в начале строки, либо встроенно внутри строки.

При использовании комментариев будьте осторожны при включении символа # в настройки токенизации символов, так как всё, что следует после него, будет проигнорировано. Чтобы этого избежать, используйте UTF-8 код для #, который равен U+23.

Если вам нужно использовать символ # внутри вашего файла конфигурации, например, в учетных данных базы данных в описаниях источников, вы можете экранировать его с помощью обратного слэша \. Это позволяет включать символ # в настройки без его интерпретации как начала комментария.

Наследование в объявлениях table и source помогает лучше организовать таблицы с похожими настройками или структурой и уменьшает размер конфигурации. Наследование можно использовать и в родительских, и в дочерних таблицах или источниках.

Для родительской таблицы или источника не требуется никакой специальной конфигурации.

В объявлении дочерней таблицы или источника укажите имя таблицы или источника, затем двоеточие (:) и имя родителя:

table parent {
path = /var/lib/manticore/parent
...
}
table child:parent {
path = /var/lib/manticore/child
...
}

Дочерний объект унаследует всю конфигурацию родителя. Любые настройки, объявленные в дочернем объекте, переопределят унаследованные значения. Имейте в виду, что для многозначных настроек указание одного значения в дочернем объекте очистит все унаследованные значения. Например, если у родителя есть несколько объявлений sql_query_pre, а у дочернего объекта есть одно объявление sql_query_pre, все унаследованные объявления sql_query_pre будут удалены. Чтобы переопределить только часть унаследованных значений родителя, явно объявите их в дочернем объекте. Это также подходит, если вам не нужно значение из родителя. Например, если значение sql_query_pre от родителя не требуется, объявите директиву с пустым значением в дочернем объекте, например sql_query_pre=.

Обратите внимание, что существующие значения многозначной настройки не будут скопированы, если дочерний объект объявляет для этой настройки одно значение.

Такое поведение наследования относится не только к параметрам таблицы, но и к полям и атрибутам. Например, если у родителя есть два целочисленных атрибута, а дочернему объекту нужен новый целочисленный атрибут, объявления целочисленных атрибутов из родителя нужно скопировать в конфигурацию дочернего объекта.

SET [GLOBAL] server_variable_name = value
SET [INDEX table_name] GLOBAL @user_variable_name = (int_val1 [, int_val2, ...])
SET NAMES value [COLLATE value]
SET @@dummy_variable = ignored_value

Оператор SET в Manticore Search позволяет изменять значения переменных. Имена переменных не чувствительны к регистру, и никакие изменения значений переменных не сохранятся после перезапуска сервера.

Manticore Search поддерживает оператор SET NAMES и синтаксис SET @@variable_name для совместимости с внешними MySQL клиентскими библиотеками, коннекторами и фреймворками, которые могут требовать выполнения этих операторов при подключении. Однако эти операторы не влияют на сам Manticore Search.

В Manticore Search существуют четыре класса переменных:

1. Переменная сервера на сессию: set var_name = value
2. Глобальная переменная сервера: set global var_name = value
3. Глобальная пользовательская переменная: set global @var_name = (value)
4. Глобальная распределённая переменная: set index dist_table_name global @var_name = (value)

Глобальные пользовательские переменные разделяются между параллельными сессиями. Единственный поддерживаемый тип значения — список BIGINT, и эти переменные можно использовать с оператором IN() для фильтрации. Основное применение этой возможности — загрузка больших списков значений в searchd один раз с последующим многократным использованием, что снижает сетевые расходы. Глобальные пользовательские переменные можно передавать всем агентам распределённой таблицы или устанавливать локально в случае локальной таблицы, определённой в распределённой таблице. Пример:

// in session 1
mysql> SET GLOBAL @myfilter=(2,3,5,7,11,13);
Query OK, 0 rows affected (0.00 sec)
// later in session 2
mysql> SELECT * FROM test1 WHERE group_id IN @myfilter;
+------+--------+----------+------------+-----------------+------+
| id   | weight | group_id | date_added | title           | tag  |
+------+--------+----------+------------+-----------------+------+
|    3 |      1 |        2 | 1299338153 | another doc     | 15   |
|    4 |      1 |        2 | 1299338153 | doc number four | 7,40 |
+------+--------+----------+------------+-----------------+------+
2 rows in set (0.02 sec)

Manticore Search поддерживает переменные сервера на сессию и глобальные переменные сервера, которые влияют на определённые настройки сервера в соответствующих областях видимости. Ниже приведён список известных переменных сервера на сессию и глобальных переменных сервера:

Известные переменные сервера на сессию:

• AUTOCOMMIT = {0 | 1} определяет, должны ли операции изменения данных неявно заключаться в BEGIN и COMMIT.

• COLLATION_CONNECTION = collation_name выбирает колляцию для ORDER BY или GROUP BY по строковым значениям в последующих запросах. Список известных названий колляций см. в разделе Collations.

• MAX_THREADS_PER_QUERY = <POSITIVE_INT_VALUE> переопределяет max_threads_per_query во время выполнения. Переменная на сессию влияет только на запросы, выполняемые в той же сессии (соединении), т.е. до отключения. Значение 0 означает "без ограничений". Если установлены обе переменные — и на сессию, и глобальная, приоритет выше у переменной на сессию.

• NET_WRITE_TIMEOUT = <value>

• NET_READ_TIMEOUT = <value>

• INTERACTIVE_TIMEOUT = <value>: Устанавливает таймаут подключения SQL (время простоя) для интерактивных SQL-сессий. Распространенный пример — подключение к серверу Manticore с использованием клиента командной строки (CLI), такого как mysql. Ранее существовали отдельные глобальные таймауты 'чтения' и 'записи', но это оказалось запутанным. Теперь NET_WRITE_TIMEOUT и NET_READ_TIMEOUT являются псевдонимами для INTERACTIVE_TIMEOUT. Все они управляют одной и той же переменной, относящейся только к конечным точкам SQL: максимальное допустимое время простоя соединения. Это похоже на WAIT_TIMEOUT, но специально для интерактивных сессий.

• WAIT_TIMEOUT = <value>: Устанавливает таймаут подключения SQL (время простоя) для неинтерактивных SQL-сессий. Распространённый пример — клиентская библиотека, подключающаяся к серверу Manticore и поддерживающая пул соединений для повторного использования. Это похоже на INTERACTIVE_TIMEOUT, но применяется специально к неинтерактивным сессиям.

• OPTIMIZE_BY_ID = {0 | 1}: Внутренний флаг, используемый в некоторых командах debug.

• PROFILING = {0 | 1} включает профилирование запросов в текущей сессии. По умолчанию 0. См. также show profile.

• ro = {1 | 0} переключает сессию в режим только для чтения или обратно. В выводе show variables переменная показывается под именем session_read_only.

• throttling_period = <INT_VALUE>: Интервал (в миллисекундах), в течение которого текущий выполняющийся запрос будет переназначен. Значение 0 отключает ограничение, что значит, запрос займет ядра CPU до завершения. Если параллельные запросы поступают в это же время из других соединений, они будут отправлены на свободные ядра или приостановлены до освобождения ядра. Установка отрицательного значения (-1) сбрасывает ограничение до стандартного скомпилированного значения (100 мс), что означает переназначение запроса каждые 100 мс, позволяющее выполнять параллельные запросы. Глобальное значение (устанавливаемое через set global) может задаваться только через VIP соединение.

• thread_stack = <value>: Меняет значение по умолчанию на лету, ограничивая размер стека, выделенного одной задаче. При этом 'thread' здесь означает не поток ОС, а поток пользователя, известный также как корутина. Это полезно, например, если вы загружаете percolate таблицу с неожиданно высокими требованиями. В таких случаях 'call pq' завершится ошибкой о недостаточном размере стека. Обычно нужно остановить демон, увеличить значение в конфиге, а затем перезапустить. Однако можно попробовать новое значение без перезапуска, установив его этой переменной. Глобальное значение также можно изменить онлайн с set global thread_stack, но это возможно только из VIP соединения.

• threads_ex (диагностическая): Заставляет Manticore вести себя так, как будто он запущен на CPU с указанным профилем. Краткий пример: set threads_ex='4/2+6/3' означает 'у вас есть 4 свободных CPU ядра, при планировании нескольких запросов их нужно группировать по 2. Кроме того, у вас есть 6 свободных CPU ядер для псевдо-шардинга, части нужно группировать по 3'. Эта опция диагностическая, так как очень полезна, например, чтобы увидеть, как ваш запрос выполнялся бы на конфигурации, которой у вас нет локально. Например, на 128-ядерном CPU. Или, наоборот, чтобы быстро ограничить демон до однопоточного режима, чтобы найти узкое место или исследовать сбой.

  MORE

  Известные глобальные серверные переменные:

  • WAIT_TIMEOUT = <значение> устанавливает таймаут SQL-соединения на максимально допустимое время простоя для неинтерактивного соединения. Вы можете настроить этот параметр либо для сессии (для текущего соединения), либо глобально, но глобальные настройки применяются только при использовании VIP-соединений.
  • INTERACTIVE_TIMEOUT = <значение> устанавливает таймаут SQL-соединения на максимально допустимое время простоя для интерактивного соединения. Как и WAIT_TIMEOUT, этот параметр можно настроить для сессии или глобально, но глобальные настройки применяются только при использовании VIP-соединений.
  • ACCURATE_AGGREGATION: Устанавливает значение по умолчанию для опции accurate_aggregation будущих запросов.
  • AUTO_OPTIMIZE = <non-negative integer> Настраивает auto_optimize: 0 отключает, 1 включает с порогом по умолчанию, а значения больше 1 умножают этот порог.
  • cluster_user = name Устанавливает имя пользователя, используемое с mysqldump / mariadb-dump для включения режима репликации.
  • COREDUMP= {1|0} Включает/выключает сохранение core-файла или минидампа сервера при сбое. Подробнее здесь.
  • CPUSTATS= {1|0} Включает/выключает отслеживание времени CPU.
  • DISTINCT_PRECISION_THRESHOLD: Устанавливает значение по умолчанию для опции distinct_precision_threshold будущих запросов.
  • EMBEDDINGS_THREADS = <non-negative integer> Меняет embeddings_threads во время работы. Значение ограничивает, сколько потоков библиотека embeddings может использовать при генерации векторов для вставок с автоэмбеддингом, перестроения KNN в ALTER TABLE и эмбеддинга текстовых запросов KNN. 0 отключает ограничение.
  • ES_COMPAT = {on/off/dashboards} При установке в on (по умолчанию) поддерживаются запросы записи, аналогичные Elasticsearch; off отключает поддержку; dashboards включает поддержку и также разрешает запросы из Kibana (функциональность экспериментальная).
  • EXPANSION_MERGE_THRESHOLD_DOCS: Изменяет значение настройки конфига expansion_merge_threshold_docs на лету.
  • EXPANSION_MERGE_THRESHOLD_HITS: Изменяет значение настройки конфига expansion_merge_threshold_hits на лету.
  • GROUPING_IN_UTC = {0 | 1} При установке в 1 вызывает расчет функций группировки по времени (day(), month(), year(), yearmonth(), yearmonthday()) в UTC. Подробнее о параметре grouping_in_utc.
  • IOSTATS = {0 | 1} Включает или выключает отчеты об операциях ввода-вывода (кроме атрибутов) в журнале запросов.
  • KNN_PARALLEL_BUILD = <положительное целое число> Изменяет knn_parallel_build во время выполнения. Значение контролирует, сколько рабочих потоков может использоваться для построения графов HNSW во время сохранения RT-чанков и слияний чанков при OPTIMIZE / автооптимизации.
  • LOG_DEBUG_FILTER = <string value> Фильтрует избыточные сообщения журнала. Если установлено значение, тогда все логи с уровнем > INFO (например, DEBUG, DEBUGV и т.д.) будут сравниваться со строкой, и выводиться только в случае, если начинаются с данного значения.
  • LOG_LEVEL = {info | debug | replication | debugv | debugvv} Изменяет текущий уровень подробности журнала.
  • MAINTENANCE = {0 | 1} При установке в 1 переводит сервер в режим обслуживания. В этом режиме запросы могут выполнять только клиенты с VIP-соединениями. Все новые не-VIP соединения отклоняются. Существующие соединения сохраняются.
  • MAX_THREADS_PER_QUERY = <POSITIVE_INT_VALUE> Переопределяет max_threads_per_query во время выполнения. Если задано глобально, меняет поведение для всех сессий. Значение 0 означает "без ограничений". Если установлены обе переменные — на сессию и глобальная, приоритет у переменной на сессию.
  • NET_WAIT = {-1 | 0 | POSITIVE_INT_VALUE} Изменяет значение настройки net_wait_tm searchd.
  • OPTIMIZE_CUTOFF = <value>: Изменяет значение настройки конфига optimize_cutoff на лету.
  • PSEUDO_SHARDING = {1|0} Включает/выключает поиск с помощью псевдо-шардинга.
  • QCACHE_MAX_BYTES = <value> Изменяет лимит использования ОЗУ для query_cache на заданное значение.
  • QCACHE_THRESH_MSEC = <value> Изменяет минимальный порог времени выполнения кэша запросов query_cache на заданное значение.
  • QCACHE_TTL_SEC = <value> Изменяет время жизни (TTL) для закэшированного результата в query_cache на заданное значение.
  • QUERY_LOG_FORMAT = {plain | sphinxql} Изменяет текущий формат журнала.
  • QUERY_LOG_MIN_MSEC = <value> Изменяет значение настройки query_log_min_msec searchd. В этом случае значение ожидается строго в миллисекундах без обработки суффиксов времени, как в конфиге.

    Внимание: это очень специфичная и "жёсткая" переменная; отфильтрованные сообщения просто удаляются и не записываются в журнал. Лучше фильтруйте журнал с помощью чего-то вроде 'grep', тогда у вас всегда будет резервная копия полного оригинального журнала.

  • RESET_NETWORK_TIMEOUT_ON_PACKET = {1|0} Изменяет параметр reset_network_timeout_on_packet. Изменять этот параметр могут только клиенты с VIP-соединениями.
  • SECONDARY_INDEXES = {1|0} Включает/выключает вторичные индексы для поисковых запросов.
  • TIMEZONE = <value> Указывает временную зону, используемую функциями, связанными с датой/временем. Подробнее о параметре timezone.

  Примеры:

  mysql> SET autocommit=0;
  Query OK, 0 rows affected (0.00 sec)
  mysql> SET GLOBAL query_log_format=sphinxql;
  Query OK, 0 rows affected (0.00 sec)
  mysql> SET GLOBAL @banned=(1,2,3);
  Query OK, 0 rows affected (0.01 sec)
  mysql> SET INDEX users GLOBAL @banned=(1,2,3);
  Query OK, 0 rows affected (0.01 sec)

  Чтобы сделать пользовательские переменные постоянными, убедитесь, что sphinxql_state включен.