В Manticore Search существует два способа управления таблицами:

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

Репликация доступна только в этом режиме.

Вы можете использовать SQL-команды, такие как CREATE TABLE, ALTER TABLE и DROP TABLE для создания и изменения схемы таблицы, а также для её удаления. Этот режим особенно полезен для таблиц реального времени и перколяторов.

Имена таблиц при создании преобразуются в нижний регистр.

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

Чтобы удалить таблицу, удалите её из конфигурационного файла или удалите настройку пути и отправьте серверу сигнал HUP или перезапустите его.

Имена таблиц в этом режиме чувствительны к регистру.

В этом режиме поддерживаются все типы таблиц.

Таблица в реальном времени — это основной тип таблицы в Manticore. Она позволяет добавлять, обновлять и удалять документы, и вы можете видеть эти изменения сразу же. Вы можете настроить таблицу в реальном времени в конфигурационном файле или использовать команды, такие как CREATE, UPDATE, DELETE или ALTER.

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

• несколько дисковых чанков — они сохраняются на диске и структурированы как простая таблица.
• один RAM-чанк — хранится в памяти и собирает все изменения.

Размер RAM-чанка контролируется настройкой rt_mem_limit. Как только этот лимит достигается, RAM-чанк переносится на диск как дисковый чанк. Если дисковых чанков становится слишком много, Manticore объединяет некоторые из них для улучшения производительности.

Вы можете создать новую таблицу в реальном времени двумя способами: с помощью команды CREATE TABLE или через _mapping endpoint HTTP JSON API.

CREATE TABLE products(title text, price float) morphology='stem_en';

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

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

utilsApi.sql('CREATE TABLE forum(title text, price float)')

await utilsApi.sql('CREATE TABLE forum(title text, price float)')

res = await utilsApi.sql('CREATE TABLE forum(title text, price float)');

utilsApi.sql("CREATE TABLE forum(title text, price float)");

utilsApi.Sql("CREATE TABLE forum(title text, price float)");

utils_api.sql("CREATE TABLE forum(title text, price float)", Some(true)).await;

res = await utilsApi.sql('CREATE TABLE forum(title text, price float)');

utilsAPI.Sql(context.Background()).Body("CREATE TABLE forum(title text, price float)").Execute()

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

Query OK, 0 rows affected (0.00 sec)

{
"total":0,
"error":"",
"warning":""
}

ПРИМЕЧАНИЕ: API _mapping требует Manticore Buddy. Если он не работает, убедитесь, что Buddy установлен.

"properties"
{
  "FIELD_NAME_1":
  {
    "type": "FIELD_TYPE_1"
  },
  "FIELD_NAME_2":
  {
    "type": "FIELD_TYPE_2"
  },
  ...
  "FIELD_NAME_N":
  {
    "type": "FIELD_TYPE_M"
  }
}

POST /your_table_name/_mapping -d '
{
  "properties": {
    "price": {
        "type": "float"
    },
    "title": {
        "type": "text"
    }
  }
}
'

{
"total":0,
"error":"",
"warning":""
}

CREATE TABLE [IF NOT EXISTS] table_name LIKE old_table_name [WITH DATA]

create table products LIKE old_products;

create table products LIKE old_products WITH DATA;

• Добавлять документы.
• Обновлять атрибуты и полнотекстовые поля с помощью процесса Update.
• Удалять документы.
• Очищать таблицу.
• Изменять схему онлайн с помощью команды ALTER, как описано в разделе Изменение схемы онлайн.
• Определять таблицу в конфигурационном файле, как подробно описано в разделе Определение таблицы.
• Использовать функцию UUID для автоматического присвоения ID.

• Загружать данные с помощью функции indexer.
• Подключать её к источникам для удобного индексирования из внешнего хранилища.
• Обновите killlist_target, так как он автоматически управляется таблицей реального времени.

В следующей таблице приведены различные расширения файлов и их описания в таблице реального времени:

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

Plain table — это базовый элемент для поиска без перколяции. Он может быть определён только в конфигурационном файле с использованием Plain mode и не поддерживается в RT mode. Обычно используется вместе с source для обработки данных из внешнего хранилища и может быть позже присоединена к real-time table.

Чтобы создать plain table, необходимо определить её в конфигурационном файле. Команда CREATE TABLE её не поддерживает.

