Создание распределенной таблицы > Создание локальной распределенной таблицы

html_strip = {0|1}

Эта опция определяет, следует ли удалять HTML-разметку из входящих полнотекстовых данных. Значение по умолчанию — 0, что отключает удаление. Чтобы включить удаление, установите значение 1.

HTML-теги и сущности считаются разметкой и будут обработаны.

HTML-теги удаляются, а содержимое между ними (например, всё между <p> и </p>) остаётся нетронутым. Вы можете выбрать сохранение и индексацию атрибутов тегов (например, атрибута HREF в теге A или ALT в теге IMG). Некоторые известные строчные теги, такие как A, B, I, S, U, BASEFONT, BIG, EM, FONT, IMG, LABEL, SMALL, SPAN, STRIKE, STRONG, SUB, SUP и TT, удаляются полностью. Все остальные теги рассматриваются как блочные и заменяются пробелами. Например, текст te<b>st</b> будет проиндексирован как одно ключевое слово 'test', а te<p>st</p> — как два ключевых слова 'te' и 'st'.

HTML-сущности декодируются и заменяются соответствующими UTF-8 символами. Удалитель поддерживает как числовые формы (например, ï), так и текстовые формы (например, ó или  ) сущностей, а также все сущности, указанные в стандарте HTML4.

Удалитель предназначен для работы с правильно сформированным HTML и XHTML, но может давать неожиданные результаты на некорректном вводе (например, HTML с лишними <'s или незакрытыми >'s).

Обратите внимание, что удаляются только сами теги, а также HTML-комментарии. Чтобы удалить содержимое тегов, включая встроенные скрипты, см. опцию html_remove_elements. Ограничений на имена тегов нет, то есть всё, что выглядит как начало, конец тега или комментарий, будет удалено.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
Java
C#
Rust
CONFIG

📋

CREATE TABLE products(title text, price float) html_strip = '1'

POST /cli -d "
CREATE TABLE products(title text, price float) html_strip = '1'"

$index = new \Manticoresearch\Index($client);
$index->setName('products');
$index->create([
            'title'=>['type'=>'text'],
            'price'=>['type'=>'float']
        ],[
            'html_strip' => '1'
        ]);

utilsApi.sql('CREATE TABLE products(title text, price float) html_strip = \'1\'')

await utilsApi.sql('CREATE TABLE products(title text, price float) html_strip = \'1\'')

res = await utilsApi.sql('CREATE TABLE products(title text, price float) html_strip = \'1\'');

utilsApi.sql("CREATE TABLE products(title text, price float) html_strip = '1'");

utilsApi.Sql("CREATE TABLE products(title text, price float) html_strip = '1'");

utils_api.sql("CREATE TABLE products(title text, price float) html_strip = '1'", Some(true)).await;

table products {
  html_strip = 1
  type = rt
  path = tbl
  rt_field = title
  rt_attr_uint = price
}

html_index_attrs = img=alt,title; a=title;

Опция html_index_attrs позволяет указать, какие атрибуты HTML-разметки должны индексироваться, даже если остальная HTML-разметка удаляется. Значение по умолчанию — пустое, что означает, что атрибуты не будут индексироваться. Формат опции — перечисление индексируемых атрибутов для каждого тега, как показано в примере выше. Содержимое указанных атрибутов будет сохранено и проиндексировано, предоставляя способ извлечения дополнительной информации из ваших полнотекстовых данных.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
Java
C#
Rust
CONFIG

📋

CREATE TABLE products(title text, price float) html_index_attrs = 'img=alt,title; a=title;' html_strip = '1'

POST /cli -d "
CREATE TABLE products(title text, price float) html_index_attrs = 'img=alt,title; a=title;' html_strip = '1'"

$index = new \Manticoresearch\Index($client);
$index->setName('products');
$index->create([
            'title'=>['type'=>'text'],
            'price'=>['type'=>'float']
        ],[
            'html_index_attrs' => 'img=alt,title; a=title;',
            'html_strip' => '1'
        ]);

utilsApi.sql('CREATE TABLE products(title text, price float) html_index_attrs = \'img=alt,title; a=title;\' html_strip = \'1\'')

await utilsApi.sql('CREATE TABLE products(title text, price float) html_index_attrs = \'img=alt,title; a=title;\' html_strip = \'1\'')

