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