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
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 datosAtomic tiene un UUID persistente y almacena sus datos en el siguiente directorio:
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:
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 consultasRENAME 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 usarDROP 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 consultaEXCHANGE intercambia tablas o diccionarios de forma atómica. Por ejemplo, en lugar de esta operación no atómica:
Non-atomic
Atomic
ReplicatedMergeTree en una base de datos Atomic
Para las tablasReplicatedMergeTree, 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 especificadisk 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:
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:
Limitar el número de tablas
La configuraciónmax_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.
ALTER DATABASE:
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