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
}Manticore позволяет создавать распределённые таблицы, которые работают как обычные plain или real-time таблицы, но на самом деле являются коллекцией дочерних таблиц, используемых для поиска. Когда запрос отправляется в распределённую таблицу, он распределяется по всем таблицам в коллекции. Затем сервер собирает и обрабатывает ответы для сортировки и при необходимости перерасчёта значений агрегатов.
С точки зрения клиента, создаётся впечатление, что он выполняет запрос к одной таблице.
Распределённые таблицы могут состоять из любых комбинаций таблиц, включая:
- Локальные таблицы хранения (plain table и Real-Time)
- Удалённые таблицы
- Комбинация локальных и удалённых таблиц
- Percolate таблицы (локальные, удалённые или комбинация)
- Одна локальная и несколько удалённых таблиц или любая другая комбинация
Смешивание percolate и шаблонных таблиц с plain и real-time таблицами не рекомендуется.
Распределённая таблица определяется как тип 'distributed' в конфигурационном файле или через SQL оператор CREATE TABLE
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]
...
}CREATE TABLE distributed_index type='distributed' local='local_index' agent='127.0.0.1:9312:remote_table'Суть распределённой таблицы заключается в списке дочерних таблиц, на которые она ссылается. Существует два типа дочерних таблиц в распределённой таблице:
-
Локальные таблицы: Это таблицы, обслуживаемые на том же сервере, что и распределённая таблица. Для перечисления локальных таблиц используется синтаксис
local =. Вы можете указать несколько локальных таблиц с помощью нескольких строкlocal =или объединить их в один список, разделённый запятыми. -
Удалённые таблицы: Это таблицы, обслуживаемые вне сервера. Для перечисления удалённых таблиц используется синтаксис
agent =. Каждая строка представляет один endpoint или агент. Каждый агент может иметь несколько внешних локаций и опций того, как он должен работать. Подробнее здесь. Важно отметить, что сервер не имеет информации о типе таблицы, с которой он работает. Это может привести к ошибкам, если, например, вы выполнитеCALL PQдля удалённой таблицы 'foo', которая не является percolate таблицей.
Распределенная таблица в Manticore Search действует как "главный узел", который перенаправляет требуемый запрос к другим таблицам и предоставляет объединенные результаты из полученных ответов. Сама таблица не хранит никаких данных. Она может подключаться как к локальным таблицам, так и к таблицам, расположенным на других серверах. Вот пример простой распределенной таблицы:
- Configuration file
- RT mode
- PHP
- Python
- Python-asyncio
- javascript
- Java
- C#
- Rust
table index_dist {
type = distributed
local = index1
local = index2
...
}CREATE TABLE local_dist type='distributed' local='index1' local='index2';$params = [
'body' => [
'settings' => [
'type' => 'distributed',
'local' => [
'index1',
'index2'
]
]
],
'table' => 'products'
];
$index = new \Manticoresearch\Index($client);
$index->create($params);utilsApi.sql('CREATE TABLE local_dist type=\'distributed\' local=\'index1\' local=\'index2\'')await utilsApi.sql('CREATE TABLE local_dist type=\'distributed\' local=\'index1\' local=\'index2\'')res = await utilsApi.sql('CREATE TABLE local_dist type=\'distributed\' local=\'index1\' local=\'index2\'');utilsApi.sql("CREATE TABLE local_dist type='distributed' local='index1' local='index2'");utilsApi.Sql("CREATE TABLE local_dist type='distributed' local='index1' local='index2'");utils_api.sql("CREATE TABLE local_dist type='distributed' local='index1' local='index2'", Some(true)).await;Удалённая таблица в 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.sockhostname — это имя удалённого хоста, port — удалённый TCP-порт, table-list — это список имён таблиц, разделённых запятыми, а квадратные скобки [] обозначают необязательное условие.
Если имя таблицы опущено, предполагается, что это та же таблица, где определена эта строка. Другими словами, при определении агентов для распределённой таблицы 'mycoolindex' можно просто указать адрес, и будет предполагаться, что запрос идёт к таблице mycoolindex на конечных точках агента.
Если номер порта опущен, считается, что он равен 9312. Если он задан, но недопустим (например, 70000), агент будет пропущен.
Вы можете направлять каждого агента к одной или нескольким удалённым таблицам, расположенным на одном или нескольких сетевых серверах без ограничений. Это позволяет несколько различных режимов использования:
- Шардинг по нескольким серверам агентов и создание произвольной топологии кластера
- Шардинг по нескольким серверам агентов, зеркалированным для высокой доступности и балансировки нагрузки
- Шардинг внутри localhost для использования нескольких ядер (хотя проще использовать несколько локальных таблиц)
Все агенты опрашиваются параллельно. Список индексов передаётся удалённому агенту без изменений. Точный способ поиска по этому списку в агенте (последовательно или параллельно) зависит только от конфигурации агента (см. настройку 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на уровне таблицы)blackhole0,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]Для оптимальной производительности рекомендуется помещать удалённые таблицы, расположенные на одном сервере, в одну запись. Например, вместо:
agent = remote:9312:idx1
agent = remote:9312:idx2следует предпочесть:
agent = remote:9312:idx1,idx2agent_persistent = remotebox:9312:index2Опция agent_persistent позволяет устанавливать постоянное соединение с агентом, то есть соединение не закрывается после выполнения запроса. Синтаксис этой директивы такой же, как у директивы agent. Однако вместо открытия нового соединения с агентом для каждого запроса и последующего его закрытия мастер будет поддерживать открытое соединение и повторно использовать его для последующих запросов. Максимальное количество постоянных соединений на хост агента задаётся опцией persistent_connections_limit в секции searchd.
Важно отметить, что значение persistent_connections_limit должно быть больше 0 для использования постоянных соединений с агентом. Если оно не определено, по умолчанию равно 0, и директива agent_persistent будет работать так же, как agent.
Использование постоянных соединений мастер-агент снижает нагрузку на TCP-порты и экономит время на установку соединений, делая процесс более эффективным.
agent_blackhole = testbox:9312:testindex1,testindex2Директива agent_blackhole позволяет пересылать запросы к удалённым агентам без ожидания или обработки их ответов. Это полезно для отладки или тестирования продакшн-кластеров, так как можно настроить отдельный экземпляр для отладки/тестирования и пересылать запросы к нему с продакшн-мастера (агрегатора) без вмешательства в продакшн-работу. Мастер searchd будет пытаться подключиться к агенту-черной дыре и отправлять запросы как обычно, но не будет ждать и обрабатывать ответы, а все сетевые ошибки на агентах-черных дырах будут игнорироваться. Формат значения идентичен директиве agent.
agent_connect_timeout = 300Директива agent_connect_timeout задает таймаут подключения к удалённым агентам. По умолчанию значение считается в миллисекундах, но может иметь другой суффикс). Значение по умолчанию — 1000 (1 секунда).
При подключении к удалённым агентам searchd будет ждать максимум это время, чтобы успешно установить соединение. Если таймаут достигнут, но соединение так и не установлено, и включены retries, будет выполнена попытка повторного подключения.
agent_query_timeout = 10000 # our query can be long, allow up to 10 secagent_query_timeout устанавливает время, в течение которого searchd будет ждать завершения запроса от удалённого агента. Значение по умолчанию — 3000 миллисекунд (3 секунды), но оно может иметь суффикс для указания другой единицы времени.
После установления соединения searchd будет ждать максимум agent_query_timeout для выполнения удалённых запросов. Обратите внимание, что этот таймаут отличается от agent_connect_timeout, и общая задержка, вызванная удалённым агентом, будет суммой обоих значений. Если время agent_query_timeout истечёт, запрос не будет повторяться, вместо этого будет выведено предупреждение.
Также поведение зависит от reset_network_timeout_on_packet
agent_retry_count — целое число, определяющее, сколько раз Manticore попытается подключиться и выполнить запрос удалённым агентам в распределённой таблице до сообщения о фатальной ошибке запроса. Работает аналогично agent_retry_count, заданному в разделе "searchd" конфигурационного файла, но применяется конкретно для таблицы.
mirror_retry_count выполняет ту же функцию, что и agent_retry_count. Если заданы оба значения, приоритет будет у mirror_retry_count, и будет выведено предупреждение.
Следующие параметры управляют общим поведением удалённых агентов и задаются в разделе searchd конфигурационного файла. Они устанавливают значения по умолчанию для всего экземпляра Manticore.
agent_connect_timeout— значение по умолчанию для параметраagent_connect_timeout.agent_query_timeout— значение по умолчанию для параметраagent_query_timeout. Также может быть переопределено для каждого запроса с использованием того же имени параметра в распределённой (сетевой) таблице.agent_retry_count— целое число, указывающее, сколько раз Manticore будет пытаться подключаться и выполнять запросы удалённым агентам в распределённой таблице до сообщения о фатальной ошибке. Значение по умолчанию — 0 (т.е. без повторных попыток). Это значение также можно задать для каждого запроса с помощью опции 'OPTION retry_count=XXX'. Если задан параметр для отдельного запроса, он будет иметь приоритет над значением из конфига.
Обратите внимание, что при использовании зеркал агентов в определении распределённой таблицы сервер будет выбирать другое зеркало перед каждой попыткой подключения в соответствии с указанной ha_strategy. В этом случае agent_retry_count агрегируется для всех зеркал в наборе.
Например, если у вас есть 10 зеркал и установлено agent_retry_count=5, сервер сделает до 50 попыток (приблизительно 5 попыток на каждые 10 зеркал). В случае опции ha_strategy = roundrobin это будет ровно по 5 попыток на каждое зеркало.
При этом значение, заданное в опции retry_count в определении agent служит абсолютным лимитом. Другими словами, опция [retry_count=2] в определении агента означает максимум 2 попытки, независимо от того, сколько зеркал (1 или 10) в строке.
agent_retry_delay — целочисленное значение, определяющее время в миллисекундах, которое Manticore Search будет ждать перед повторной попыткой запросить удалённого агента в случае сбоя. Это значение можно указать глобально в конфигурации searchd или для каждого запроса с помощью директивы OPTION retry_delay=XXX. Если обе опции заданы, приоритет будет у параметра для отдельного запроса. Значение по умолчанию — 500 миллисекунд (0,5 секунды). Этот параметр актуален только если agent_retry_count или параметр OPTION retry_count для запроса больше нуля.
Опция client_timeout устанавливает максимальное время ожидания между запросами при использовании постоянных соединений. Значение задаётся в секундах или с суффиксом времени. Значение по умолчанию — 5 минут.
Пример:
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 к такому неправильному агенту вызовет ошибку.
Для получения дополнительной информации о выполнении запросов к распределённой перколяционной таблице смотрите выполнение запросов к распределённой перколяционной таблице.