source source {
  type             = mysql
  sql_host         = localhost
  sql_user         = myuser
  sql_pass         = mypass
  sql_db           = mydb
  sql_query        = SELECT id, title, description, category_id  from mytable
  sql_attr_uint    = category_id
  sql_field_string = title
 }
table tbl {
  type   = plain
  source = source
  path   = /path/to/table
 }

• Создавать её из внешнего хранилища с помощью source и indexer
• Выполнять обновление на месте для целочисленных, числовых, строковых и MVA атрибутов
• Обновлять его killlist_target

• Вставлять дополнительные данные в таблицу после её создания
• Удалять данные из таблицы
• Создавать, удалять или изменять схему таблицы онлайн
• Использовать UUID для автоматической генерации ID (данные из внешнего хранилища должны содержать уникальный идентификатор)

Числовые атрибуты, включая MVA, — единственные элементы, которые можно обновлять в plain table. Все остальные данные в таблице неизменяемы. Если требуются обновления или новые записи, таблицу необходимо перестраивать. Во время перестройки существующая таблица остаётся доступной для обслуживания запросов, и выполняется процесс, называемый ротацией, когда новая версия готова, она выводится в онлайн, а старая версия удаляется.

Скорость индексирования plain table зависит от нескольких факторов, включая:

• Скорость получения данных из источника
• Настройки токенизации
• Аппаратные характеристики (например, CPU, RAM и производительность диска)

Для небольших наборов данных самым простым вариантом является одна plain table, которая полностью перестраивается по мере необходимости. Такой подход приемлем, когда:

• Данные в таблице не такие свежие, как данные в источнике
• Время построения таблицы увеличивается с ростом объёма данных

Для больших наборов данных plain table может использоваться вместо Real-Time. Сценарий main+delta включает:

• Создание меньшей таблицы для инкрементального индексирования
• Объединение двух таблиц с помощью distributed table

Этот подход позволяет реже перестраивать большую таблицу и чаще обрабатывать обновления из источника. Меньшую таблицу можно перестраивать чаще (например, каждую минуту или даже каждые несколько секунд).

Однако со временем время индексирования меньшей таблицы станет слишком долгим, что потребует перестройки большой таблицы и очистки меньшей.

Схема main+delta подробно объясняется в этом интерактивном курсе.

Механизм kill list и директива killlist_target используются для обеспечения приоритета документов из текущей таблицы над документами из другой таблицы.

Более подробную информацию по этой теме смотрите здесь.

В следующей таблице приведены различные расширения файлов, используемых в plain table, и их описания:

table <table_name>[:<parent table name>] {
...
}

table <table name> {
  type = plain
  path = /path/to/table
  source = <source_name>
  source = <another source_name>
  [stored_fields = <comma separated list of full-text fields that should be stored, all are stored by default, can be empty>]
}

table <table name> {
  type = rt
  path = /path/to/table
  rt_field = <full-text field name>
  rt_field = <another full-text field name>
  [rt_attr_uint = <integer field name>]
  [rt_attr_uint = <another integer field name, limit by N bits>:N]
  [rt_attr_bigint = <bigint field name>]
  [rt_attr_bigint = <another bigint field name>]
  [rt_attr_multi = <multi-integer (MVA) field name>]
  [rt_attr_multi = <another multi-integer (MVA) field name>]
  [rt_attr_multi_64 = <multi-bigint (MVA) field name>]
  [rt_attr_multi_64 = <another multi-bigint (MVA) field name>]
  [rt_attr_float = <float field name>]
  [rt_attr_float = <another float field name>]
  [rt_attr_float_vector = <float vector field name>]
  [rt_attr_float_vector = <another float vector field name>]
  [rt_attr_bool = <boolean field name>]
  [rt_attr_bool = <another boolean field name>]
  [rt_attr_string = <string field name>]
  [rt_attr_string = <another string field name>]
  [rt_attr_json = <json field name>]
  [rt_attr_json = <another json field name>]
  [rt_attr_timestamp = <timestamp field name>]
  [rt_attr_timestamp = <another timestamp field name>]
  [stored_fields = <comma separated list of full-text fields that should be stored, all are stored by default, can be empty>]
  [rt_mem_limit = <RAM chunk max size, default 128M>]
  [optimize_cutoff = <max number of RT table disk chunks>]
}

type = plain
type = rt

Тип таблицы: "plain" или "rt" (реального времени)

Значение: plain (по умолчанию), rt

path = path/to/table

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

Значение: Путь к таблице, обязательно

stored_fields = title, content

CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)

POST /cli -d "
CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)"