res = await utilsApi.sql('CREATE TABLE products(title text, price float) html_index_attrs = \'img=alt,title; a=title;\' html_strip = \'1\'');

utilsApi.sql("CREATE TABLE products(title text, price float) html_index_attrs = \'img=alt,title; a=title;\' html_strip = '1'");

utilsApi.Sql("CREATE TABLE products(title text, price float) html_index_attrs = \'img=alt,title; a=title;\' html_strip = '1'");

utils_api.sql("CREATE TABLE products(title text, price float) html_index_attrs = \'img=alt,title; a=title;\' html_strip = '1'", Some(true)).await;

table products {
  html_index_attrs = img=alt,title; a=title;
  html_strip = 1
  type = rt
  path = tbl
  rt_field = title
  rt_attr_uint = price
}

html_remove_elements = element1[, element2, ...]

Список HTML-элементов, содержимое которых, вместе с самими элементами, будет удалено. Необязательный параметр, по умолчанию — пустая строка (не удалять содержимое никаких элементов).

Эта опция позволяет удалять содержимое элементов, то есть всё между открывающим и закрывающим тегами. Она полезна для удаления встроенных скриптов, CSS и т.д. Короткая форма тега для пустых элементов (например,
) корректно поддерживается, и текст после такого тега не будет удалён.

Значение представляет собой список имён элементов (тегов), разделённых запятыми, содержимое которых должно быть удалено. Имена тегов нечувствительны к регистру.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
Java
C#
Rust
CONFIG

📋

CREATE TABLE products(title text, price float) html_remove_elements = 'style, script' html_strip = '1'

POST /cli -d "
CREATE TABLE products(title text, price float) html_remove_elements = 'style, script' html_strip = '1'"

$index = new \Manticoresearch\Index($client);
$index->setName('products');
$index->create([
            'title'=>['type'=>'text'],
            'price'=>['type'=>'float']
        ],[
            'html_remove_elements' => 'style, script',
            'html_strip' => '1'
        ]);

utilsApi.sql('CREATE TABLE products(title text, price float) html_remove_elements = \'style, script\' html_strip = \'1\'')

await utilsApi.sql('CREATE TABLE products(title text, price float) html_remove_elements = \'style, script\' html_strip = \'1\'')

res = await utilsApi.sql('CREATE TABLE products(title text, price float) html_remove_elements = \'style, script\' html_strip = \'1\'');

utilsApi.sql("CREATE TABLE products(title text, price float) html_remove_elements = \'style, script\' html_strip = '1'");

utilsApi.Sql("CREATE TABLE products(title text, price float) html_remove_elements = \'style, script\' html_strip = '1'");

utils_api.sql("CREATE TABLE products(title text, price float) html_remove_elements = \'style, script\' html_strip = '1'", Some(true)).await;

table products {
  html_remove_elements = style, script
  html_strip = 1
  type = rt
  path = tbl
  rt_field = title
  rt_attr_uint = price
}

index_sp = {0|1}

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

Эта директива включает обнаружение и индексацию границ предложений и абзацев, что позволяет работать операторам SENTENCE и PARAGRAPH. Обнаружение границ предложений основано на анализе простого текста и требует только установки index_sp = 1 для включения. Однако обнаружение абзацев зависит от HTML-разметки и происходит в процессе удаления HTML. Таким образом, для индексации границ абзацев обе директивы, index_sp и html_strip, должны быть установлены в 1.

Для определения границ предложений используются следующие правила:

Вопросительные знаки (?) и восклицательные знаки (!) всегда обозначают границу предложения.
Точки в конце предложения (.) обозначают границу предложения, за исключением следующих случаев:
- Когда за точкой следует буква. Это считается частью аббревиатуры (например, "S.T.A.L.K.E.R." или "Goldman Sachs S.p.A.").
- Когда за точкой следует запятая. Это считается аббревиатурой, за которой следует запятая (например, "Telecom Italia S.p.A., основанная в 1994 году").
- Когда за точкой следует пробел и строчная буква. Это считается аббревиатурой внутри предложения (например, "News Corp. объявила в феврале").
- Когда перед точкой стоит пробел и заглавная буква, а после точки — пробел. Это считается инициалом (например, "John D. Doe").

