Atomic 데이터베이스 엔진

Atomic 데이터베이스 엔진

비차단 DROP TABLE과 RENAME TABLE 쿼리, 원자적 EXCHANGE TABLES 쿼리를 지원하는 데이터베이스 엔진이에요. 오픈소스 ClickHouse에서 기본 데이터베이스 엔진으로 사용돼요. ClickHouse Cloud에서는 Shared 데이터베이스 엔진이 기본으로 사용되며 위에서 언급한 연산도 지원해요.

출처: 문서

본문

Atomic 엔진은 비차단 DROP TABLE과 RENAME TABLE 쿼리, 원자적 EXCHANGE TABLES 쿼리를 지원해요. Atomic 데이터베이스 엔진은 오픈소스 ClickHouse에서 기본으로 사용돼요. ClickHouse Cloud에서는 Shared 데이터베이스 엔진이 기본으로 사용되고 또한 위에서 언급한 연산을 지원해요.

데이터베이스 만들기 (Creating a database)

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

ENGINE = Atomic은 기본값이므로 생략할 수 있어요. SETTINGS 절은 데이터베이스 엔진의 설정(예: disk 또는 max_tables)과 일반 쿼리 설정을 모두 담을 수 있어요. 각 이름은 둘 중 어느 쪽에 속하는지에 따라 라우팅돼요.

세부 사항과 권장 사항 (Specifics and recommendations)

테이블 UUID (Table 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/DICTIONARIES

EXCHANGE 쿼리는 테이블이나 사전을 원자적으로 맞바꿔요. 예를 들어, 이 비원자적 연산 대신:

비원자적 (Non-atomic):

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

원자적 (Atomic):

EXCHANGE TABLES new_table AND old_table;

을 사용할 수 있어요.

Atomic 데이터베이스의 ReplicatedMergeTree

ReplicatedMergeTree 테이블의 경우 ZooKeeper의 경로와 복제본 이름에 대해 엔진 매개변수를 지정하지 않는 것을 권장해요. 이 경우 설정 매개변수 default_replica_path와 default_replica_name이 사용돼요. 엔진 매개변수를 명시적으로 지정하려면 {uuid} 매크로를 사용하는 것을 권장해요. 이렇게 하면 각 테이블에 대해 ZooKeeper에서 고유한 경로가 자동으로 생성됨을 보장해요.

메타데이터 디스크 (Metadata disk)

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에도 동작하며, 이는 메타데이터 파일이 다른 디스크에 있는 데이터베이스를 서버에 붙이는 방식이에요. 이 경우 Atomic은 데이터베이스의 UUID를 명시적으로 주어야 해요.

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

테이블 수 제한 (Limiting the number of tables)

max_tables 설정은 데이터베이스가 포함할 수 있는 테이블 수를 제한해요. 0(기본값)은 무제한을 뜻해요. 일반 테이블, 뷰, 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 엔진에서는 지원되지 않아요.

더 알아보기 (Learn more)