$params = [
    'body' => [
        'columns' => [
            'title'=>['type'=>'text'],
            'content'=>['type'=>'text', 'options' => ['indexed', 'stored']],
            'name'=>['type'=>'text', 'options' => ['indexed']],
            'price'=>['type'=>'float']
        ]
    ],
    'table' => 'products'
];
$index = new \Manticoresearch\Index($client);
$index->create($params);

utilsApi.sql('CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)')

await utilsApi.sql('CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)')

res = await utilsApi.sql('CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)');

utilsApi.sql("CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)");

utilsApi.Sql("CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)");

utils_api.sql("CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)", Some(true)).await;

res = await utilsApi.sql('CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)');

utilsAPI.Sql(context.Background()).Body("CREATE TABLE products(title text, content text stored indexed, name text indexed, price float)").Execute()

table products {
  stored_fields = title, content # we want to store only "title" and "content", "name" shouldn't be stored
  type = rt
  path = tbl
  rt_field = title
  rt_field = content
  rt_field = name
  rt_attr_uint = price
}

stored_only_fields = title,content

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

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

Вы можете сделать это двумя способами:

• В обычном режиме в конфигурации таблицы используйте настройку stored_only_fields.
• В SQL-интерфейсе (RT режим) используйте свойство stored при определении текстового поля (вместо indexed или indexed stored). В SQL не нужно включать stored_only_fields — оно не поддерживается в операторах CREATE TABLE.

Значение stored_only_fields — это список имён полей, разделённых запятыми. По умолчанию пусто. Если вы используете таблицу реального времени, каждое поле, указанное в stored_only_fields, также должно быть объявлено как rt_field.

Примечание: не нужно включать атрибуты в stored_only_fields, так как их оригинальные значения сохраняются в любом случае.

Сравнение полей только для хранения и строковых атрибутов:

• Поле только для хранения:

  • Хранится только на диске
  • Сжатый формат
  • Можно только получить (не используется для фильтрации, сортировки и т.д.)

• Строковый атрибут:

  • Хранится на диске и в памяти
  • Несжатый формат (если не используется колоночное хранение)
  • Может использоваться для сортировки, фильтрации, группировки и т.д.

Если вы хотите, чтобы Manticore хранил текстовые данные, которые вы только хотите хранить на диске (например, json данные, возвращаемые с каждым результатом), и не хранить в памяти или делать их доступными для поиска/фильтрации/группировки, используйте stored_only_fields или stored как свойство текстового поля.

При создании таблиц через SQL-интерфейс пометьте текстовое поле как stored (а не indexed или indexed stored). Вам не понадобится опция stored_only_fields в операторе CREATE TABLE; её включение может привести к ошибке запроса.

json_secondary_indexes = json_attr

CREATE TABLE products(title text, j json secondary_index='1')

POST /cli -d "
CREATE TABLE products(title text, j json secondary_index='1')"

$params = [
    'body' => [
        'columns' => [
            'title'=>['type'=>'text'],
            'j'=>['type'=>'json', 'options' => ['secondary_index' => 1]]
        ]
    ],
    'table' => 'products'
];
$index = new \Manticoresearch\Index($client);
$index->create($params);

utilsApi.sql('CREATE TABLE products(title text, j json secondary_index='1')')

await utilsApi.sql('CREATE TABLE products(title text, j json secondary_index='1')')

res = await utilsApi.sql('CREATE TABLE products(title text, j json secondary_index=\'1\')');

utilsApi.sql("CREATE TABLE products(title text, j json secondary_index='1')");

utilsApi.Sql("CREATE TABLE products(title text, j json secondary_index='1')");

utils_api.sql("CREATE TABLE products(title text, j json secondary_index='1')", Some(true)).await;

res = await utilsApi.sql('CREATE TABLE products(title text, j json secondary_index=\'1\')');

utilsAPI.Sql(context.Background()).Body("CREATE TABLE products(title text, j json secondary_index='1')").Execute()

table products {
  json_secondary_indexes = j
  type = rt
  path = tbl
  rt_field = title
  rt_attr_json = j
}

diskchunk_flush_search_timeout = 10s

Таймаут для предотвращения автоматической очистки RAM-чанка, если в таблице нет поисковых запросов. Подробнее см. здесь.

diskchunk_flush_write_timeout = 60s

Таймаут для автоматической очистки RAM-чанка, если в него не записываются данные. Подробнее см. здесь.

