> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Le moteur `Atomic` prend en charge les requêtes [`DROP TABLE`](#drop-detach-table) et [`RENAME TABLE`](#rename-table) sans blocage, ainsi que les requêtes atomiques [`EXCHANGE TABLES`](#exchange-tables). Le moteur de base de données `Atomic` est utilisé par défaut.
# Atomic
Le moteur `Atomic` prend en charge les requêtes [`DROP TABLE`](#drop-detach-table) et [`RENAME TABLE`](#rename-table) sans blocage, ainsi que les requêtes atomiques [`EXCHANGE TABLES`](#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`](/fr/products/cloud/features/infrastructure/shared-catalog#shared-database-engine) est utilisé par défaut et prend également en charge
les opérations mentionnées ci-dessus.
## Créer une base de données
```sql theme={null}
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`](#metadata-disk) ou [`max_tables`](#limiting-the-number-of-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](/fr/reference/data-types/uuid) permanent et stocke ses données dans le répertoire suivant :
```text theme={null}
/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 :
```sql theme={null}
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](/fr/reference/settings/session-settings/show#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`](/fr/reference/statements/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`](/fr/reference/settings/server-settings/settings/other#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`](/fr/reference/settings/session-settings/database#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`](/fr/reference/statements/exchange) permute des tables ou des dictionnaires de manière atomique. Par exemple, au lieu de cette opération non atomique :
```sql title="Non-atomic" theme={null}
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 :
```sql title="Atomic" theme={null}
EXCHANGE TABLES new_table AND old_table;
```
### ReplicatedMergeTree dans la base de données atomic
Pour les tables [`ReplicatedMergeTree`](/fr/reference/engines/table-engines/mergetree-family/replication), 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`](/fr/reference/settings/server-settings/settings/default-replica#default_replica_path) et [`default_replica_name`](/fr/reference/settings/server-settings/settings/default-replica#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 :
```sql theme={null}
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 :
```sql theme={null}
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`.
```sql theme={null}
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` :
```sql theme={null}
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](/fr/reference/system-tables/databases) table système