Atomic

Atomic 엔진은 비차단 DROP TABLE 및 RENAME TABLE 쿼리와 원자적 EXCHANGE TABLES 쿼리를 지원합니다. Atomic 데이터베이스 엔진이 기본으로 사용됩니다.

Atomic 엔진은 비차단 DROP TABLE 및 RENAME TABLE 쿼리와 원자적 EXCHANGE TABLES 쿼리를 지원합니다. 오픈소스 ClickHouse에서는 Atomic 데이터베이스 엔진이 기본으로 사용됩니다.

ClickHouse Cloud에서는 기본적으로 Shared 데이터베이스 엔진을 사용하며, 이 엔진도 위에서 언급한 작업을 지원합니다.

​

데이터베이스 생성

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

ENGINE = Atomic은 기본값이므로 생략할 수 있습니다. SETTINGS 절에는 데이터베이스 엔진의 설정(disk, max_tables 등)과 일반 쿼리 설정을 함께 지정할 수 있으며, 각 이름은 둘 중 해당하는 쪽으로 전달됩니다.

​

세부 정보 및 권장 사항

​

테이블 UUID

Atomic 데이터베이스의 각 테이블에는 영구적인 UUID가 있으며, 해당 데이터는 다음 디렉터리에 저장됩니다:

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

여기서 xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy는 테이블의 UUID를 의미합니다.

기본적으로 UUID는 자동으로 생성됩니다. 하지만 테이블을 생성할 때 UUID를 직접 지정할 수도 있으나, 이는 권장되지 않습니다.

예시:

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

show_table_uuid_in_table_create_query_if_not_nil 설정을 사용하면 SHOW CREATE 쿼리에서 UUID를 표시할 수 있습니다.

​

RENAME TABLE

RENAME 쿼리는 UUID를 변경하거나 테이블 데이터를 이동하지 않습니다. 이 쿼리는 즉시 실행되며, 해당 테이블을 사용 중인 다른 쿼리가 끝날 때까지 기다리지 않습니다.

​

DROP/DETACH TABLE

DROP TABLE를 사용해도 데이터는 삭제되지 않습니다. Atomic 엔진은 메타데이터를 /clickhouse_path/metadata_dropped/로 이동하여 테이블을 삭제된 것으로 표시하고 백그라운드 스레드에 알립니다. 최종적으로 테이블 데이터가 삭제되기 전까지의 지연 시간은 database_atomic_delay_before_drop_table_sec 설정으로 지정됩니다. SYNC 수정자를 사용하여 동기 모드를 지정할 수 있습니다. 이를 위해 database_atomic_wait_for_drop_and_detach_synchronously 설정을 사용하십시오. 이 경우 DROP은 테이블을 사용 중인 실행 중의 SELECT, INSERT 및 기타 쿼리가 완료될 때까지 기다립니다. 테이블은 더 이상 사용되지 않을 때 제거됩니다.

​

EXCHANGE TABLES/사전

EXCHANGE 쿼리는 테이블이나 사전의 이름을 원자적으로 서로 바꿉니다. 예를 들어, 다음과 같은 원자적이지 않은 작업 대신:

Non-atomic

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

Atomic 데이터베이스를 사용할 수 있습니다:

Atomic

EXCHANGE TABLES new_table AND old_table;

​

Atomic 데이터베이스의 ReplicatedMergeTree

ReplicatedMergeTree 테이블에서는 ZooKeeper의 경로와 레플리카 이름에 대한 엔진 매개변수를 지정하지 않는 것을 권장합니다. 이 경우 구성 매개변수 default_replica_path와 default_replica_name이 사용됩니다. 엔진 매개변수를 명시적으로 지정하려면 {uuid} 매크로를 사용하는 것을 권장합니다. 이렇게 하면 ZooKeeper에서 각 테이블마다 고유한 경로가 자동으로 생성됩니다.

​

메타데이터 디스크

SETTINGS에 disk를 지정하면 해당 디스크가 테이블 메타데이터 파일을 저장하는 데 사용됩니다. 단일 테이블과 마찬가지로, 서버 구성에 정의된 디스크 이름을 지정하거나 disk 함수로 인라인 정의할 수 있습니다:

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

지정하지 않으면 기본적으로 database_disk.disk에 정의된 디스크가 사용됩니다.

동일한 SETTINGS 절은 ATTACH DATABASE에서도 사용할 수 있으며, 메타데이터 파일이 다른 디스크에 있는 데이터베이스를 서버에 attach할 때 이 방식을 사용합니다. 이 경우 Atomic은 데이터베이스의 UUID를 명시적으로 지정해야 합니다:

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

​

테이블 수 제한

max_tables 설정은 데이터베이스가 포함할 수 있는 테이블 수를 제한합니다. 0(기본값)은 무제한을 의미합니다. 일반 테이블, VIEW, materialized view, CREATE DICTIONARY로 생성한 딕셔너리 등 테이블 형태의 모든 객체가 이 제한에 포함됩니다. 제한에 도달하면 CREATE TABLE, CREATE DICTIONARY, ATTACH TABLE은 TOO_MANY_TABLES 예외를 발생시킵니다.

CREATE DATABASE db ENGINE = Atomic SETTINGS max_tables = 100;

기존 데이터베이스의 제한은 ALTER DATABASE로 변경할 수 있습니다:

ALTER DATABASE db MODIFY SETTING max_tables = 200;

현재 테이블 수보다 낮은 값으로 제한을 낮추더라도 기존 테이블이 삭제되지는 않습니다. 테이블 수가 다시 제한 아래로 내려갈 때까지 새 테이블 생성만 차단될 뿐입니다.

CREATE OR REPLACE TABLE은 대체 테이블을 임시 이름으로 잠시 생성한 뒤 스왑하므로, 데이터베이스가 정확히 max_tables에 도달한 상태에서 테이블을 교체하면 최종 테이블 수가 늘어나지 않더라도 TOO_MANY_TABLES 오류로 실패합니다. RENAME TABLE이나 RENAME DICTIONARY로 객체를 해당 데이터베이스로 이동하는 작업에도 이 제한이 적용됩니다.

TO 절 없이 생성된 materialized view는 숨겨진 내부 테이블을 가지며, 이 내부 테이블도 별도의 테이블로 제한에 포함됩니다.

제한은 작업이 시작되기 전에 확인되므로 최선 노력(best-effort) 방식입니다. 즉, 동시에 실행되는 쿼리로 인해 데이터베이스가 제한을 약간 초과할 수 있습니다.

이 설정은 테이블을 메모리에 유지하고 메타데이터를 로컬 .sql 파일에 저장하는 온디스크 데이터베이스 엔진인 Atomic과 Ordinary에서 사용할 수 있습니다. Replicated 엔진에서는 지원되지 않습니다.

​

관련 항목

• system.databases 시스템 테이블