Atomic

Движок Atomic поддерживает неблокирующие запросы DROP TABLE и RENAME TABLE, а также атомарные запросы EXCHANGE TABLES. Движок базы данных Atomic используется по умолчанию.

Движок Atomic поддерживает неблокирующие запросы DROP TABLE и RENAME TABLE, а также атомарные запросы EXCHANGE TABLES. В ClickHouse с открытым исходным кодом по умолчанию используется движок базы данных Atomic.

В ClickHouse Cloud по умолчанию используется движок базы данных Shared, который также поддерживает описанные выше операции.

​

Создание базы данных

CREATE DATABASE test [ENGINE = Atomic] [SETTINGS name = value, ...];

ENGINE = Atomic можно не указывать, так как это значение по умолчанию. Предложение SETTINGS может содержать как настройки движка баз данных (например, disk или max_tables), так и обычные настройки запроса; каждое имя направляется к той из двух групп, к которой оно относится.

​

Особенности и рекомендации

​

UUID таблицы

У каждой таблицы в базе данных Atomic есть постоянный UUID, а её данные хранятся в следующем каталоге:

/clickhouse_path/store/xxx/xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/

Где xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy — UUID таблицы.

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

Например:

CREATE TABLE name UUID '28f1c61c-2970-457a-bffe-454156ddcfef' (n UInt64) ENGINE = ...;

Вы можете использовать настройку show_table_uuid_in_table_create_query_if_not_nil, чтобы выводить UUID в запросе SHOW CREATE.

​

RENAME TABLE

Запросы RENAME не изменяют UUID и не перемещают данные таблицы. Они выполняются немедленно и не ждут завершения других запросов, использующих эту таблицу.

​

DROP/DETACH TABLE

При использовании DROP TABLE данные не удаляются. Движок Atomic лишь помечает таблицу как удалённую, перемещая её метаданные в /clickhouse_path/metadata_dropped/, и уведомляет фоновый поток. Задержка перед окончательным удалением данных таблицы задаётся настройкой database_atomic_delay_before_drop_table_sec. Вы можете включить синхронный режим с помощью модификатора SYNC. Для этого используйте настройку database_atomic_wait_for_drop_and_detach_synchronously. В этом случае DROP ожидает завершения выполняющихся SELECT, INSERT и других запросов, использующих таблицу. Таблица будет удалена, когда она перестанет использоваться.

​

EXCHANGE TABLES/DICTIONARIES

Запрос EXCHANGE атомарно меняет местами таблицы или словари. Например, вместо этой неатомарной операции:

Non-atomic

RENAME TABLE new_table TO tmp, old_table TO new_table, tmp TO old_table;

можно использовать базу данных Atomic:

Atomic

EXCHANGE TABLES new_table AND old_table;

​

ReplicatedMergeTree в базе данных Atomic

Для таблиц ReplicatedMergeTree рекомендуется не задавать параметры движка для пути в ZooKeeper и имени реплики. В этом случае будут использоваться параметры конфигурации default_replica_path и default_replica_name. Если вы хотите явно указать параметры движка, рекомендуется использовать макрос {uuid}. Это гарантирует автоматическое создание уникальных путей в ZooKeeper для каждой таблицы.

​

Диск для метаданных

Когда в SETTINGS указан disk, этот диск используется для хранения файлов метаданных таблицы. Можно указать диск из конфигурации сервера либо задать его непосредственно с помощью функции disk — так же, как это делается для отдельной таблицы:

CREATE DATABASE db SETTINGS disk = 'db_disk';
CREATE DATABASE db SETTINGS disk = disk(type = 'local', path = '/var/lib/clickhouse-disks/db_disk');

Если значение не указано, по умолчанию используется диск, заданный в database_disk.disk.

То же предложение SETTINGS работает и для ATTACH DATABASE — именно так к серверу подключается база данных, файлы метаданных которой расположены на другом диске. В этом случае для Atomic необходимо явно указать UUID базы данных:

ATTACH DATABASE db UUID '28f1c61c-2970-457a-bffe-454156ddcfef'
SETTINGS disk = disk(type = 'local', path = '/var/lib/clickhouse-disks/db_disk');

​

Ограничение количества таблиц

Настройка max_tables ограничивает количество таблиц, которые может содержать база данных. 0 (значение по умолчанию) означает, что количество таблиц не ограничено. В лимит учитывается каждый табличный объект: обычная таблица, представление, materialized view и словарь, созданный с помощью CREATE DICTIONARY. При достижении лимита команды CREATE TABLE, CREATE DICTIONARY и ATTACH TABLE генерируют исключение TOO_MANY_TABLES.

CREATE DATABASE db ENGINE = Atomic SETTINGS max_tables = 100;

Для существующей базы данных лимит можно изменить с помощью ALTER DATABASE:

ALTER DATABASE db MODIFY SETTING max_tables = 200;

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

CREATE OR REPLACE TABLE на короткое время создаёт заменяющую таблицу под временным именем, прежде чем подменить ею исходную. Поэтому замена таблицы, когда в базе данных уже ровно max_tables таблиц, завершается ошибкой TOO_MANY_TABLES, хотя итоговое количество таблиц не увеличится. Перемещение объекта в базу данных с помощью RENAME TABLE или RENAME DICTIONARY также подпадает под действие лимита.

Materialized view, созданное без предложения TO, имеет скрытую внутреннюю таблицу, которая учитывается в лимите как отдельная таблица.

Лимит проверяется до начала операции, поэтому его соблюдение не гарантируется: параллельные запросы могут немного превысить его.

Настройка доступна для дисковых движков баз данных, хранящих таблицы в памяти, а метаданные — в локальных .sql-файлах: Atomic и Ordinary. Движок Replicated её не поддерживает.

​

См. также

• системная таблица system.databases