Со временем RT-таблицы могут фрагментироваться на множество дисковых чанков и/или загрязняться удалёнными, но ещё не очищенными данными, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет пары дисковых чанков, удаляя документы, которые были ранее удалены с помощью операторов DELETE.
Начиная с Manticore 4, этот процесс происходит автоматически по умолчанию. Однако вы также можете использовать следующие команды для ручного запуска компактирования таблицы.
OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]]Оператор OPTIMIZE добавляет RT-таблицу в очередь оптимизации, которая будет обработана в фоновом потоке.
- SQL
OPTIMIZE TABLE rt;По умолчанию OPTIMIZE объединяет дисковые чанки RT-таблицы до количества, меньшего или равного числу логических ядер процессора, умноженному на 2.
Однако, если в таблице есть атрибуты с KNN-индексами, этот порог отличается. В этом случае он устанавливается как количество физических ядер процессора, делённое на 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-запроса), иначе они завершатся с ошибкой. После того как таблица будет добавлена обратно в кластер, необходимо возобновить операции записи в таблицу и снова использовать префикс имени кластера, иначе они будут завершаться с ошибкой.
Операции поиска доступны как обычно на любом из узлов в процессе.