Создание и изменение данных > Добавление данных из внешних хранилищ > Создание простых таблиц

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

поле	тип	описание
id	bigint	идентификатор правила PQ (если не указан, будет назначен автоматически)
query	string	полнотекстовый запрос (может быть пустым), совместимый с таблицей перколяции
filters	string	дополнительные фильтры по полям, не являющимся полнотекстовыми (может быть пустым), совместимые с таблицей перколяции
tags	string	строка с одним или несколькими тегами, разделёнными запятыми, которые могут использоваться для выборочного отображения/удаления сохранённых запросов

Любые другие имена полей не поддерживаются и вызовут ошибку.

Внимание: Вставка/замена правил PQ в формате JSON через SQL не сработает. Другими словами, операторы, специфичные для JSON (match и т.п.), будут рассматриваться просто как части текста правила, которые должны совпадать с документами. Если вы предпочитаете синтаксис JSON, используйте HTTP-эндпоинт вместо INSERT/REPLACE.

‹›

SQL
JSON
PHP
Python
Python-asyncio
Javascript
Java
C#
Rust

📋

INSERT INTO pq(id, query, filters) VALUES (1, '@title shoes', 'price > 5');
INSERT INTO pq(id, query, tags) VALUES (2, '@title bag', 'Louis Vuitton');
SELECT * FROM pq;

Существует два способа добавить запрос перколяции в таблицу перколяции:

Запрос в формате JSON, совместимом с /search, описанном в json/search

PUT /pq/pq_table/doc/1
{
"query": {
  "match": {
    "title": "shoes"
  },
  "range": {
    "price": {
      "gt": 5
    }
  }
},
"tags": ["Loius Vuitton"]
}

Запрос в формате SQL, описанном в синтаксисе запросов search

PUT /pq/pq_table/doc/2
{
"query": {
  "ql": "@title shoes"
},
"filters": "price > 5",
"tags": ["Loius Vuitton"]
}

$newstoredquery = [
  'table' => 'test_pq',
  'body' => [
      'query' => [
                     'match' => [
                             'title' => 'shoes'
                     ]
             ],
             'range' => [
                     'price' => [
                             'gt' => 5
                     ]
             ]
     ],
  'tags' => ['Loius Vuitton']
];
$client->pq()->doc($newstoredquery);

newstoredquery ={"table" : "test_pq", "id" : 2, "doc" : {"query": {"ql": "@title shoes"},"filters": "price > 5","tags": ["Loius Vuitton"]}}
indexApi.insert(newstoredquery)

newstoredquery ={"table" : "test_pq", "id" : 2, "doc" : {"query": {"ql": "@title shoes"},"filters": "price > 5","tags": ["Loius Vuitton"]}}
await indexApi.insert(newstoredquery)

newstoredquery ={"table" : "test_pq", "id" : 2, "doc" : {"query": {"ql": "@title shoes"},"filters": "price > 5","tags": ["Loius Vuitton"]}};
indexApi.insert(newstoredquery);

newstoredquery = new HashMap<String,Object>(){{
    put("query",new HashMap<String,Object >(){{
        put("q1","@title shoes");
        put("filters","price>5");
        put("tags",new String[] {"Loius Vuitton"});
    }});
}};
newdoc.index("test_pq").id(2L).setDoc(doc);
indexApi.insert(newdoc);

Dictionary<string, Object> query = new Dictionary<string, Object>();
query.Add("q1", "@title shoes");
query.Add("filters", "price>5");
query.Add("tags", new List<string> {"Loius Vuitton"});
Dictionary<string, Object> newstoredquery = new Dictionary<string, Object>();
newstoredquery.Add("query", query);
InsertDocumentRequest newdoc = new InsertDocumentRequest(index: "test_pq", id: 2, doc: doc);
indexApi.Insert(newdoc);