Границы абзацев определяются по каждому HTML-тегу блочного уровня, включая: ADDRESS, BLOCKQUOTE, CAPTION, CENTER, DD, DIV, DL, DT, H1, H2, H3, H4, H5, LI, MENU, OL, P, PRE, TABLE, TBODY, TD, TFOOT, TH, THEAD, TR и UL.

Как предложения, так и абзацы увеличивают счетчик позиций ключевых слов на 1.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
Java
C#
Rust
CONFIG

📋

CREATE TABLE products(title text, price float) index_sp = '1' html_strip = '1'

POST /cli -d "
CREATE TABLE products(title text, price float) index_sp = '1' html_strip = '1'"

$index = new \Manticoresearch\Index($client);
$index->setName('products');
$index->create([
            'title'=>['type'=>'text'],
            'price'=>['type'=>'float']
        ],[
            'index_sp' => '1',
            'html_strip' => '1'
        ]);

utilsApi.sql('CREATE TABLE products(title text, price float) index_sp = \'1\' html_strip = \'1\'')

await utilsApi.sql('CREATE TABLE products(title text, price float) index_sp = \'1\' html_strip = \'1\'')

res = await utilsApi.sql('CREATE TABLE products(title text, price float) index_sp = \'1\' html_strip = \'1\'');

utilsApi.sql("CREATE TABLE products(title text, price float) index_sp = \'1\' html_strip = '1'", true);

utilsApi.Sql("CREATE TABLE products(title text, price float) index_sp = \'1\' html_strip = '1'", true);

utils_api.sql("CREATE TABLE products(title text, price float) index_sp = \'1\' html_strip = '1'", Some(true)).await;

table products {
  index_sp = 1
  html_strip = 1
  type = rt
  path = tbl
  rt_field = title
  rt_attr_uint = price
}

index_zones = h*, th, title

Список HTML/XML зон внутри поля, которые должны быть проиндексированы. По умолчанию это пустая строка (зоны индексироваться не будут).

"Зона" определяется как всё, что находится между открывающим и соответствующим закрывающим тегом, и все участки с одинаковым именем тега называются "зоной". Например, всё между <H1> и </H1> в поле документа принадлежит зоне H1.

Директива index_zones включает индексацию зон, но также должен быть включен HTML стриппер (путем установки html_strip = 1). Значение index_zones должно быть списком имен тегов и шаблонов (заканчивающихся звездочкой), разделенных запятыми, которые будут индексироваться как зоны.

Зоны могут быть вложенными и перекрываться, при условии, что каждый открывающий тег имеет соответствующий закрывающий тег. Зоны также могут использоваться для сопоставления с оператором ZONE, как описано в расширенном синтаксисе запросов.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
Java
C#
Rust
CONFIG

📋

CREATE TABLE products(title text, price float) index_zones = 'h, th, title' html_strip = '1'

POST /cli -d "
CREATE TABLE products(title text, price float) index_zones = 'h, th, title' html_strip = '1'"

$index = new \Manticoresearch\Index($client);
$index->setName('products');
$index->create([
            'title'=>['type'=>'text'],
            'price'=>['type'=>'float']
        ],[
            'index_zones' => 'h*,th,title',
            'html_strip' => '1'
        ]);

utilsApi.sql('CREATE TABLE products(title text, price float) index_zones = \'h, th, title\' html_strip = \'1\'')

await utilsApi.sql('CREATE TABLE products(title text, price float) index_zones = \'h, th, title\' html_strip = \'1\'')

res = await utilsApi.sql('CREATE TABLE products(title text, price float) index_zones = \'h, th, title\' html_strip = \'1\'');

utilsApi.sql("CREATE TABLE products(title text, price float) index_zones = 'h, th, title' html_strip = '1'", true);

utilsApi.Sql("CREATE TABLE products(title text, price float) index_zones = 'h, th, title' html_strip = '1'", true);

utils_api.sql("CREATE TABLE products(title text, price float) index_zones = 'h, th, title' html_strip = '1'", Some(true)).await;

table products {
  index_zones = h*, th, title
  html_strip = 1
  type = rt
  path = tbl
  rt_field = title
  rt_attr_uint = price
}

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

Last modified: August 28, 2025