Максимальное количество дисковых чанков для RT-таблицы. Подробнее см. здесь.

rt_field = subject

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

Это поле с множественными значениями, необязательное.

rt_attr_uint = gid

Это объявление определяет атрибут беззнакового целого числа.

Значение: имя поля или field_name:N (где N — максимальное количество бит для хранения).

rt_attr_bigint = gid

Это объявление определяет атрибут BIGINT.

Значение: имя поля, допускается несколько записей.

rt_attr_multi = tags

Объявляет атрибут с множественными значениями (MVA) с беззнаковыми 32-битными целочисленными значениями.

Значение: имя поля. Допускается несколько записей.

rt_attr_multi_64 = wide_tags

Объявляет атрибут с множественными значениями (MVA) с знаковыми 64-битными значениями BIGINT.

Значение: имя поля. Допускается несколько записей.

rt_attr_float = lat
rt_attr_float = lon

Объявляет атрибуты с плавающей точкой одинарной точности, формат IEEE 754, 32-битный.

Значение: имя поля. Допускается несколько записей.

rt_attr_float_vector = image_vector
rt_attr_float_vector = text_vector

Объявляет вектор значений с плавающей точкой для хранения эмбеддингов и обеспечения поиска по векторам методом k-ближайших соседей (KNN).

Значение: имя поля. Допускается несколько записей.

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

Важно: Атрибуты с векторами с плавающей точкой требуют дополнительной конфигурации KNN для включения возможностей векторного поиска.

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

rt_attr_float_vector = image_vector
rt_attr_float_vector = text_vector
knn = {"attrs":[{"name":"image_vector","type":"hnsw","dims":768,"hnsw_similarity":"COSINE","hnsw_m":16,"hnsw_ef_construction":200},{"name":"text_vector","type":"hnsw","dims":768,"hnsw_similarity":"COSINE","hnsw_m":16,"hnsw_ef_construction":200}]}

Обязательные параметры KNN:

• name: имя векторного атрибута (должно совпадать с именем rt_attr_float_vector)
• type: тип индекса, в настоящее время поддерживается только "hnsw"
• dims: количество измерений в векторах (должно соответствовать выходу вашей модели эмбеддингов)
• hnsw_similarity: функция расстояния — "L2", "IP" (внутреннее произведение) или "COSINE"

Необязательные параметры KNN:

• hnsw_m: максимальное количество связей в графе
• hnsw_ef_construction: компромисс между временем построения и точностью

Для подробностей о векторном поиске KNN смотрите документацию KNN.

rt_attr_bool = available

Объявляет булев атрибут с 1-битными беззнаковыми целочисленными значениями.

Значение: имя поля.

rt_attr_string = title

Объявление строкового атрибута.

Значение: имя поля.

rt_attr_json = properties

Объявляет JSON-атрибут.

Значение: имя поля.

rt_attr_timestamp = date_added

Объявляет атрибут временной метки.

Значение: имя поля.

rt_mem_limit = 512M

Ограничение памяти для RAM-чанка таблицы. Необязательно, по умолчанию 128M.

RT-таблицы хранят часть данных в памяти, известную как "RAM-чанк", а также поддерживают несколько таблиц на диске, называемых "дисковыми чанками". Эта директива позволяет контролировать размер RAM-чанка. Когда данных слишком много для хранения в памяти, RT-таблицы сбрасывают их на диск, активируют вновь созданный дисковый чанк и сбрасывают RAM-чанк.

Обратите внимание, что ограничение строгое, и RT-таблицы никогда не выделяют памяти больше, чем указано в rt_mem_limit. Кроме того, память не выделяется заранее, поэтому при указании лимита 512 МБ и вставке только 3 МБ данных будет выделено только 3 МБ, а не 512 МБ.

rt_mem_limit никогда не превышается, но фактический размер RAM-чанка может быть значительно меньше лимита. RT-таблицы адаптируются к скорости вставки данных и динамически регулируют фактический лимит, чтобы минимизировать использование памяти и максимизировать скорость записи данных. Вот как это работает:

• По умолчанию размер RAM-чанка составляет 50% от rt_mem_limit, это называется "rt_mem_limit лимит".
• Как только RAM-чанк накапливает данных, эквивалентных rt_mem_limit * rate (по умолчанию 50% от rt_mem_limit), Manticore начинает сохранять RAM-чанк как новый дисковый чанк.
• Во время сохранения нового дискового чанка Manticore оценивает количество новых/обновленных документов.
• После сохранения нового дискового чанка значение rt_mem_limit rate обновляется.
• Rate сбрасывается до 50% при каждом перезапуске searchd.