let mut pq_doc = HashMap::new();
pq_doc.insert("q1".to_string(), serde_json::json!("@title shoes"));
pq_doc.insert("filters".to_string(), serde_json::json!("price>5"));
pq_doc.insert("tags".to_string(), serde_json::json!(["Louis Vitton"]));
let mut doc = HashMap::new();
pq_doc.insert("query".to_string(), serde_json::json!(pq_doc));
let insert_req = InsertDocumentRequest::new("test_pq".to_string(), serde_json::json!(doc));
let insert_res = index_api.insert(insert_req).await;

‹›

Response

+------+--------------+---------------+---------+
| id   | query        | tags          | filters |
+------+--------------+---------------+---------+
|    1 | @title shoes |               | price>5 |
|    2 | @title bag   | Louis Vuitton |         |
+------+--------------+---------------+---------+

Если вы не указываете ID, он будет назначен автоматически. Подробнее об авто-ID можно прочитать здесь.

‹›

SQL
JSON
PHP
Python
Python-asyncio
Javascript
Java
C#
Rust

📋

INSERT INTO pq(query, filters) VALUES ('wristband', 'price > 5');
SELECT * FROM pq;

PUT /pq/pq_table/doc
{
"query": {
  "match": {
    "title": "shoes"
  },
  "range": {
    "price": {
      "gt": 5
    }
  }
},
"tags": ["Loius Vuitton"]
}
PUT /pq/pq_table/doc
{
"query": {
  "ql": "@title shoes"
},
"filters": "price > 5",
"tags": ["Loius Vuitton"]
}

$newstoredquery = [
    'table' => 'pq_table',
    'body' => [
        'query' => [
                       'match' => [
                               'title' => 'shoes'
                       ]
               ],
               'range' => [
                       'price' => [
                               'gt' => 5
                       ]
               ]
       ],
    'tags' => ['Loius Vuitton']
];
$client->pq()->doc($newstoredquery);

indexApi = api = manticoresearch.IndexApi(client)
newstoredquery ={"table" : "test_pq",   "doc" : {"query": {"ql": "@title shoes"},"filters": "price > 5","tags": ["Loius Vuitton"]}}
indexApi.insert(store_query)

indexApi = api = manticoresearch.IndexApi(client)
newstoredquery ={"table" : "test_pq",   "doc" : {"query": {"ql": "@title shoes"},"filters": "price > 5","tags": ["Loius Vuitton"]}}
await indexApi.insert(store_query)

newstoredquery ={"table" : "test_pq",  "doc" : {"query": {"ql": "@title shoes"},"filters": "price > 5","tags": ["Loius Vuitton"]}};
res =  await indexApi.insert(store_query);

newstoredquery = new HashMap<String,Object>(){{
    put("query",new HashMap<String,Object >(){{
        put("q1","@title shoes");
        put("filters","price>5");
        put("tags",new String[] {"Loius Vuitton"});
    }});
}};
newdoc.index("test_pq").setDoc(doc);
indexApi.insert(newdoc);

Dictionary<string, Object> query = new Dictionary<string, Object>();
query.Add("q1", "@title shoes");
query.Add("filters", "price>5");
query.Add("tags", new List<string> {"Loius Vuitton"});
Dictionary<string, Object> newstoredquery = new Dictionary<string, Object>();
newstoredquery.Add("query", query);
InsertDocumentRequest newdoc = new InsertDocumentRequest(index: "test_pq", doc: doc);
indexApi.Insert(newdoc);

let mut pq_doc = HashMap::new();
pq_doc.insert("q1".to_string(), serde_json::json!("@title shoes"));
pq_doc.insert("filters".to_string(), serde_json::json!("price>5"));
pq_doc.insert("tags".to_string(), serde_json::json!(["Louis Vitton"]));
let mut doc = HashMap::new();
pq_doc.insert("query".to_string(), serde_json::json!(pq_doc));
let insert_req = InsertDocumentRequest::new("test_pq".to_string(), serde_json::json!(doc));
let insert_res = index_api.insert(insert_req).await;

‹›

Response

+---------------------+-----------+------+---------+
| id                  | query     | tags | filters |
+---------------------+-----------+------+---------+
| 1657843905795719192 | wristband |      | price>5 |
+---------------------+-----------+------+---------+