Manticore позволяет создавать распределённые таблицы, которые работают как обычные plain или real-time таблицы, но на самом деле являются коллекцией дочерних таблиц, используемых для поиска. Когда запрос отправляется в распределённую таблицу, он распределяется по всем таблицам в коллекции. Затем сервер собирает и обрабатывает ответы для сортировки и при необходимости перерасчёта значений агрегатов.

С точки зрения клиента, создаётся впечатление, что он выполняет запрос к одной таблице.

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

Локальные таблицы хранения (plain table и Real-Time)
Удалённые таблицы
Комбинация локальных и удалённых таблиц
Percolate таблицы (локальные, удалённые или комбинация)
Одна локальная и несколько удалённых таблиц или любая другая комбинация

Смешивание percolate и шаблонных таблиц с plain и real-time таблицами не рекомендуется.

Распределенная таблица определяется как тип 'distributed' в файле конфигурации или через SQL-предложение CREATE TABLE.

‹›

Config
SQL

📋

table foo {
    type = distributed
    local = bar
    local = bar1, bar2
    agent = 127.0.0.1:9312:baz
    agent = host1|host2:tbl
    agent = host1:9301:tbl1|host2:tbl2 [ha_strategy=random retry_count=10]
    ...
}

Суть распределённой таблицы заключается в списке дочерних таблиц, на которые она ссылается. Существует два типа дочерних таблиц в распределённой таблице:

Локальные таблицы: Это таблицы, обслуживаемые на том же сервере, что и распределённая таблица. Для перечисления локальных таблиц используется синтаксис local =. Вы можете указать несколько локальных таблиц с помощью нескольких строк local = или объединить их в один список, разделённый запятыми.
Удалённые таблицы: Это таблицы, обслуживаемые вне сервера. Для перечисления удалённых таблиц используется синтаксис agent =. Каждая строка представляет один endpoint или агент. Каждый агент может иметь несколько внешних локаций и опций того, как он должен работать. Подробнее здесь. Важно отметить, что сервер не имеет информации о типе таблицы, с которой он работает. Это может привести к ошибкам, если, например, вы выполните CALL PQ для удалённой таблицы 'foo', которая не является percolate таблицей.

Расширенная HTML-токенизация Создание локальной распределенной таблицы

Last modified: June 26, 2026

Распределенная таблица в Manticore Search действует как "главный узел", который проксирует требуемый запрос к другим таблицам и предоставляет объединенные результаты из полученных ответов. Сама таблица не хранит никаких данных. Она может подключаться как к локальным таблицам, так и к таблицам, расположенным на других серверах. Локальная распределенная таблица — это просто распределенная таблица, все дочерние таблицы которой являются локальными. Если вам нужно только совместно искать по нескольким локальным таблицам, вы можете запрашивать их напрямую, без создания распределенной таблицы. Если вы все же создаете локальную распределенную таблицу, в SQL вы можете указать несколько локальных таблиц либо путем повторения local='...', либо передав их в виде списка, разделенного запятыми, в одном предложении local='index1,index2'.

‹›

Config
SQL
PHP
Python
Python-asyncio
javascript
Java
C#
Rust

📋

table table_dist {
  type  = distributed
  local = tbl1
  local = tbl2
  ...
 }

CREATE TABLE local_dist type='distributed' local='index1,index2';

$params = [
    'body' => [
        'settings' => [
            'type' => 'distributed',
            'local' => [
                'tbl1',
                'tbl2'
            ]
        ]
    ],
    'table' => 'products'
];
$table = new \Manticoresearch\Table($client);
$table->create($params);

utilsApi.sql('CREATE TABLE local_dist type=\'distributed\' local=\'tbl1\' local=\'tbl2\'')

await utilsApi.sql('CREATE TABLE local_dist type=\'distributed\' local=\'index1\' local=\'index2\'')

res = await utilsApi.sql('CREATE TABLE local_dist type=\'distributed\' local=\'tbl1\' local=\'tbl2\'');

utilsApi.sql("CREATE TABLE local_dist type='distributed' local='tbl1' local='tbl2'");

utilsApi.Sql("CREATE TABLE local_dist type='distributed' local='tbl1' local='tbl2'");

