Со временем RT-таблицы могут фрагментироваться на множество дисковых чанков и/или содержать удаленные, но не очищенные данные, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет дисковые чанки (N-путевое слияние), удаляя документы, которые ранее были удалены с помощью операторов DELETE.
Начиная с Manticore 4, этот процесс происходит автоматически по умолчанию. Однако вы также можете использовать следующие команды для ручного запуска компактизации таблицы.
OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]]Оператор OPTIMIZE добавляет RT-таблицу в очередь оптимизации, которая будет обработана в фоновом потоке.
- SQL
OPTIMIZE TABLE rt;По умолчанию OPTIMIZE объединяет дисковые чанки RT-таблицы до количества, меньшего или равного количеству логических ядер CPU, умноженному на 2.
Однако, если таблица имеет атрибуты с KNN-индексами, этот порог отличается. В этом случае он устанавливается равным количеству физических ядер CPU, деленному на 2, для повышения производительности KNN-поиска.
Вы также можете управлять количеством оптимизированных дисковых чанков вручную с помощью опции cutoff.
Дополнительные опции включают:
- Настройку сервера optimize_cutoff для переопределения порога по умолчанию
- Настройку для конкретной таблицы optimize_cutoff
- SQL
OPTIMIZE TABLE rt OPTION cutoff=4;При использовании OPTION sync=1 (по умолчанию 0) команда будет ждать завершения процесса оптимизации перед возвратом. Если соединение прервется, оптимизация продолжит выполняться на сервере.
- SQL
OPTIMIZE TABLE rt OPTION sync=1;Оптимизация может быть длительным и ресурсоемким процессом ввода-вывода. Оператор OPTIMIZE добавляет задание в пул фоновых воркеров. Вы можете контролировать, сколько заданий выполняется параллельно, с помощью parallel_chunk_merges, и сколько чанков объединяет каждое задание, с помощью merge_chunks_per_job. Воркеры оптимизации могут быть ограничены по вводу-выводу, и вы можете контролировать максимальное количество операций ввода-вывода в секунду и максимальный размер операции ввода-вывода с помощью директив rt_merge_iops и rt_merge_maxiosize соответственно.
Во время оптимизации оптимизируемая RT-таблица остается онлайн и доступной как для поиска, так и для обновлений почти все время. Она блокируется на очень короткий период, когда пара дисковых чанков успешно объединяется, что позволяет переименовать старые и новые файлы и обновить заголовок таблицы.
Пока auto_optimize не отключен, таблицы оптимизируются автоматически.
Если вы сталкиваетесь с неожиданными SST или хотите, чтобы таблицы на всех узлах кластера были бинарно идентичными, вам необходимо:
- Отключить auto_optimize.
- Вручную оптимизировать таблицы:
На одном из узлов удалить таблицу из кластера:
- SQL
ALTER CLUSTER mycluster DROP myindex;Оптимизировать таблицу:
- SQL
OPTIMIZE TABLE myindex;Добавить таблицу обратно в кластер:
- SQL
ALTER CLUSTER mycluster ADD myindex;Когда таблица добавляется обратно, новые файлы, созданные в процессе оптимизации, будут реплицированы на другие узлы кластера. Любые локальные изменения, внесенные в таблицу на других узлах, будут потеряны.
Модификации данных таблицы (вставки, замены, удаления, обновления) должны либо:
- Быть отложены, либо
- Направляться на узел, где выполняется процесс оптимизации.
Обратите внимание, что пока таблица находится вне кластера, команды insert/replace/delete/update должны ссылаться на нее без префикса имени кластера (для SQL-запросов или свойства cluster в случае HTTP JSON запроса), иначе они завершатся ошибкой. После того как таблица будет добавлена обратно в кластер, вы должны возобновить операции записи в таблицу и снова включать префикс имени кластера, иначе они завершатся ошибкой.
Операции поиска доступны как обычно в процессе на любом из узлов.