{
  "table": "pq_table",
  "type": "doc",
  "_id": 1657843905795719196,
  "result": "created"
}
{
  "table": "pq_table",
  "type": "doc",
  "_id": 1657843905795719198,
  "result": "created"
}

Array(
       [index] => pq_table
       [type] => doc
       [_id] => 1657843905795719198
       [result] => created
)

{'created': True,
 'found': None,
 'id': 1657843905795719198,
 'table': 'test_pq',
 'result': 'created'}

{'created': True,
 'found': None,
 'id': 1657843905795719198,
 'table': 'test_pq',
 'result': 'created'}

{"table":"test_pq","_id":1657843905795719198,"created":true,"result":"created"}

Если в SQL-команде INSERT опустить схему, ожидаются следующие параметры:

ID. Можно использовать 0 в качестве ID, чтобы вызвать автоматическую генерацию ID.
Query - полнотекстовый запрос.
Tags - строка тегов правила PQ.
Filters - дополнительные фильтры по атрибутам.

‹›

SQL

📋

INSERT INTO pq VALUES (0, '@title shoes', '', '');
INSERT INTO pq VALUES (0, '@title shoes', 'Louis Vuitton', '');
SELECT * FROM pq;

‹›

Response

+---------------------+--------------+---------------+---------+
| id                  | query        | tags          | filters |
+---------------------+--------------+---------------+---------+
| 2810855531667783688 | @title shoes |               |         |
| 2810855531667783689 | @title shoes | Louis Vuitton |         |
+---------------------+--------------+---------------+---------+

Чтобы заменить существующее правило PQ новым в SQL, просто используйте обычную команду REPLACE. Существует специальный синтаксис ?refresh=1 для замены правила PQ определённого в JSON-режиме через HTTP JSON интерфейс.

‹›

SQL
JSON

📋

mysql> select * from pq;
+---------------------+--------------+------+---------+
| id                  | query        | tags | filters |
+---------------------+--------------+------+---------+
| 2810823411335430148 | @title shoes |      |         |
+---------------------+--------------+------+---------+
1 row in set (0.00 sec)
mysql> replace into pq(id,query) values(2810823411335430148,'@title boots');
Query OK, 1 row affected (0.00 sec)
mysql> select * from pq;
+---------------------+--------------+------+---------+
| id                  | query        | tags | filters |
+---------------------+--------------+------+---------+
| 2810823411335430148 | @title boots |      |         |
+---------------------+--------------+------+---------+
1 row in set (0.00 sec)

Добавление данных из внешних хранилищ

Last modified: August 28, 2025

Вы можете загружать данные в Manticore из внешних хранилищ с помощью различных методов:

Инструмент Indexer для получения данных из различных баз данных в plain-таблицы.
Интеграции Logstash, Filebeat и Vector.dev для передачи данных в real-time таблицы Manticore из этих инструментов.
Интеграция Kafka для синхронизации данных из тем Kafka в real-time таблицу.

Добавление правил в перколирующую таблицу Создание простых таблиц

Last modified: August 28, 2025

Простые таблицы — это таблицы, которые создаются однократно путём получения данных при создании из одного или нескольких источников. Простая таблица является неизменяемой, так как документы не могут быть добавлены или удалены в течение её жизненного цикла. Возможно только обновление значений числовых атрибутов (включая MVA). Обновление данных возможно только путём пересоздания всей таблицы.

Простые таблицы доступны только в Plain режиме, и их определение состоит из объявления таблицы и одного или нескольких объявлений источников. Сбор данных и создание таблицы выполняются не сервером searchd, а вспомогательным инструментом indexer.

Indexer — это инструмент командной строки, который можно вызывать напрямую из командной строки или из shell-скриптов.

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

В типичном сценарии indexer выполняет следующие действия:

Получает данные из источника
Строит простую таблицу
Записывает файлы таблицы
(Опционально) Информирует поисковый сервер о новой таблице, что запускает ротацию таблиц