utils_api.sql("CREATE TABLE local_dist type='distributed' local='index1' local='index2'", Some(true)).await;

Прямой запрос к нескольким локальным таблицам работает как в SQL, так и в JSON.

‹›

SQL
JSON

📋

SELECT * FROM index1, index2, index3;

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

Last modified: June 26, 2026

Удалённая таблица в Manticore Search представлена префиксом agent в определении распределённой таблицы. Распределённая таблица может включать сочетание локальных и удалённых таблиц. Если локальные таблицы не указаны, распределённая таблица будет полностью удалённой и будет выступать только как прокси. Например, у вас может быть экземпляр Manticore, который слушает несколько портов и обслуживает разные протоколы, а затем перенаправляет запросы на серверы backend, которые принимают соединения только через внутренний бинарный протокол Manticore, используя постоянные соединения для уменьшения накладных расходов при установлении соединений.
Хотя распределённая таблица, состоящая только из удалённых, сама не содержит локальных таблиц, она всё равно потребляет ресурсы машины, поскольку должна выполнять окончательные вычисления, такие как слияние результатов и вычисление итоговых агрегированных значений.

agent = address1 [ | address2 [...] ][:table-list]
agent = address1[:table-list [ | address2[:table-list [...] ] ] ]

Директива agent объявляет удаленные агенты, которые опрашиваются каждый раз при поиске по охватывающей распределенной таблице. Эти агенты, по сути, являются указателями на сетевые таблицы. Указанное значение включает адрес и также может включать несколько альтернатив (зеркала агента) либо только для адреса, либо для адреса и списка таблиц. См. Зеркалирование для синтаксиса зеркал и Балансировка нагрузки для информации о том, как выбираются зеркальные агенты.

Спецификация адреса должна быть одной из следующих:

address = hostname[:port] # eg. server2:9312
address = /absolute/unix/socket/path # eg. /var/run/manticore2.sock

hostname — это имя удаленного хоста, port — номер удаленного TCP-порта, table-list — это список имен таблиц, разделенных запятыми, а квадратные скобки [] обозначают необязательную часть. Для TCP-соединений этот порт является портом удаленного агента/API (обычно 9312), а не портом MySQL (9306).

Если имя таблицы опущено, предполагается, что это та же таблица, где определена эта строка. Другими словами, при определении агентов для распределённой таблицы 'mycoolindex' можно просто указать адрес, и будет предполагаться, что запрос идёт к таблице mycoolindex на конечных точках агента.

Если номер порта опущен, считается, что он равен 9312. Если он задан, но недопустим (например, 70000), агент будет пропущен.

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

Шардинг по нескольким серверам агентов и создание произвольной топологии кластера
Шардирование по нескольким серверам-агентам с зеркалированием для обеспечения высокой доступности и балансировки нагрузки (см. Зеркалирование и Балансировка нагрузки)
Шардинг внутри localhost для использования нескольких ядер (хотя проще использовать несколько локальных таблиц)

Чтобы избежать путаницы:

Одна запись agent='host1|host2:table' означает один удаленный шард с зеркальными бэкендами.
Несколько записей agent='...' означают несколько удаленных шардов.

Все агенты опрашиваются параллельно. Список индексов передаётся удалённому агенту без изменений. Точный способ поиска по этому списку в агенте (последовательно или параллельно) зависит только от конфигурации агента (см. настройку threads). Мастер не управляет этим удалённо.

Важно отметить, что опция LIMIT игнорируется в запросах к агентам. Это связано с тем, что каждый агент может содержать разные таблицы, и ответственность за применение ограничения к итоговому набору результатов лежит на клиенте. Поэтому запрос к физической таблице отличается от запроса к распределённой таблице, если смотреть в логах запросов. Запрос не может быть простой копией исходного запроса, так как это приведёт к некорректным результатам.

Например, если клиент делает запрос SELECT ... LIMIT 10, 10, а существует два агента, при этом второй агент содержит только 10 документов, трансляция исходного запроса LIMIT 10, 10 приведёт к тому, что от второго агента будут получены 0 документов. Однако запрос LIMIT 10,10 должен вернуть документы с 10 по 20 из итогового набора. Чтобы решить эту проблему, запрос отправляют агентам с более широким ограничением, например, используя значение max_matches по умолчанию 1000.