Например, если на диск сохранено 90 МБ данных, и во время сохранения поступило еще 10 МБ, rate будет 90%. В следующий раз RT-таблица будет собирать до 90% от rt_mem_limit перед сбросом данных. Чем быстрее скорость вставки, тем ниже rate rt_mem_limit. Rate варьируется от 33.3% до 95%. Текущий rate таблицы можно посмотреть с помощью команды SHOW TABLE STATUS.

В режиме реального времени вы можете настроить ограничение размера RAM-чанков и максимальное количество дисковых чанков с помощью оператора ALTER TABLE. Чтобы установить rt_mem_limit в 1 гигабайт для таблицы "t", выполните следующий запрос: ALTER TABLE t rt_mem_limit='1G'. Чтобы изменить максимальное количество дисковых чанков, выполните запрос: ALTER TABLE t optimize_cutoff='5'.

В обычном режиме вы можете изменить значения rt_mem_limit и optimize_cutoff, обновив конфигурацию таблицы или выполнив команду ALTER TABLE <table_name> RECONFIGURE

• Таблицы реального времени похожи на распределённые, состоящие из нескольких локальных таблиц, также известных как дисковые чанки.
• Каждый RAM-чанк состоит из нескольких сегментов, которые являются специальными таблицами, работающими только в памяти.
• В то время как дисковые чанки хранятся на диске, RAM-чанки хранятся в памяти.
• Каждая транзакция, выполненная с таблицей реального времени, создаёт новый сегмент, и сегменты RAM-чанка объединяются после каждого коммита транзакции. Более эффективно выполнять массовые INSERT-операции сотнями или тысячами документов, чем множество отдельных INSERT-операций с одним документом, чтобы уменьшить накладные расходы на слияние сегментов RAM-чанка.
• Когда количество сегментов превышает 32, они объединяются, чтобы сохранить количество ниже 32.
• Таблицы реального времени всегда имеют один RAM-чанк (который может быть пустым) и один или несколько дисковых чанков.
• Слияние больших сегментов занимает больше времени, поэтому лучше избегать очень большого RAM-чанка (и, следовательно, большого значения rt_mem_limit).
• Количество дисковых чанков зависит от данных в таблице и настройки rt_mem_limit.
• Searchd сбрасывает RAM-чанк на диск (в виде сохранённого файла, а не как дисковый чанк) при завершении работы и периодически в соответствии с настройкой rt_flush_period. Сброс нескольких гигабайт на диск может занять некоторое время.
• Большой RAM-чанк создаёт большую нагрузку на хранилище как при сбросе в файл .ram, так и когда RAM-чанк заполняется и сбрасывается на диск как дисковый чанк.
• RAM-чанк поддерживается бинарным журналом до тех пор, пока не будет сброшен на диск, и большая настройка rt_mem_limit увеличит время воспроизведения бинарного журнала и восстановления RAM-чанка.
• RAM-чанк может работать немного медленнее, чем дисковый чанк.
• Хотя сам RAM-чанк не занимает больше памяти, чем rt_mem_limit, Manticore может занимать больше памяти в некоторых случаях, например, когда вы начинаете транзакцию для вставки данных и не коммитите её некоторое время. В этом случае данные, которые вы уже передали в рамках транзакции, останутся в памяти.

Помимо rt_mem_limit, поведение сброса RAM-чанков также зависит от следующих опций и условий:

• Состояние заморозки. Если таблица заморожена, сброс откладывается. Это постоянное правило; ничто не может его переопределить. Если условие rt_mem_limit достигнуто, пока таблица заморожена, все последующие вставки будут задержаны до разморозки таблицы.

• diskchunk_flush_write_timeout: Эта опция задаёт тайм-аут (в секундах) для автоматического сброса RAM-чанка, если в него не происходит запись. Если в течение этого времени запись не происходит, чанк будет сброшен на диск. Установка значения -1 отключает автоматический сброс на основе активности записи. Значение по умолчанию — 1 секунда.

• diskchunk_flush_search_timeout: Эта опция задаёт тайм-аут (в секундах) для предотвращения автоматического сброса RAM-чанка, если в таблице не выполняются поиски. Автоматический сброс произойдёт только если в течение этого времени был хотя бы один поиск. Значение по умолчанию — 30 секунд.

