Со временем RT-таблицы могут фрагментироваться на множество дисковых чанков и/или содержать удаленные, но не очищенные данные, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет пары дисковых чанков, удаляя документы, которые ранее были удалены с помощью операторов 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 просто добавляет задание в его очередь. Поток оптимизации может быть ограничен по вводу-выводу, и вы можете управлять максимальным количеством операций ввода-вывода в секунду и максимальным размером операции ввода-вывода с помощью директив rt_merge_iops и rt_merge_maxiosize соответственно.
Во время оптимизации оптимизируемая RT-таблица остается онлайн и доступной как для поиска, так и для обновлений почти все время. Она блокируется на очень короткий период, когда пара дисковых чанков успешно объединяется, что позволяет переименовать старые и новые файлы и обновить заголовок таблицы.
Пока auto_optimize не отключен, таблицы оптимизируются автоматически.
Если вы сталкиваетесь с неожиданными SST или хотите, чтобы таблицы на всех узлах кластера были бинарно идентичными, вам необходимо:
- Отключить auto_optimize.
- Вручную оптимизировать таблицы:
На одном из узлов удалить таблицу из кластера:
- SQL
SQL📋ALTER CLUSTER mycluster DROP myindex;Оптимизировать таблицу:
- SQL
SQL📋OPTIMIZE TABLE myindex;Добавить таблицу обратно в кластер:
- SQL
SQL📋ALTER CLUSTER mycluster ADD myindex;Когда таблица добавляется обратно, новые файлы, созданные процессом оптимизации, будут реплицированы на другие узлы кластера. Любые локальные изменения, внесенные в таблицу на других узлах, будут потеряны.
Модификации данных таблицы (вставки, замены, удаления, обновления) должны либо:
- Быть отложены, либо
- Направляться на узел, где выполняется процесс оптимизации.
Обратите внимание, что пока таблица находится вне кластера, команды insert/replace/delete/update должны ссылаться на нее без префикса имени кластера (для SQL-запросов или свойства cluster в случае HTTP JSON-запроса), иначе они завершатся ошибкой. После того как таблица будет добавлена обратно в кластер, вы должны возобновить операции записи в таблицу и снова включать префикс имени кластера, иначе они завершатся ошибкой.
Операции поиска доступны как обычно в процессе на любом из узлов.