Инструмент indexer используется для создания простых таблиц в Manticore Search. Его общий синтаксис:

indexer [OPTIONS] [table_name1 [table_name2 [...]]]

При создании таблиц с помощью indexer сгенерированные файлы таблиц должны иметь права, позволяющие searchd читать, записывать и удалять их. В случае официальных пакетов для Linux searchd работает под пользователем manticore. Поэтому indexer также должен запускаться под пользователем manticore:

sudo -u manticore indexer ...

Если вы запускаете searchd иначе, возможно, потребуется опустить sudo -u manticore. Просто убедитесь, что пользователь, под которым работает ваш экземпляр searchd, имеет права на чтение/запись для таблиц, созданных с помощью indexer.

Чтобы создать простую таблицу, нужно перечислить таблицу(ы), которые вы хотите обработать. Например, если в вашем файле manticore.conf содержатся сведения о двух таблицах, mybigindex и mysmallindex, вы можете выполнить:

sudo -u manticore indexer mysmallindex mybigindex

Вы также можете использовать подстановочные знаки для сопоставления имён таблиц:

? соответствует любому одному символу
* соответствует любому количеству любых символов
% соответствует отсутствию или любому одному символу

sudo -u manticore indexer indexpart*main --rotate

Коды выхода indexer следующие:

0: всё прошло успешно
1: возникла проблема при индексации (и если был указан --rotate, он был пропущен) или операция выдала предупреждение
2: индексация прошла успешно, но попытка --rotate не удалась

Вы также можете запустить indexer с помощью следующего файла юнита systemctl:

systemctl start --no-block manticore-indexer

Или, если хотите построить конкретную таблицу:

systemctl start --no-block manticore-indexer@specific-table-name

Используйте команду systemctl set-environment INDEXER_CONFIG для запуска Indexer с пользовательской конфигурацией, которая заменяет настройки по умолчанию.

Команда systemctl set-environment INDEXER_ARGS позволяет добавить пользовательские параметры запуска для Indexer. Полный список параметров командной строки смотрите здесь.

Например, чтобы запустить Indexer в тихом режиме, выполните:

systemctl set-environment INDEXER_ARGS='--quiet'
systemctl restart manticore-indexer

Чтобы отменить изменения, выполните:

systemctl set-environment INDEXER_ARGS=''
systemctl restart manticore-indexer