Например, если есть распределённая таблица dist, которая ссылается на удалённую таблицу user, запрос клиента SELECT * FROM dist LIMIT 10,10 будет преобразован в запрос SELECT * FROM user LIMIT 0,1000 и отправлен удалённой таблице user. После получения результата распределённая таблица применит LIMIT 10,10 и вернёт запрашиваемые 10 документов.

SELECT * FROM dist LIMIT 10,10;

запрос будет преобразован в:

SELECT * FROM user LIMIT 0,1000

Кроме того, значение может содержать опции для каждого отдельного агента, такие как:

ha_strategy - random, roundrobin, nodeads, noerrors (переопределяет глобальную настройку ha_strategy для конкретного агента; см. также Зеркалирование)
conn - pconn, persistent (эквивалентно установке agent_persistent на уровне таблицы)
blackhole 0,1 (идентично настройке agent_blackhole для агента)
retry_count целочисленное значение (соответствует agent_retry_count, но заданное значение не умножается на число зеркал)

agent = address1:table-list[[ha_strategy=value, conn=value, blackhole=value]]

Пример:

# config on box1
# sharding a table over 3 servers
agent = box2:9312:shard1
agent = box3:9312:shard2
# config on box2
# sharding a table over 3 servers
agent = box1:9312:shard2
agent = box3:9312:shard3
# config on box3
# sharding a table over 3 servers
agent = box1:9312:shard1
agent = box2:9312:shard3
# per agent options
agent = box1:9312:shard1[ha_strategy=nodeads]
agent = box2:9312:shard2[conn=pconn]
agent = box2:9312:shard2[conn=pconn,ha_strategy=nodeads]
agent = test:9312:any[blackhole=1]
agent = test:9312|box2:9312|box3:9312:any2[retry_count=2]
agent = test:9312|box2:9312:any2[retry_count=2,conn=pconn,ha_strategy=noerrors]

Удаленные таблицы могут быть определены либо в конфигурационном файле, либо с помощью SQL на распределенной таблице.

‹›

Config
SQL

📋

table products_dist {
  type  = distributed
  agent = 127.0.0.1:9312|127.0.0.1:9313:products
}

Предположим, что удаленные таблицы уже существуют, например:

‹›

SQL

📋

CREATE TABLE products_dist type='distributed'
  agent='127.0.0.1:9312:products|127.0.0.1:9313:products'
  ha_strategy='roundrobin'
  agent_connect_timeout='200ms'
  agent_query_timeout='500ms'
  mirror_retry_count='2';

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

‹›

SQL

📋

SELECT id, title, node FROM products_dist;
SHOW CREATE TABLE products_dist;

‹›

Response

+------+------------+-------+
| id   | title      | node  |
+------+------------+-------+
|    1 | same title | node1 |
+------+------------+-------+
+---------------+----------------------------------------------------------------------------------+
| Table         | Create Table                                                                     |
+---------------+----------------------------------------------------------------------------------+
| products_dist | CREATE TABLE products_dist type='distributed' agent='127.0.0.1:9312:products|... |
+---------------+----------------------------------------------------------------------------------+

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

agent = remote:9312:idx1
agent = remote:9312:idx2

следует предпочесть:

agent = remote:9312:idx1,idx2

‹›

Config

Config

📋

agent_persistent = remotebox:9312:index2

Опция agent_persistent позволяет устанавливать постоянное соединение с агентом, то есть соединение не закрывается после выполнения запроса. Синтаксис этой директивы такой же, как у директивы agent. Однако вместо открытия нового соединения с агентом для каждого запроса и последующего его закрытия мастер будет поддерживать открытое соединение и повторно использовать его для последующих запросов. Максимальное количество постоянных соединений на хост агента задаётся опцией persistent_connections_limit в секции searchd.

Важно отметить, что значение persistent_connections_limit должно быть больше 0 для использования постоянных соединений с агентом. Если оно не определено, по умолчанию равно 0, и директива agent_persistent будет работать так же, как agent.

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