• Текущая оптимизация: Если в данный момент выполняется процесс оптимизации, и количество существующих дисковых чанков достигло или превысило настроенный внутренний порог cutoff, сброс, вызванный тайм-аутом diskchunk_flush_write_timeout или diskchunk_flush_search_timeout, будет пропущен.

• Слишком мало документов в RAM-сегментах: Если количество документов во всех RAM-сегментах ниже минимального порога (8192),

  сброс, вызванный тайм-аутом diskchunk_flush_write_timeout или diskchunk_flush_search_timeout, будет пропущен, чтобы избежать создания очень маленьких дисковых чанков. Это помогает минимизировать ненужные записи на диск и фрагментацию чанков. Эти тайм-ауты работают совместно. RAM-чанк будет сброшен, если достигнут любой из тайм-аутов. Это гарантирует, что даже при отсутствии записей данные в конечном итоге будут сохранены на диск, и наоборот, даже при постоянных записях, но отсутствии поисков, данные также будут сохранены. Эти настройки обеспечивают более тонкий контроль над частотой сброса RAM-чанков, балансируя потребность в сохранности данных и производительность. Директивы на уровне таблицы для этих настроек имеют более высокий приоритет и переопределяют значения по умолчанию для всего экземпляра.

source = srcpart1

source = srcpart2
source = srcpart3
Поле source указывает источник, из которого будут получены документы при индексировании текущей таблицы. Должен быть как минимум один источник. Источники могут быть разных типов (например, один может быть MySQL, другой PostgreSQL). Для получения дополнительной информации об индексировании из внешних хранилищ %читайте здесь [../../Data_creation_and_modification/Adding_data_from_external_storages/Plain_tables_creation.md] %

Значение: Имя источника является обязательным. Разрешено несколько значений.

killlist_target = main:kl

Этот параметр определяет таблицу(ы), к которым будет применяться kill-list. Совпадения в целевой таблице, которые обновляются или удаляются в текущей таблице, будут подавлены. В режиме `:kl` документы для подавления берутся из %kill-list [../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md] %. В режиме `:id` все идентификаторы документов из текущей таблицы подавляются в целевой. Если ни один из режимов не указан, будут применяться оба режима. %Подробнее о kill-list здесь [../../Data_creation_and_modification/Adding_data_from_external_storages/Adding_data_to_tables/Killlist_in_plain_tables.md] %

Значение: не указано (по умолчанию), target_table_name:kl, target_table_name:id, target_table_name. Допускается несколько значений

columnar_attrs = *

columnar_attrs = id, attr1, attr2, attr3
Этот параметр конфигурации определяет, какие атрибуты должны храниться в %колоночном хранилище [../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages] % вместо построчного хранилища.

Вы можете установить columnar_attrs = *, чтобы хранить все поддерживаемые типы данных в колоночном хранилище.

Кроме того, id является поддерживаемым атрибутом для хранения в колоночном хранилище.

columnar_strings_no_hash = attr1, attr2, attr3

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

##### Типы данных:

Это создаёт таблицу "products" с двумя полями: "title" (полнотекстовый) и "price" (число с плавающей точкой), и устанавливает "morphology" в "stem_en".

Это создаёт таблицу "products" с тремя полями:

create table ... engine='columnar';