--config <file> (-c <file> для краткости) указывает indexer использовать указанный файл в качестве конфигурации. Обычно он ищет manticore.conf в каталоге установки (например, /etc/manticoresearch/manticore.conf), затем в текущем каталоге, в котором вы вызываете indexer из shell. Это особенно полезно в общих средах, где бинарные файлы установлены в глобальную папку, например /usr/bin/, но вы хотите предоставить пользователям возможность создавать свои собственные настройки Manticore или запускать несколько экземпляров на одном сервере. В таких случаях вы можете позволить им создавать свои собственные файлы manticore.conf и передавать их indexer с помощью этой опции. Например:
```
sudo -u manticore indexer --config /home/myuser/manticore.conf mytable
```
--all указывает indexer обновить все таблицы, перечисленные в manticore.conf, вместо указания отдельных таблиц. Это полезно в небольших конфигурациях или для заданий cron или обслуживания, когда весь набор таблиц пересоздаётся каждый день, неделю или в другой подходящий период. Обратите внимание, что поскольку --all пытается обновить все найденные таблицы в конфигурации, он выдаст предупреждение, если встретит RealTime таблицы, и код выхода команды будет 1, а не 0, даже если простые таблицы завершились без проблем. Пример использования:
```
sudo -u manticore indexer --config /home/myuser/manticore.conf --all
```
--rotate используется для ротации таблиц. Если у вас нет ситуации, когда можно отключить функцию поиска без неудобств для пользователей, вам почти наверняка нужно будет держать поиск запущенным во время индексации новых документов. --rotate создаёт вторую таблицу, параллельную первой (в том же месте, просто с включением .new в имена файлов). После завершения indexer уведомляет searchd отправкой сигнала SIGHUP, и searchd пытается переименовать таблицы (переименовывая существующие с добавлением .old и переименовывая .new в их место), а затем начинает обслуживать из новых файлов. В зависимости от настройки seamless_rotate может быть небольшая задержка перед возможностью поиска в новых таблицах. Если одновременно ротируются несколько таблиц, связанных отношениями killlist_target, ротация начнётся с таблиц, которые не являются целями, и закончится таблицами в конце цепочки целей. Пример использования:
```
sudo -u manticore indexer --rotate --all
```
--quiet указывает indexer не выводить ничего, кроме ошибок. Это в основном используется для заданий типа cron или других скриптов, где вывод не важен или не нужен, кроме случаев ошибок. Пример использования:
```
sudo -u manticore indexer --rotate --all --quiet
```
--noprogress не отображает детали прогресса по мере их появления. Вместо этого итоговые данные о статусе (например, количество проиндексированных документов, скорость индексации и так далее) выводятся только по завершении индексации. В случаях, когда скрипт не запускается в консоли (или 'tty'), этот параметр включен по умолчанию. Пример использования:
```
sudo -u manticore indexer --rotate --all --noprogress
```
--buildstops <outputfile.text> <N> просматривает исходную таблицу, как если бы она индексировалась, и создает список терминов, которые индексируются. Другими словами, он создает список всех поисковых терминов, которые становятся частью таблицы. Обратите внимание, что таблица при этом не обновляется, данные просто обрабатываются, как при индексации, включая выполнение запросов, определенных с помощью sql_query_pre или sql_query_post. В outputfile.txt будет содержаться список слов, по одному на строку, отсортированных по частоте с наиболее частыми первыми, а N задает максимальное количество слов в списке. Если N достаточно велик, чтобы охватить все слова в таблице, будет возвращено только столько слов. Такой словарь может использоваться для функций клиентских приложений, связанных с функционалом "Вы имели в виду…", обычно в сочетании с --buildfreqs, описанным ниже. Пример:
```
sudo -u manticore indexer mytable --buildstops word_freq.txt 1000
```
Это создаст файл в текущем каталоге word_freq.txt с 1000 наиболее часто встречающимися словами в 'mytable', упорядоченными по убыванию частоты. Обратите внимание, что файл будет относиться к последней проиндексированной таблице, если указано несколько таблиц или --all (то есть к последней в конфигурационном файле).
--buildfreqs работает вместе с --buildstops (игнорируется, если --buildstops не указан). Поскольку --buildstops предоставляет список слов, используемых в таблице, --buildfreqs добавляет количество их вхождений в таблицу, что полезно для определения, следует ли считать некоторые слова стоп-словами, если они слишком распространены. Это также помогает при разработке функций "Вы имели в виду…", где нужно знать, насколько одно слово встречается чаще другого, похожего. Например:
```
sudo -u manticore indexer mytable --buildstops word_freq.txt 1000 --buildfreqs
```
Это создаст word_freq.txt, как описано выше, но после каждого слова будет указано количество его вхождений в таблицу.
--merge <dst-table> <src-table> используется для физического слияния таблиц, например, если у вас есть схема main+delta, где основная таблица редко меняется, а дельта-таблица часто перестраивается, и --merge используется для объединения двух таблиц. Операция идет справа налево — содержимое src-table анализируется и физически объединяется с содержимым dst-table, а результат остается в dst-table. В псевдокоде это можно выразить как: dst-table += src-table Пример:
```
sudo -u manticore indexer --merge main delta --rotate
```
В приведенном примере, где main — это основная, редко изменяемая таблица, а delta — более часто изменяемая, вы можете использовать эту команду для вызова indexer, чтобы объединить содержимое delta с main и выполнить ротацию таблиц.
--merge-dst-range <attr> <min> <max> применяет фильтр диапазона при слиянии. Конкретно, поскольку слияние применяется к целевой таблице (в рамках --merge и игнорируется, если --merge не указан), indexer также фильтрует документы, попадающие в целевую таблицу, и только документы, проходящие через заданный фильтр, окажутся в итоговой таблице. Это может использоваться, например, в таблице с атрибутом 'deleted', где 0 означает 'не удален'. Такая таблица может быть объединена с помощью:
```
sudo -u manticore indexer --merge main delta --merge-dst-range deleted 0 0
```
Все документы, помеченные как удаленные (значение 1), будут удалены из вновь объединенной целевой таблицы. Этот параметр можно указывать несколько раз в командной строке, чтобы добавить последовательные фильтры к слиянию, все из которых должны быть выполнены, чтобы документ стал частью итоговой таблицы.
--merge-killlists (и его короткий псевдоним --merge-klists) изменяет способ обработки списков удаления (kill lists) при слиянии таблиц. По умолчанию оба списка удаления отбрасываются после слияния. Это поддерживает наиболее типичный сценарий слияния main+delta. При включении этой опции списки удаления обеих таблиц объединяются и сохраняются в целевой таблице. Обратите внимание, что список удаления исходной (delta) таблицы всегда используется для подавления строк из целевой (main) таблицы.
--keep-attrs позволяет повторно использовать существующие атрибуты при переиндексации. При перестроении таблицы для каждого нового id документа проверяется наличие в "старой" таблице, и если он уже существует, его атрибуты переносятся в "новую" таблицу; если не найден, используются атрибуты из новой таблицы. Если пользователь обновил атрибуты в таблице, но не в исходных данных, используемых для таблицы, все обновления будут потеряны при переиндексации; использование --keep-attrs позволяет сохранить обновленные значения атрибутов из предыдущей таблицы. Можно указать путь к файлам таблицы, который будет использоваться вместо пути из конфигурации:
```
sudo -u manticore indexer mytable --keep-attrs=/path/to/index/files
```
--keep-attrs-names=<attributes list> позволяет указать атрибуты для повторного использования из существующей таблицы при переиндексации. По умолчанию все атрибуты из существующей таблицы повторно используются в новой таблице:
```
sudo -u manticore indexer mytable --keep-attrs=/path/to/table/files --keep-attrs-names=update,state
```
--dump-rows <FILE> сохраняет строки, полученные из SQL-источника(ов), в указанный файл в синтаксисе, совместимом с MySQL. Полученные дампы являются точным представлением данных, как они получены indexer, и могут помочь воспроизвести проблемы, возникающие во время индексации. Команда выполняет получение данных из источника и создает как файлы таблиц, так и файл дампа.
--print-rt <rt_index> <table> выводит полученные данные из источника в виде INSERT-запросов для таблицы реального времени. Первые строки дампа будут содержать поля и атрибуты реального времени (как отражение полей и атрибутов обычной таблицы). Команда выполняет получение данных из источника и создает как файлы таблиц, так и вывод дампа. Команду можно использовать как sudo -u manticore indexer -c manticore.conf --print-rt indexrt indexplain > dump.sql. Поддерживаются только источники на основе SQL. MVAs не поддерживаются.
--sighup-each полезен, когда вы перестраиваете много больших таблиц и хотите, чтобы каждая из них была как можно скорее загружена в searchd. С --sighup-each indexer отправит сигнал SIGHUP в searchd после успешного завершения работы с каждой таблицей. (По умолчанию отправляется один SIGHUP после построения всех таблиц).
--nohup полезен, когда вы хотите проверить таблицу с помощью indextool перед фактической загрузкой. indexer не отправит SIGHUP, если эта опция включена. Файлы таблиц переименовываются в .tmp. Используйте indextool для переименования файлов таблиц в .new и загрузки их. Пример использования:
```
sudo -u manticore indexer --rotate --nohup mytable
sudo -u manticore indextool --rotate --check mytable
```
--print-queries выводит SQL-запросы, которые indexer отправляет в базу данных, вместе с событиями подключения и отключения SQL. Это полезно для диагностики и устранения проблем с SQL-источниками.
--help (-h для краткости) выводит список всех параметров, которые можно вызвать в indexer.
-v показывает версию indexer.

