Atomic

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.

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

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

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:

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

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:

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

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

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

você pode usar um banco de dados Atomic:

Atomic

EXCHANGE TABLES new_table AND old_table;

​

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:

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

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:

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

​

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.

CREATE DATABASE db ENGINE = Atomic SETTINGS max_tables = 100;

O limite de um banco de dados existente pode ser alterado com ALTER DATABASE:

ALTER DATABASE db MODIFY SETTING max_tables = 200;

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

• system.databases tabela do sistema