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 с лишними символами < или незакрытыми >).
Обратите внимание, что удаляются только сами теги и 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 stripper также должен быть включен (установкой html_strip = 1). Значение index_zones должно быть списком через запятую имен тегов и подстановочных знаков (заканчивающихся звездочкой), которые будут индексироваться как зоны.
Зоны могут быть вложенными и перекрываться, при условии, что каждый открывающий тег имеет соответствующий закрывающий тег. Зоны также могут использоваться для сопоставления с оператором ZONE, как описано в extended_query_syntax.
- 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 и template таблиц с 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, который слушает на нескольких портах и обслуживает разные протоколы, а затем перенаправляет запросы на серверы бэкенда, которые принимают соединения только через внутренний бинарный протокол 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 будет пытаться подключиться к blackhole-агенту и отправлять запросы как обычно, но не будет ждать или обрабатывать ответы, а все сетевые ошибки на blackhole-агентах будут игнорироваться. Формат значения идентичен формату обычной директивы 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 secДиректива agent_query_timeout задаёт время ожидания выполнения запроса удалённым агентом. Значение по умолчанию — 3000 миллисекунд (3 секунды), но может иметь суффикс для указания другой единицы времени.
После установления соединения searchd будет ждать не более agent_query_timeout для завершения удалённых запросов. Обратите внимание, что этот таймаут отличается от agent_connection_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— целое число, указывающее количество попыток подключения и запроса к удалённым агентам в распределённой таблице до сообщения о фатальной ошибке. Значение по умолчанию — 0 (т.е. без повторных попыток). Это значение также можно задать для каждого запроса с помощью опции 'OPTION retry_count=XXX'. Если задана опция для конкретного запроса, она имеет приоритет над значением из конфигурации.
Обратите внимание, что если вы используете agent mirrors в определении вашей распределённой таблицы, сервер будет выбирать другой mirror перед каждой попыткой подключения согласно указанной ha_strategy. В этом случае значение agent_retry_count будет суммироваться для всех mirrors в наборе.
Например, если у вас 10 mirrors и задано agent_retry_count=5, сервер попытается выполнить до 50 повторных попыток (в среднем 5 попыток на каждые 10 mirrors). В случае опции ha_strategy = roundrobin будет ровно 5 попыток на каждый mirror.
При этом значение, заданное в опции retry_count в определении agent, служит абсолютным лимитом. Другими словами, опция [retry_count=2] в определении агента означает максимум 2 попытки, независимо от того, 1 или 10 mirrors в строке.
Директива 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-адреса имён агентов кэшируются при запуске сервера, чтобы избежать чрезмерных обращений к 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 к такому неправильному агенту вызовет ошибку.
Для получения дополнительной информации о выполнении запросов к распределённой перколяторной таблице смотрите выполнение запросов к распределённой перколяторной таблице.