Со временем RT-таблицы могут фрагментироваться на множество дисковых чанков и/или содержать удаленные, но не очищенные данные, что влияет на производительность поиска. В таких случаях необходима оптимизация. По сути, процесс оптимизации объединяет пары дисковых чанков, удаляя документы, которые ранее были удалены с помощью операторов DELETE.

Начиная с Manticore 4, этот процесс происходит автоматически по умолчанию. Однако вы также можете использовать следующие команды для ручного запуска компактизации таблицы.

OPTIMIZE TABLE table_name [OPTION opt_name = opt_value [,...]]

OPTIMIZE TABLE rt;

OPTIMIZE TABLE rt OPTION cutoff=4;

OPTIMIZE TABLE rt OPTION sync=1;

Оптимизация может быть длительным и ресурсоемким процессом ввода-вывода. Чтобы минимизировать влияние, вся фактическая работа по слиянию выполняется последовательно в специальном фоновом потоке, а оператор OPTIMIZE просто добавляет задание в его очередь. Поток оптимизации может быть ограничен по вводу-выводу, и вы можете управлять максимальным количеством операций ввода-вывода в секунду и максимальным размером операции ввода-вывода с помощью директив rt_merge_iops и rt_merge_maxiosize соответственно.

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

Пока auto_optimize не отключен, таблицы оптимизируются автоматически.

Если вы сталкиваетесь с неожиданными SST или хотите, чтобы таблицы на всех узлах кластера были бинарно идентичными, вам необходимо:

1. Отключить auto_optimize.
2. Вручную оптимизировать таблицы:

   На одном из узлов удалить таблицу из кластера:

   ‹›

   • SQL

   SQL

   📋

   ⚙

   ALTER CLUSTER mycluster DROP myindex;

   Оптимизировать таблицу:

   ‹›

   • SQL

   SQL

   📋

   ⚙

   OPTIMIZE TABLE myindex;

   Добавить таблицу обратно в кластер:

   ‹›

   • SQL

   SQL

   📋

   ⚙

   ALTER CLUSTER mycluster ADD myindex;

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

Модификации данных таблицы (вставки, замены, удаления, обновления) должны либо:

1. Быть отложены, либо
2. Направляться на узел, где выполняется процесс оптимизации.

Обратите внимание, что пока таблица находится вне кластера, команды insert/replace/delete/update должны ссылаться на нее без префикса имени кластера (для SQL-запросов или свойства cluster в случае HTTP JSON-запроса), иначе они завершатся ошибкой. После того как таблица будет добавлена обратно в кластер, вы должны возобновить операции записи в таблицу и снова включать префикс имени кластера, иначе они завершатся ошибкой.

Операции поиска доступны как обычно в процессе на любом из узлов.

Manticore обеспечивает изоляцию во время процессов слива и слияния таблицы в реальном времени, чтобы предотвратить влияние изменений на выполняющиеся запросы.

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

То же самое касается слива RAM-чанка, где подходящие сегменты RAM объединяются в новый дисковый чанк, а участвующие сегменты RAM-чанка игнорируются. Во время этой операции Manticore обеспечивает изоляцию для запросов, которые начались до начала операции.

Кроме того, эти операции прозрачны для replace и update. Если вы обновляете атрибут в документе, который принадлежит дисковому чанку, объединяемому с другим, обновление будет применено как к этому чанку, так и к результирующему объединённому чанку. Если вы удаляете документ во время слияния, он будет удалён в исходном чанке и также в результирующем объединённом чанке, где документ либо будет помечен как удалённый, либо вообще отсутствовать, если удаление произошло на ранней стадии процесса слияния.

"Заморозка" таблицы полезна, когда вы хотите сделать физическую копию или резервную копию. Она помечает файлы таблицы как замороженные и показывает, где они хранятся. После заморозки вы можете безопасно скопировать эти файлы в другое место. Вы по-прежнему можете добавлять новые документы в замороженную таблицу, пока она не достигнет rt_mem_limit, но эти новые данные остаются в памяти и не записываются на диск, пока таблица не будет разморожена. Если таблица превысит rt_mem_limit, все изменения приостанавливаются до её разморозки. Если демон неожиданно остановится, любые несохранённые данные будут восстановлены из бинарного лога.