Вы также можете настроить поведение indexer в конфигурационном файле Manticore в разделе indexer:

indexer {
...
}

lemmatizer_cache = 256M

Размер кэша лемматизатора. Необязательно, по умолчанию 256K.

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

В настоящее время доступны только словари ru.pak, en.pak и de.pak. Это русские, английские и немецкие словари. Размер сжатого словаря примерно от 2 до 10 МБ. Обратите внимание, что словарь всегда находится в памяти. Размер кэша по умолчанию — 256 КБ. Допустимые размеры кэша — от 0 до 2047 МБ. Безопасно увеличивать размер кэша слишком высоко; лемматизатор будет использовать только необходимую память. Например, весь русский словарь распаковывается примерно до 110 МБ; поэтому установка lemmatizer_cache выше этого значения не повлияет на использование памяти. Даже если разрешено 1024 МБ для кэша, если нужно только 110 МБ, будет использовано только 110 МБ.

max_file_field_buffer = 128M

Максимальный размер адаптивного буфера для файлового поля в байтах. Необязательно, по умолчанию 8 МБ, минимум 1 МБ.

Буфер файлового поля используется для загрузки файлов, на которые ссылаются столбцы sql_file_field. Этот буфер адаптивен, начиная с 1 МБ при первом выделении и увеличиваясь в 2 раза, пока либо содержимое файла не будет загружено, либо не будет достигнут максимальный размер буфера, указанный директивой max_file_field_buffer.