create table ... engine='rowwise';
Параметр engine изменяет стандартное %хранилище атрибутов [../../Creating_a_table/Data_types.md#Row-wise-and-columnar-attribute-storages] % для всех атрибутов в таблице. Вы также можете указать `engine` %отдельно для каждого атрибута [../../Creating_a_table/Data_types.md#How-to-switch-between-the-storages] %.

Для информации о том, как включить колоночное хранилище для простой таблицы, смотрите columnar_attrs.

Значения:

• columnar - Включает колоночное хранилище для всех атрибутов таблицы, кроме json
• rowwise (по умолчанию) - Не изменяет ничего и использует традиционное построчное хранилище для таблицы.

  Другие настройки

Следующие настройки применимы как для таблиц реального времени, так и для простых таблиц, независимо от того, указаны ли они в конфигурационном файле или установлены онлайн с помощью команды CREATE или ALTER.

Manticore поддерживает два режима доступа для чтения данных таблицы: seek+read и mmap. В режиме seek+read сервер использует системный вызов pread для чтения списков документов и позиций ключевых слов, представленных файлами *.spd и *.spp. Сервер использует внутренние буферы чтения для оптимизации процесса чтения, и размер этих буферов можно настроить с помощью опций read_buffer_docs и read_buffer_hits. Также существует опция preopen, которая контролирует, как Manticore открывает файлы при запуске.

В режиме доступа mmap поисковый сервер отображает файл таблицы в память с помощью системного вызова mmap, а ОС кэширует содержимое файла. Опции read_buffer_docs и read_buffer_hits не влияют на соответствующие файлы в этом режиме. mmap-ридер также может заблокировать данные таблицы в памяти с помощью привилегированного вызова mlock, что предотвращает выгрузку кэшированных данных на диск ОС.

Для управления используемым режимом доступа доступны опции access_plain_attrs, access_blob_attrs, access_doclists, access_hitlists и access_dict со следующими значениями:

| Значение | Описание |

| - | - | | file | сервер читает файлы таблицы с диска с помощью seek+read, используя внутренние буферы при доступе к файлу | | mmap | сервер отображает файлы таблицы в память, и ОС кэширует их содержимое при доступе к файлу | | mmap_preread | сервер отображает файлы таблицы в память, и фоновый поток один раз читает их для прогрева кэша | | mlock | сервер отображает файлы таблицы в память, а затем выполняет системный вызов mlock() для кэширования содержимого файла и блокировки его в памяти, чтобы предотвратить выгрузку | | Настройка | Значения | Описание |

| - | - | - | | access_plain_attrs | mmap, mmap_preread (по умолчанию), mlock | контролирует, как будут читаться *.spa (простые атрибуты), *.spe (skip lists), *.spt (lookups), *.spm (killed docs) | | access_blob_attrs | mmap, mmap_preread (по умолчанию), mlock | контролирует, как будут читаться *.spb (blob-атрибуты) (строковые, MVA и JSON атрибуты) | | access_doclists | file (по умолчанию), mmap, mlock | контролирует, как будут читаться данные *.spd (списки документов) | | access_hitlists | file (по умолчанию), mmap, mlock | контролирует, как будут читаться данные *.spp (списки попаданий) | | access_dict | mmap, mmap_preread (по умолчанию), mlock | контролирует, как будет читаться *.spi (словарь) | Ниже приведена таблица, которая поможет выбрать желаемый режим:

| часть таблицы | оставлять на диске | хранить в памяти | кэшировать в памяти при запуске сервера | блокировать в памяти |

| - | - | - | - | - | | простые атрибуты в построчном (не колоночном) хранении, skip lists, списки слов, lookups, killed docs | mmap | mmap | mmap_preread (по умолчанию) | mlock | | построчные строковые, мультизначные атрибуты (MVA) и JSON атрибуты | mmap | mmap | mmap_preread (по умолчанию) | mlock | | колоночные числовые, строковые и мультизначные атрибуты | всегда | только средствами ОС | нет | не поддерживается | | списки документов | file (по умолчанию) | mmap | нет | mlock | | списки попаданий | file (по умолчанию) | mmap | нет | mlock | | словарь | mmap | mmap | mmap_preread (по умолчанию) | mlock |

• Для максимально быстрого времени отклика поиска и достаточного объема памяти используйте построчные атрибуты и блокируйте их в памяти с помощью mlock. Дополнительно используйте mlock для doclists/hitlists.

• Если вы отдаёте предпочтение тому, что нельзя допустить снижение производительности после запуска и готовы принять более длительное время запуска, используйте опцию --force-preread. Если вы хотите более быстрый перезапуск searchd, придерживайтесь опции по умолчанию mmap_preread.

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

• Если построчные атрибуты не помещаются в память, выберите колоночные атрибуты.

• Если производительность полнотекстового поиска не является приоритетом, и вы хотите сэкономить память, используйте access_doclists/access_hitlists=file. Режим по умолчанию предлагает баланс:

• mmap,

• предварительное чтение неколоночных атрибутов,

• seek+read колоночных атрибутов без предварительного чтения,

• seek+read doclists/hitlists без предварительного чтения. Это обеспечивает достойную производительность поиска, оптимальное использование памяти и более быстрый перезапуск searchd в большинстве сценариев.

attr_update_reserve = 256k

Эта настройка резервирует дополнительное пространство для обновлений blob-атрибутов, таких как мультизначные атрибуты (MVA), строки и JSON. Значение по умолчанию — 128k. При обновлении этих атрибутов их длина может изменяться. Если обновленная строка короче предыдущей, она перезапишет старые данные в файле `*.spb`. Если обновленная строка длиннее, она будет записана в конец файла `*.spb`. Этот файл отображается в память, что делает изменение его размера потенциально медленным процессом, в зависимости от реализации отображения файлов в память в операционной системе. Чтобы избежать частого изменения размера, можно использовать эту настройку для резервирования дополнительного пространства в конце файла .spb.

Значение: размер, по умолчанию 128k.

docstore_block_size = 32k

This setting controls the size of blocks used by the document storage. The default value is 16kb. When original document text is stored using stored_fields or stored_only_fields, it is stored within the table and compressed for efficiency. To optimize disk access and compression ratios for small documents, these documents are concatenated into blocks. The indexing process collects documents until their total size reaches the threshold specified by this option. At that point, the block of documents is compressed. This option can be adjusted to achieve better compression ratios (by increasing the block size) or faster access to document text (by decreasing the block size).

Value: size, default 16k.

docstore_compression = lz4hc

This setting determines the type of compression used for compressing blocks of documents stored in document storage. If stored_fields or stored_only_fields are specified, the document storage stores compressed document blocks. 'lz4' offers fast compression and decompression speeds, while 'lz4hc' (high compression) sacrifices some compression speed for a better compression ratio. 'none' disables compression completely.

Values: lz4 (default), lz4hc, none.

docstore_compression_level = 12

The compression level used when 'lz4hc' compression is applied in document storage. By adjusting the compression level, you can find the right balance between performance and compression ratio when using 'lz4hc' compression. Note that this option is not applicable when using 'lz4' compression.

Value: An integer between 1 and 12, with a default of 9.

preopen = 1

This setting indicates that searchd should open all table files on startup or rotation, and keep them open while running. By default, the files are not pre-opened. Pre-opened tables require a few file descriptors per table, but they eliminate the need for per-query open() calls and are immune to race conditions that might occur during table rotation under high load. However, if you are serving many tables, it may still be more efficient to open them on a per-query basis in order to conserve file descriptors.

Value: 0 (default), or 1.

read_buffer_docs = 1M

Buffer size for storing the list of documents per keyword. Increasing this value will result in higher memory usage during query execution, but may reduce I/O time.

Value: size, default 256k, minimum value is 8k.

read_buffer_hits = 1M

Buffer size for storing the list of hits per keyword. Increasing this value will result in higher memory usage during query execution, but may reduce I/O time.

Value: size, default 256k, minimum value is 8k.

inplace_enable = {0|1}

Enables in-place table inversion. Optional, default is 0 (uses separate temporary files).

  inplace_enable = 1
  path = products
  source = src_base
}
#### inplace_hit_gap

