Atomic

Le moteur Atomic prend en charge les requêtes DROP TABLE et RENAME TABLE sans blocage, ainsi que les requêtes atomiques EXCHANGE TABLES. Le moteur de base de données Atomic est utilisé par défaut.

Le moteur Atomic prend en charge les requêtes DROP TABLE et RENAME TABLE sans blocage, ainsi que les requêtes atomiques EXCHANGE TABLES. Le moteur de base de données Atomic est utilisé par défaut dans la version open source de ClickHouse.

Dans ClickHouse Cloud, le moteur de base de données Shared est utilisé par défaut et prend également en charge les opérations mentionnées ci-dessus.

​

Créer une base de données

CREATE DATABASE test [ENGINE = Atomic] [SETTINGS disk=...];

​

Spécificités et recommandations

​

UUID de la table

Chaque table de la base de données Atomic possède un UUID permanent et stocke ses données dans le répertoire suivant :

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

où xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy est l’UUID de la table.

Par défaut, l’UUID est généré automatiquement. Les utilisateurs peuvent toutefois le définir explicitement lors de la création d’une table, bien que cela ne soit pas recommandé.

Par exemple :

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

Vous pouvez utiliser le paramètre show_table_uuid_in_table_create_query_if_not_nil pour afficher l’UUID dans le résultat de la requête SHOW CREATE.

​

RENAME TABLE

Les requêtes RENAME ne modifient pas l’UUID et ne déplacent pas les données de la table. Elles s’exécutent immédiatement et n’attendent pas la fin des autres requêtes utilisant la table.

​

DROP/DETACH TABLE

Lors de l’utilisation de DROP TABLE, aucune donnée n’est supprimée. Le moteur Atomic se contente de marquer la table comme supprimée en déplaçant ses métadonnées vers /clickhouse_path/metadata_dropped/ et en notifiant le thread d’arrière-plan. Le délai avant la suppression définitive des données de la table est défini par le paramètre database_atomic_delay_before_drop_table_sec. Vous pouvez activer le mode synchrone à l’aide du modificateur SYNC. Pour cela, utilisez le paramètre database_atomic_wait_for_drop_and_detach_synchronously. Dans ce cas, DROP attend la fin des requêtes SELECT, INSERT et autres requêtes en cours qui utilisent la table. La table sera supprimée lorsqu’elle ne sera plus utilisée.

​

EXCHANGE TABLES/DICTIONARIES

La requête EXCHANGE permute des tables ou des dictionnaires de manière atomique. Par exemple, au lieu de cette opération non atomique :

Non-atomic

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

vous pouvez utiliser une base de données de type Atomic :

Atomic

EXCHANGE TABLES new_table AND old_table;

​

ReplicatedMergeTree dans la base de données atomic

Pour les tables ReplicatedMergeTree, il est recommandé de ne pas spécifier les paramètres du moteur pour le chemin dans ZooKeeper ni le nom de la réplique. Dans ce cas, les paramètres de configuration default_replica_path et default_replica_name seront utilisés. Si vous souhaitez spécifier explicitement les paramètres du moteur, il est recommandé d’utiliser les macros {uuid}. Cela garantit que des chemins uniques sont automatiquement générés pour chaque table dans ZooKeeper.

​

Disque de métadonnées

Lorsque disk est spécifié dans SETTINGS, le disque est utilisé pour stocker les fichiers de métadonnées de la table. Par exemple :

CREATE TABLE db (n UInt64) ENGINE = Atomic SETTINGS disk=disk(type='local', path='/var/lib/clickhouse-disks/db_disk');

Si rien n’est précisé, le disque défini dans database_disk.disk est utilisé par défaut.

​

Voir aussi

• system.databases table système