Atomic

El motor Atomic admite consultas DROP TABLE y RENAME TABLE sin bloqueo, y consultas EXCHANGE TABLES Atomic. El motor de base de datos Atomic se usa de forma predeterminada.

El motor Atomic admite consultas DROP TABLE y RENAME TABLE sin bloqueo, y consultas EXCHANGE TABLES Atomic. El motor de base de datos Atomic se usa de forma predeterminada en la versión de código abierto de ClickHouse.

En ClickHouse Cloud, el motor de base de datos Shared se usa de forma predeterminada y también admite las operaciones mencionadas anteriormente.

​

Crear una base de datos

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

ENGINE = Atomic puede omitirse, ya que es el valor predeterminado. Una cláusula SETTINGS puede contener tanto SETTINGS del motor de base de datos (como disk o max_tables) como SETTINGS de consulta ordinarios; cada nombre se dirige al que de los dos le corresponda.

​

Aspectos específicos y recomendaciones

​

UUID de la tabla

Cada tabla de la base de datos Atomic tiene un UUID persistente y almacena sus datos en el siguiente directorio:

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

Donde xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy es el UUID de la tabla.

De forma predeterminada, el UUID se genera automáticamente. Sin embargo, los usuarios pueden indicar explícitamente el UUID al crear una tabla, aunque no se recomienda.

Por ejemplo:

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

Puedes usar la SETTING show_table_uuid_in_table_create_query_if_not_nil para mostrar el UUID en la consulta SHOW CREATE.

​

RENAME TABLE

Las consultas RENAME no modifican el UUID ni mueven los datos de la tabla. Estas consultas se ejecutan de inmediato y no esperan a que terminen otras consultas que estén usando la tabla.

​

DROP/DETACH TABLE

Al usar DROP TABLE, no se elimina ningún dato. El motor Atomic simplemente marca la tabla como eliminada moviendo sus metadatos a /clickhouse_path/metadata_dropped/ y notifica al hilo en segundo plano. El retraso antes de la eliminación definitiva de los datos de la tabla se especifica mediante el ajuste database_atomic_delay_before_drop_table_sec. Puede especificar el modo síncrono usando el modificador SYNC. Use el ajuste database_atomic_wait_for_drop_and_detach_synchronously para ello. En este caso, DROP espera a que terminen las consultas SELECT, INSERT y otras consultas que estén usando la tabla. La tabla se eliminará cuando deje de estar en uso.

​

EXCHANGE TABLAS/DICCIONARIOS

La consulta EXCHANGE intercambia tablas o diccionarios de forma atómica. Por ejemplo, en lugar de esta operación no atómica:

Non-atomic

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

puede usar una base de datos Atomic:

Atomic

EXCHANGE TABLES new_table AND old_table;

​

ReplicatedMergeTree en una base de datos Atomic

Para las tablas ReplicatedMergeTree, se recomienda no especificar en los parámetros del motor ni la ruta en ZooKeeper ni el nombre de la réplica. En este caso, se utilizarán los parámetros de configuración default_replica_path y default_replica_name. Si desea especificar explícitamente los parámetros del motor, se recomienda usar las macros {uuid}. Esto garantiza que se generen automáticamente rutas únicas para cada tabla en ZooKeeper.

​

Disco de metadatos

Cuando se especifica disk en SETTINGS, el disco se utiliza para almacenar los archivos de metadatos de la tabla. Puede indicar un disco definido en la configuración del servidor o definir uno en línea con la función disk, igual que se hace con una tabla individual:

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

Si no se especifica, se utiliza de forma predeterminada el disco definido en database_disk.disk.

La misma cláusula SETTINGS funciona para ATTACH DATABASE, que es la forma de asociar a un servidor una base de datos cuyos archivos de metadatos se encuentran en otro disco. En ese caso, Atomic requiere que se indique explícitamente el UUID de la base de datos:

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

​

Limitar el número de tablas

La configuración max_tables limita cuántas tablas puede contener la base de datos. 0 (el valor predeterminado) significa que no hay límite. Todos los objetos de tipo tabla cuentan para el límite: una tabla ordinaria, una vista, una vista materializada y un diccionario creado con CREATE DICTIONARY. Cuando se alcanza el límite, CREATE TABLE, CREATE DICTIONARY y ATTACH TABLE lanzan una excepción TOO_MANY_TABLES.

CREATE DATABASE db ENGINE = Atomic SETTINGS max_tables = 100;

El límite se puede modificar en una base de datos existente con ALTER DATABASE:

ALTER DATABASE db MODIFY SETTING max_tables = 200;

Reducir el límite por debajo del número actual de tablas no elimina ninguna tabla. Únicamente impide que se creen nuevas hasta que el recuento vuelva a situarse por debajo del límite.

CREATE OR REPLACE TABLE crea brevemente el reemplazo con un nombre temporal antes de intercambiarlo, por lo que reemplazar una tabla cuando la base de datos está exactamente en max_tables falla con TOO_MANY_TABLES, aunque el recuento final de tablas no aumentaría. Mover un objeto a la base de datos con RENAME TABLE o RENAME DICTIONARY también está sujeto al límite.

Una vista materializada creada sin cláusula TO tiene una tabla interna oculta que cuenta para el límite como una tabla más.

El límite se comprueba antes de que comience la operación, por lo que solo ofrece garantías aproximadas: las consultas concurrentes pueden hacer que la base de datos lo supere ligeramente.

La configuración está disponible para los motores de bases de datos en disco que mantienen sus tablas en memoria y sus metadatos en archivos .sql locales: Atomic y Ordinary. El motor Replicated no es compatible con ella.

​

Véase también

• system.databases tabla del sistema