Директива agent_blackhole позволяет перенаправлять запросы удаленным агентам без ожидания или обработки их ответов. Это полезно для отладки или тестирования рабочих кластеров, так как вы можете настроить отдельный экземпляр для отладки/тестирования и перенаправлять ему запросы с рабочего мастера (агрегатора), не мешая рабочему процессу. Master searchd попытается подключиться к агенту-черной дыре и отправить запросы как обычно, но не будет ждать или обрабатывать никакие ответы, а все сетевые ошибки на агентах-черных дырах будут игнорироваться. Формат значения идентичен формату обычной директивы agent.

‹›

Config

Config

📋

agent_blackhole = testbox:9312:testindex1,testindex2

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

Опция	Для всего экземпляра	На таблицу	На запрос	На агента	Полные детали
`ha_strategy`	да	да	нет	да	Балансировка нагрузки, Удаленные таблицы: agent
`agent_connect_timeout`	да	да	нет	нет	Searchd: agent_connect_timeout
`agent_query_timeout`	да	да	да	нет	Searchd: agent_query_timeout
`agent_retry_count` / `mirror_retry_count` / `retry_count`	да (`agent_retry_count`)	да (`agent_retry_count` или `mirror_retry_count`)	да (`OPTION retry_count=...`)	да (`agent=...[retry_count=...]`)	Searchd: agent_retry_count, Удаленные таблицы: mirror_retry_count, Удаленные таблицы: agent
`agent_retry_delay`	да	нет	да	нет	Searchd: agent_retry_delay
per-agent `conn`	нет	нет	нет	да	Удаленные таблицы: agent
per-agent `blackhole`	нет	нет	нет	да	Удаленные таблицы: agent_blackhole

agent_connect_timeout определяет, сколько времени Manticore ждет установления соединения с удаленным агентом. Поддерживается как глобальная настройка по умолчанию для экземпляра и для каждой распределенной таблицы. Полные детали на уровне демона находятся в Searchd: agent_connect_timeout.

‹›

Config
SQL

📋

agent_connect_timeout = 300ms

agent_query_timeout определяет, сколько времени Manticore ждет, пока подключенный удаленный агент завершит выполнение запроса. Поддерживается как глобальная настройка по умолчанию для экземпляра, для каждой распределенной таблицы и для каждого запроса как OPTION agent_query_timeout=.... Полные детали на уровне демона находятся в Searchd: agent_query_timeout.

Если достигается agent_query_timeout, запрос не повторяется автоматически; вместо этого выводится предупреждение. Поведение также зависит от reset_network_timeout_on_packet.

‹›

Config
SQL

📋

agent_query_timeout = 10000 # our query can be long, allow up to 10 sec

agent_retry_count определяет, сколько раз Manticore попытается подключиться к удаленным агентам и выполнить запросы в распределенной таблице, прежде чем сообщить о фатальной ошибке запроса. Имя параметра зависит от области применения: используйте

agent_retry_count как настройку уровня экземпляра,
agent_retry_count или его псевдоним mirror_retry_count для распределенной таблицы,
OPTION retry_count=... для каждого запроса,
и [retry_count=...] внутри отдельного объявления agent=....

Полные детали на уровне демона приведены в разделе Searchd: agent_retry_count.

Если вы используете зеркала агентов, сервер выбирает другое зеркало перед каждой попыткой подключения в соответствии с ha_strategy, а agent_retry_count суммируется по всем зеркалам.

mirror_retry_count служит той же цели, что и agent_retry_count, но только как настройка распределенной таблицы. Если указаны оба значения, приоритет имеет mirror_retry_count.

‹›

Config
SQL

📋

table products_dist {
  type = distributed
  agent = 127.0.0.1:9312|127.0.0.1:9313:products[retry_count=2]
}

agent_retry_delay определяет задержку между повторными попытками. Он поддерживается как глобальная настройка экземпляра по умолчанию и как OPTION retry_delay=... для каждого запроса, но не для распределенной таблицы. Полные детали на уровне демона приведены в разделе Searchd: agent_retry_delay.

Эта опция актуальна только тогда, когда повторные попытки включены через agent_retry_count или OPTION retry_count=....

‹›

Config
SQL

📋

agent_retry_delay = 500ms

Опция client_timeout устанавливает максимальное время ожидания между запросами при использовании постоянных соединений. Это глобальная настройка searchd уровня экземпляра, а не настройка отдельной таблицы. Значение выражается в секундах или с временным суффиксом. Значение по умолчанию составляет 5 минут. Полные детали на уровне демона приведены в разделе Searchd: client_timeout.