"Блокировка" таблицы полезна для логических резервных копий. Она не останавливает внутренние задачи обслуживания, такие как операции слияния дисковых чанков или запись RAM-чанка на диск. Она блокирует только операции записи. Это означает, что вы не можете вставлять, заменять или обновлять данные в заблокированной таблице. Это полезно для таких инструментов, как mysqldump, потому что блокировка гарантирует логическую согласованность данных. Например, без блокировки, если вы замените документ во время дампа, старая версия может уже быть в дампе, а новая версия также может появиться позже, обе с одним и тем же идентификатором документа. Блокировка таблицы предотвращает такую ситуацию.

FREEZE tbl1[, tbl2, ...]

FREEZE t;

+-------------------+---------------------------------+
| file              | normalized                      |
+-------------------+---------------------------------+
| data/t/t.0.spa    | /work/anytest/data/t/t.0.spa    |
| data/t/t.0.spd    | /work/anytest/data/t/t.0.spd    |
| data/t/t.0.spds   | /work/anytest/data/t/t.0.spds   |
| data/t/t.0.spe    | /work/anytest/data/t/t.0.spe    |
| data/t/t.0.sph    | /work/anytest/data/t/t.0.sph    |
| data/t/t.0.sphi   | /work/anytest/data/t/t.0.sphi   |
| data/t/t.0.spi    | /work/anytest/data/t/t.0.spi    |
| data/t/t.0.spm    | /work/anytest/data/t/t.0.spm    |
| data/t/t.0.spp    | /work/anytest/data/t/t.0.spp    |
| data/t/t.0.spt    | /work/anytest/data/t/t.0.spt    |
| data/t/t.meta     | /work/anytest/data/t/t.meta     |
| data/t/t.ram      | /work/anytest/data/t/t.ram      |
| data/t/t.settings | /work/anytest/data/t/t.settings |
+-------------------+---------------------------------+
13 rows in set (0.01 sec)

Столбец file указывает пути к файлам таблицы внутри data_dir запущенного экземпляра. Столбец normalized отображает абсолютные пути для тех же файлов. Чтобы создать резервную копию таблицы, просто скопируйте предоставленные файлы без дополнительной подготовки.

Когда таблица заморожена, вы не можете выполнять запросы UPDATE; они будут ждать, пока таблица не будет разморожена.

Также запросы DELETE и REPLACE имеют некоторые ограничения, пока таблица заморожена:

• Если DELETE затрагивает документ в текущем RAM-чанке — это разрешено.
• Если DELETE затрагивает документ в дисковом чанке, но он был ранее удалён — это разрешено.
• Если DELETE изменит фактический дисковый чанк — он будет ждать, пока таблица не будет разморожена.

Ручной FLUSH RAM-чанка замороженной таблицы сообщит об "успехе", но реального сохранения не произойдёт.

DROP/TRUNCATE замороженной таблицы разрешены, поскольку эти операции не являются неявными. Мы предполагаем, что если вы усекаете или удаляете таблицу, вам не нужна её резервная копия; следовательно, её не следовало изначально замораживать.

INSERT в замороженную таблицу поддерживается, но с ограничением: новые данные будут храниться в оперативной памяти (как обычно) до достижения rt_mem_limit; затем новые вставки будут ждать, пока таблица не будет разморожена.

Если вы завершите работу демона с замороженной таблицей, он поведёт себя так, как будто произошло грязное завершение работы (например, kill -9): вновь вставленные данные не будут сохранены в RAM-чанке на диске, и при перезапуске они будут восстановлены из бинарного лога (если он есть) или потеряны (если ведение бинарного лога отключено).

UNFREEZE tbl1[, tbl2, ...]

UNFREEZE tbl;

SHOW TABLE `foo` STATUS LIKE 'locked';

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| locked        | 2     |
+---------------+-------+
1 row in set (0,00 sec)

lock tables tbl1 read[, tbl2 read, ...]

--------------
LOCK TABLES tbl READ
--------------
Query OK, 0 rows affected (0.000 sec)
--------------
LOCK TABLES tbl READ, tbl2 WRITE
--------------
Query OK, 0 rows affected, 1 warning (0.000 sec)
--------------
SHOW WARNINGS
--------------
+---------+------+--------------------------------+
| Level   | Code | Message                        |
+---------+------+--------------------------------+
| warning | 1000 | Write lock is not implemented. |
+---------+------+--------------------------------+
1 row in set (0.000 sec)

UNLOCK TABLES;

SHOW LOCKS;

+-----------+------+-----------+-----------------+
| Type      | Name | Lock Type | Additional Info |
+-----------+------+-----------+-----------------+
| rt        | a    | read      | Count: 1        |
| percolate | bar  | freeze    | Count: 3        |
| rt        | foo  | freeze    | Count: 2        |
+-----------+------+-----------+-----------------+
3 rows in set (0,01 sec)