Таким образом, если файловые поля не указаны, буфер не выделяется вообще. Если все файлы, загружаемые во время индексации, меньше (например) 2 МБ, а значение max_file_field_buffer равно 128 МБ, пиковое использование буфера все равно будет только 2 МБ. Однако файлы размером более 128 МБ будут полностью пропущены.

max_iops = 40

Максимальное количество операций ввода-вывода в секунду для ограничения I/O. Необязательно, по умолчанию 0 (без ограничений).

Опция, связанная с ограничением I/O. Она ограничивает максимальное количество операций ввода-вывода (чтение или запись) за любую секунду. Значение 0 означает отсутствие ограничений.

indexer может вызывать всплески интенсивных операций дискового ввода-вывода во время построения таблицы, и может быть желательно ограничить его активность на диске (и оставить ресурсы для других программ, работающих на той же машине, например searchd). Ограничение I/O помогает в этом. Оно работает, обеспечивая минимальную гарантированную задержку между последовательными операциями дискового ввода-вывода, выполняемыми indexer. Ограничение I/O может помочь уменьшить ухудшение производительности поиска, вызванное построением. Эта настройка неэффективна для других видов загрузки данных, например вставки данных в таблицу реального времени.

max_iosize = 1048576

Максимально допустимый размер операции ввода-вывода в байтах для ограничения I/O. Необязательно, по умолчанию 0 (без ограничений).

Опция, связанная с ограничением I/O. Она ограничивает максимальный размер файловой операции ввода-вывода (чтение или запись) для всех операций, выполняемых indexer. Значение 0 означает отсутствие ограничений. Чтения или записи, превышающие этот лимит, будут разбиты на несколько меньших операций и учитываться как несколько операций в настройке max_iops. На момент написания все вызовы I/O должны быть меньше 256 КБ (размер внутреннего буфера по умолчанию), поэтому значения max_iosize выше 256 КБ не должны влиять.

max_xmlpipe2_field = 8M

Максимально допустимый размер поля для источника типа XMLpipe2 в байтах. Необязательно, по умолчанию 2 МБ.

mem_limit = 256M
# mem_limit = 262144K # same, but in KB
# mem_limit = 268435456 # same, but in bytes

Plain table building RAM usage limit. Optional, default is 128 MB. Enforced memory usage limit that the indexer will not go above. Can be specified in bytes, or kilobytes (using K postfix), or megabytes (using M postfix); see the example. This limit will be automatically raised if set to an extremely low value causing I/O buffers to be less than 8 KB; the exact lower bound for that depends on the built data size. If the buffers are less than 256 KB, a warning will be produced.