‹›

Config

Config

📋

client_timeout = 1h

Опция hostname_lookup определяет стратегию обновления имён хостов. По умолчанию IP-адреса host-имён агентов кешируются при запуске сервера, чтобы избежать чрезмерного обращения к DNS. Однако в некоторых случаях IP может динамически меняться (например, облачный хостинг), и может быть необходимо не кешировать IP. Установка этой опции в request отключает кеширование и выполняет запросы к DNS при каждом запросе. IP-адреса также можно обновлять вручную с помощью команды FLUSH HOSTNAMES.

Опция listen_tfo позволяет использовать флаг TCP_FASTOPEN для всех слушателей. По умолчанию она управляется системой, но может быть явно отключена, установив значение '0'.

Для получения дополнительной информации о расширении TCP Fast Open, пожалуйста, обратитесь к Wikipedia. Кратко, оно позволяет исключить один круг обмена TCP при установлении соединения.

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

Большинство современных операционных систем поддерживают TFO. Linux (как одна из самых прогрессивных) поддерживает его с 2011 года, начиная с ядра 3.7 (для серверной стороны). Windows поддерживает его с некоторых сборок Windows 10. Другие системы, такие как FreeBSD и MacOS, также участвуют.

Для систем Linux сервер проверяет переменную /proc/sys/net/ipv4/tcp_fastopen и действует соответственно. Бит 0 управляет клиентской стороной, а бит 1 управляет слушателями. По умолчанию система имеет этот параметр, установленный в 1, то есть клиенты включены, а слушатели отключены.

persistent_connections_limit = 29 # assume that each host of agents has max_connections = 30 (or 29).

Опция persistent_connections_limit определяет максимальное количество одновременных постоянных соединений с удалёнными постоянными агентами. Это настройка на уровне экземпляра и должна быть определена в секции конфигурации searchd. Каждый раз при установлении соединения с агентом, определённым в agent_persistent, происходит попытка повторно использовать существующее соединение (если оно есть) или создать новое и сохранить его для будущего использования. Однако в некоторых случаях может потребоваться ограничить количество постоянных соединений. Эта директива задаёт лимит и влияет на количество соединений с каждым хостом агента для всех распределённых таблиц.

Рекомендуется установить это значение равным или меньшим, чем опция max_connections в конфигурации агента.

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

snippets_file_prefix = /mnt/common/server1/

Опция snippets_file_prefix — это необязательный префикс, который можно добавить к именам локальных файлов при генерации сниппетов. Значение по умолчанию — текущая рабочая папка.

Чтобы узнать больше о создании распределённых сниппетов, смотрите CALL SNIPPETS.

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

Для DPQ операции перечисления сохранённых запросов и поиска по ним (с использованием CALL PQ) прозрачны и работают так, как если бы все таблицы были одной локальной таблицей. Однако операции манипуляции данными, такие как insert, replace, truncate, отсутствуют.

Если в список агентов включить не перколяционную таблицу, поведение будет неопределённым. Если неправильный агент имеет ту же схему, что и внешняя схема PQ таблицы (id, query, tags, filters), это не вызовет ошибку при перечислении сохранённых правил PQ и может засорить список фактических правил PQ, хранящихся в PQ таблицах, собственными не-PQ строками. В результате будьте осторожны и понимаете путаницу, которую это может вызвать. Вызов CALL PQ к такому неправильному агенту вызовет ошибку.

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

Создание локальной распределенной таблицы Создание шардинговой таблицы

Last modified: May 22, 2026

Расширенная токенизация HTML

Удаление HTML-тегов

html_strip

html_index_attrs

html_remove_elements

Извлечение важных частей из HTML

index_sp

index_zones

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

Дочерние таблицы

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

Удалённые таблицы

agent

Определение удаленных таблиц

agent_persistent

agent_blackhole

Связанные опции и поддерживаемые области видимости

agent_connect_timeout

agent_query_timeout

agent_retry_count

mirror_retry_count

agent_retry_delay

client_timeout

hostname_lookup

listen_tfo

persistent_connections_limit

Создание распределённых сниппетов

snippets_file_prefix

Распределённые перколяционные таблицы (DPQ таблицы)