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

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

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

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

Внимание: Вставка/замена правил PQ в формате JSON через SQL не будет работать. Другими словами, специфичные для JSON операторы (match и т.д.) будут рассматриваться просто как часть текста правила, который должен совпадать с документами. Если вы предпочитаете синтаксис JSON, используйте HTTP endpoint вместо 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;

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

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

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

Запрос в формате SQL, описанный в search query syntax

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 из внешних хранилищ с помощью различных методов:

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

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

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 с помощью следующего unit-файла 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 задаёт максимальное количество слов в списке. Если это число достаточно велико, чтобы охватить все слова в таблице, будет возвращено именно столько слов. Такой словарь может использоваться в клиентских приложениях для функций вроде "Вы имели в виду…", обычно в сочетании с --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
```
В приведённом примере, где основная таблица — основная, редко изменяемая, а дельта — более часто изменяемая, приведённый вызов indexer используется для объединения содержимого дельты с основной таблицей и переключения таблиц.
--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) изменяет способ обработки списков удалённых при слиянии таблиц. По умолчанию после слияния оба списка удалённых отбрасываются. Это поддерживает наиболее распространённый сценарий слияния main+delta. Однако с включённым этим параметром списки удалённых из обеих таблиц объединяются и сохраняются в целевой таблице. Обратите внимание, что список удалённых из исходной (дельта) таблицы всегда используется для подавления строк из целевой (главной) таблицы.
--keep-attrs позволяет повторно использовать существующие атрибуты при переиндексации. При перестроении таблицы идентификатор каждого нового документа проверяется на наличие в "старой" таблице; если найден, его атрибуты переносятся в "новую" таблицу; если нет — используются атрибуты из новой таблицы. Если пользователь обновил атрибуты в таблице, но не обновил источник данных, все изменения будут потеряны при переиндексации; использование --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. Массивы MVA не поддерживаются.
--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 позволяет контролировать, сколько точно оперативной памяти может быть выделено под этот несжатый кэш словаря.

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

max_file_field_buffer = 128M

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

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

max_iosize = 1048576

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

Опция, связанная с ограничением скорости I/O. Ограничивает максимальный размер файловой операции ввода/вывода (чтения или записи) для всех операций, выполняемых indexer. Значение 0 означает отсутствие ограничений. Операции чтения или записи, превышающие лимит, будут разбиты на несколько меньших операций и посчитаны как несколько операций согласно настройке max_iops. На момент написания все операции ввода/вывода должны быть меньше 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

Ограничение использования оперативной памяти при построении простых таблиц. Необязательный параметр, по умолчанию 128 МБ. Принудительный лимит использования памяти, выше которого indexer не поднимется. Можно указать в байтах, килобайтах (с использованием постфикса K) или мегабайтах (с использованием постфикса M); см. пример. Этот лимит будет автоматически повышен, если установлено чрезвычайно низкое значение, приводящее к тому, что буферы ввода-вывода становятся меньше 8 КБ; точная нижняя граница для этого зависит от размера построенных данных. Если буферы меньше 256 КБ, будет выдано предупреждение.

Максимально возможный лимит — 2047M. Слишком низкие значения могут снизить скорость построения простых таблиц, но 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

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

ignore_non_plain = 1

ignore_non_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

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

Автоматическое назначение 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

Планирование запусков indexer через systemd

≫ Извлечение из баз данных