inplace_hit_gap = size

The option %In-place inversion [../../Creating_a_table/Local_tables/Plain_and_real-time_table_settings.md#inplace_enable] % fine-tuning option. Controls preallocated hitlist gap size. Optional, default is 0.

  inplace_hit_gap = 1M
  inplace_enable = 1
  path = products
  source = src_base
}
#### inplace_reloc_factor

inplace_reloc_factor = 0.1

The inplace_reloc_factor setting determines the size of the relocation buffer within the memory arena used during indexing. The default value is 0.1.

  inplace_reloc_factor = 0.1
  inplace_enable = 1
  path = products
  source = src_base
}
#### inplace_write_factor

inplace_write_factor = 0.1

Controls the size of the buffer used for in-place writing during indexing. Optional, with a default value of 0.1.

  inplace_write_factor = 0.1
  inplace_enable = 1
  path = products
  source = src_base
}
### Специфические настройки обработки естественного языка

Поддерживаются следующие настройки. Все они описаны в разделе NLP и токенизация.

• bigram_freq_words
• bigram_index
• blend_chars
• blend_mode
• charset_table
• dict
• embedded_limit
• exceptions
• expand_keywords
• global_idf
• hitless_words
• html_index_attrs
• html_remove_elements
• html_strip
• ignore_chars
• index_exact_words
• index_field_lengths
• index_sp
• index_token_filter
• index_zones
• infix_fields
• killlist_target
• max_substring_len
• min_infix_len
• min_prefix_len
• min_stemming_len
• min_word_len
• morphology
• morphology_skip_fields
• ngram_chars
• ngram_len
• overshort_step
• phrase_boundary
• phrase_boundary_step
• prefix_fields
• regexp_filter
• stopwords
• stopword_step
• stopwords_unstemmed
• stored_fields
• stored_only_fields
• wordforms
• wordforms