Skip to main content
O motor Atomic oferece suporte a consultas DROP TABLE e RENAME TABLE sem bloqueio e a consultas atômicas EXCHANGE TABLES. O motor de banco de dados Atomic é usado por padrão no ClickHouse de código aberto.
No ClickHouse Cloud, o motor de banco de dados Shared é usado por padrão e também oferece suporte às operações mencionadas acima.

​
Criando um banco de dados

ENGINE = Atomic pode ser omitido, pois é o padrão. Uma cláusula SETTINGS pode conter tanto configurações do motor de banco de dados (como disk ou max_tables) quanto configurações comuns de consulta; cada nome é encaminhado para aquele dos dois ao qual pertence.

​
Detalhes e recomendações

​
UUID da tabela

Cada tabela no banco de dados Atomic tem um UUID persistente e armazena seus dados no seguinte diretório:
Em que xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy é o UUID da tabela. Por padrão, o UUID é gerado automaticamente. No entanto, os usuários podem especificá-lo ao criar uma tabela, embora isso não seja recomendado. Por exemplo:
Você pode usar a configuração show_table_uuid_in_table_create_query_if_not_nil para exibir o UUID na consulta SHOW CREATE.

​
RENAME TABLE

As consultas RENAME não modificam o UUID nem movem os dados da tabela. Essas consultas são executadas imediatamente e não esperam a conclusão de outras consultas que estejam usando a tabela.

​
DROP/DETACH TABLE

Ao usar DROP TABLE, nenhum dado é excluído. O motor Atomic apenas marca a tabela como removida, movendo seus metadados para /clickhouse_path/metadata_dropped/ e notificando a thread em segundo plano. O atraso antes da exclusão definitiva dos dados da tabela é especificado pela configuração database_atomic_delay_before_drop_table_sec. Você pode especificar o modo síncrono usando o modificador SYNC. Para isso, use a configuração database_atomic_wait_for_drop_and_detach_synchronously. Nesse caso, DROP espera que SELECT, INSERT e outras consultas em execução que estejam usando a tabela terminem. A tabela será removida quando não estiver mais em uso.

​
EXCHANGE TABLES/DICTIONARIES

A consulta EXCHANGE troca tabelas ou dicionários atomicamente. Por exemplo, em vez desta operação não atômica:
Non-atomic
você pode usar um banco de dados Atomic:
Atomic

​
ReplicatedMergeTree em banco de dados Atomic

Para tabelas ReplicatedMergeTree, recomenda-se não especificar os parâmetros do motor para o caminho no ZooKeeper nem o nome da réplica. Nesse caso, serão usados os parâmetros de configuração default_replica_path e default_replica_name. Se quiser especificar explicitamente os parâmetros do motor, recomenda-se usar as macros {uuid}. Isso garante que caminhos exclusivos sejam gerados automaticamente para cada tabela no ZooKeeper.

​
Disco de metadados

Quando disk é especificado em SETTINGS, o disco é usado para armazenar os arquivos de metadados da tabela. É possível indicar um disco definido na configuração do servidor ou defini-lo inline com a função disk, da mesma forma que se faz para uma única tabela:
Se não for especificado, o disco definido em database_disk.disk é usado por padrão. A mesma cláusula SETTINGS funciona para ATTACH DATABASE, que é a forma de anexar a um servidor um banco de dados cujos arquivos de metadados residem em outro disco. Nesse caso, o Atomic exige que o UUID do banco de dados seja informado explicitamente:

​
Limitando o número de tabelas

A configuração max_tables limita quantas tabelas o banco de dados pode conter. 0 (o padrão) significa ilimitado. Todo objeto do tipo tabela conta para o limite: uma tabela comum, uma view, uma visão materializada e um dicionário criado com CREATE DICTIONARY. Quando o limite é atingido, CREATE TABLE, CREATE DICTIONARY e ATTACH TABLE lançam a exceção TOO_MANY_TABLES.
O limite de um banco de dados existente pode ser alterado com ALTER DATABASE:
Reduzir o limite para um valor abaixo do número atual de tabelas não remove nenhuma tabela. Isso apenas impede que novas sejam criadas até que a contagem volte a ficar abaixo do limite. CREATE OR REPLACE TABLE cria brevemente a substituta com um nome temporário antes de colocá-la no lugar; por isso, substituir uma tabela quando o banco de dados está exatamente em max_tables falha com TOO_MANY_TABLES, mesmo que a contagem final de tabelas não aumente. Mover um objeto para o banco de dados com RENAME TABLE ou RENAME DICTIONARY também está sujeito ao limite. Uma visão materializada criada sem a cláusula TO possui uma tabela interna oculta que conta para o limite como se fosse uma tabela à parte. O limite é verificado antes do início de uma operação, portanto funciona em regime de melhor esforço: consultas concorrentes podem ultrapassá-lo ligeiramente. A configuração está disponível para os motores de banco de dados em disco que mantêm suas tabelas em memória e seus metadados em arquivos .sql locais: Atomic e Ordinary. Ela não é suportada pelo motor Replicated.

​
Veja também

Última modificação em 26 de setembro de 2026