Максимально возможный лимит — 2047M. Слишком низкие значения могут замедлить построение plain table, но 256M до 1024M должно быть достаточно для большинства, если не всех наборов данных. Установка слишком высокого значения может привести к тайм-аутам SQL сервера. Во время фазы сбора документов будут периоды, когда буфер памяти частично отсортирован и связь с базой данных не выполняется; и сервер базы данных может прервать соединение по тайм-ауту. Вы можете решить эту проблему либо увеличив тайм-ауты на стороне SQL сервера, либо уменьшив mem_limit.

on_file_field_error = skip_document

Как обрабатывать ошибки ввода-вывода в файловых полях. Необязательно, по умолчанию ignore_field. Когда возникает проблема с индексированием файла, на который ссылается файловое поле (sql_file_field), indexer может либо обработать документ, предполагая пустое содержимое в этом конкретном поле, либо пропустить документ, либо полностью завершить индексирование с ошибкой. Директива on_file_field_error контролирует это поведение. Возможные значения:

ignore_field, обработать текущий документ без поля;
skip_document, пропустить текущий документ, но продолжить индексирование;
fail_index, завершить индексирование с сообщением об ошибке.

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

Обратите внимание, что при on_file_field_error = skip_document документы будут игнорироваться только если проблемы обнаружены на ранней фазе проверки, и не во время фактического разбора файла. indexer откроет каждый указанный файл и проверит его размер перед началом работы, а затем откроет его снова при фактическом разборе. Поэтому, если файл исчезнет между этими двумя попытками открытия, документ всё равно будет проиндексирован.

write_buffer = 4M

Размер буфера записи, в байтах. Необязательно, по умолчанию 1MB. Буферы записи используются для записи как временных, так и окончательных файлов таблиц при индексировании. Большие буферы уменьшают количество необходимых операций записи на диск. Память для буферов выделяется дополнительно к mem_limit. Обратите внимание, что будет выделено несколько (в настоящее время до 4) буферов для разных файлов, что пропорционально увеличивает использование ОЗУ.

ignore_non_plain = 1

ignore_non_plain позволяет полностью игнорировать предупреждения о пропуске не-plain таблиц. По умолчанию 0 (не игнорировать).

Существует два подхода к планированию запусков indexer. Первый способ — классический метод с использованием crontab. Второй способ — использование таймера systemd с пользовательским расписанием. Чтобы создать файлы юнитов таймера, их нужно поместить в соответствующий каталог, где systemd ищет такие файлы юнитов. В большинстве дистрибутивов Linux этот каталог обычно /etc/systemd/system. Вот как это сделать:

Создайте файл юнита таймера для вашего пользовательского расписания:

cat << EOF > /etc/systemd/system/manticore-indexer@.timer
[Unit]
Description=Run Manticore Search's indexer on schedule
[Timer]
OnCalendar=minutely
RandomizedDelaySec=5m
Unit=manticore-indexer@%i.service
[Install]
WantedBy=timers.target
EOF

Подробнее о синтаксисе и примерах OnCalendar можно найти здесь.

Отредактируйте юнит таймера под свои нужды.

Включите таймер:

systemctl enable manticore-indexer@idx1.timer

Запустите таймер:

systemctl start manticore-indexer@idx1.timer

Повторите шаги 2-4 для любых дополнительных таймеров.

Добавление данных из внешних хранилищ Введение

Last modified: August 28, 2025

Добавление правил в таблицу перколяции

Автоматическое назначение ID

Отсутствие схемы в SQL

Замена правил в таблице PQ

Добавление данных из внешних хранилищ

Создание простых таблиц

Инструмент Indexer

Служба systemd для Indexer

Аргументы командной строки Indexer

Настройки конфигурации Indexer

lemmatizer_cache

max_file_field_buffer

max_iops

max_iosize

max_xmlpipe2_field

mem_limit

on_file_field_error

write_buffer

ignore_non_plain

Schedule indexer via systemd

≫ Получение из баз данных