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 name = value, ...];

ENGINE = Atomic peut être omis, car il s’agit de la valeur par défaut. Une clause SETTINGS peut contenir à la fois des paramètres du moteur de base de données (tels que disk ou max_tables) et des paramètres de requête ordinaires ; chaque nom est dirigé vers celui des deux auquel il appartient.

​

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 sert à stocker les fichiers de métadonnées de la table. Il peut s’agir d’un disque déclaré dans la configuration du serveur, ou d’un disque défini directement avec la fonction disk, comme pour une table unique :

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

Si aucune valeur n’est spécifiée, le disque défini dans database_disk.disk est utilisé par défaut.

La même clause SETTINGS fonctionne pour ATTACH DATABASE, ce qui permet d’attacher à un serveur une base de données dont les fichiers de métadonnées résident sur un autre disque. Dans ce cas, Atomic exige que l’UUID de la base de données soit fourni explicitement :

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

​

Limiter le nombre de tables

Le paramètre max_tables limite le nombre de tables que la base de données peut contenir. 0 (la valeur par défaut) signifie illimité. Tout objet assimilable à une table est comptabilisé dans cette limite : une table ordinaire, une vue, une vue matérialisée et un dictionnaire créé avec CREATE DICTIONARY. Lorsque la limite est atteinte, CREATE TABLE, CREATE DICTIONARY et ATTACH TABLE lèvent une exception TOO_MANY_TABLES.

CREATE DATABASE db ENGINE = Atomic SETTINGS max_tables = 100;

La limite peut être modifiée pour une base de données existante avec ALTER DATABASE :

ALTER DATABASE db MODIFY SETTING max_tables = 200;

Abaisser la limite en dessous du nombre actuel de tables ne supprime aucune table. Cela empêche seulement d’en créer de nouvelles tant que le nombre n’est pas repassé sous la limite.

CREATE OR REPLACE TABLE crée brièvement la table de remplacement sous un nom temporaire avant de procéder à l’échange : remplacer une table alors que la base de données est exactement à max_tables échoue donc avec TOO_MANY_TABLES, même si le nombre final de tables n’augmenterait pas. Le déplacement d’un objet vers la base de données avec RENAME TABLE ou RENAME DICTIONARY est également soumis à la limite.

Une vue matérialisée créée sans clause TO possède une table interne masquée qui compte dans la limite comme une table à part entière.

La limite est vérifiée avant le démarrage d’une opération : le contrôle est donc approximatif, car des requêtes concurrentes peuvent faire dépasser légèrement la limite à la base de données.

Le paramètre est disponible pour les moteurs de base de données sur disque qui conservent leurs tables en mémoire et leurs métadonnées dans des fichiers .sql locaux : Atomic et Ordinary. Il n’est pas pris en charge par le moteur Replicated.

​

Voir aussi

• system.databases table système