메인 콘텐츠로 건너뛰기
ClickHouse에서 처리되는 데이터는 일반적으로 ClickHouse 서버가 실행 중인 머신의 로컬 파일 시스템에 저장됩니다. 이를 위해서는 대용량 디스크가 필요하며, 비용이 많이 들 수 있습니다. 데이터를 로컬에 저장하지 않도록 다음과 같은 스토리지 옵션을 지원합니다:
  1. Amazon S3 객체 스토리지.
  2. Azure Blob Storage.
  3. 지원되지 않음: Hadoop 분산 파일 시스템(HDFS)

ClickHouse는 외부 테이블 엔진도 지원합니다. 이는 이 페이지에서 설명하는 외부 스토리지 옵션과는 다르며, 일반적인 파일 포맷(예: Parquet)으로 저장된 데이터를 읽을 수 있게 해줍니다. 이 페이지에서는 ClickHouse MergeTree 계열 또는 Log 계열 테이블의 스토리지 구성을 설명합니다.
  1. Amazon S3 디스크에 저장된 데이터를 사용하려면 S3 테이블 엔진을 사용합니다.
  2. Azure Blob Storage에 저장된 데이터를 사용하려면 AzureBlobStorage 테이블 엔진을 사용합니다.
  3. Hadoop 분산 파일 시스템(지원되지 않음)에 저장된 데이터를 사용하려면 HDFS 테이블 엔진을 사용합니다.

외부 스토리지 구성

MergeTreeLog 계열 테이블 엔진은 각각 s3, azure_blob_storage, hdfs(지원되지 않음) 타입의 디스크를 사용해 데이터를 S3, AzureBlobStorage, HDFS(지원되지 않음)에 저장할 수 있습니다. 디스크를 구성하려면 다음이 필요합니다.
  1. type 섹션: 값은 s3, azure_blob_storage, hdfs(지원되지 않음), local_blob_storage, web 중 하나여야 합니다.
  2. 특정 외부 스토리지 타입에 대한 구성.
ClickHouse 24.1 버전부터는 새로운 구성 옵션을 사용할 수 있습니다. 이 경우 다음을 지정해야 합니다.
  1. object_storage로 설정한 type
  2. s3, azure_blob_storage(24.3부터는 azure도 가능), hdfs(지원되지 않음), local_blob_storage(24.3부터는 local도 가능), web 중 하나인 object_storage_type

선택적으로 metadata_type도 지정할 수 있으며(기본값은 local), plain, web, 그리고 24.4부터는 plain_rewritable로도 설정할 수 있습니다. plain 메타데이터 타입의 사용법은 plain storage section에 설명되어 있습니다. web 메타데이터 타입은 web 객체 스토리지 타입에서만 사용할 수 있습니다. local 메타데이터 타입은 메타데이터 파일을 로컬에 저장하며(각 메타데이터 파일에는 객체 스토리지의 파일에 대한 매핑과 해당 파일의 추가 메타 정보가 포함됨)입니다. 예시:
다음 구성과 동일합니다(24.1 버전부터):
다음과 같은 구성:
다음과 같습니다:
전체 스토리지 구성의 예시는 다음과 같습니다:
버전 24.1부터는 다음과 같은 형식이 될 수도 있습니다:
모든 MergeTree 테이블에 특정 유형의 스토리지를 기본 옵션으로 설정하려면, 설정 파일에 다음 섹션을 추가하십시오:
특정 테이블에 사용할 스토리지 정책을 지정하려면, 테이블 생성 시 설정에서 이를 정의할 수 있습니다:
storage_policy 대신 disk를 사용할 수도 있습니다. 이 경우 설정 파일에 storage_policy 섹션이 필요하지 않으며, disk 섹션만 있으면 충분합니다.

refresh_parts_interval 및 table_disk

이 설정은 파트가 외부에서 작성될 수 있고, 스토리지에서 메타데이터 탐지를 다시 갱신해야 하는 비복제 MergeTree 테이블을 위한 것입니다. MergeTree 설정 refresh_parts_interval은 기본 스토리지에서 데이터 파트 목록을 주기적으로 갱신할 수 있게 합니다(예: 외부에서 작성된 파트를 감지하기 위해). 여기서 중요한 차이는 레플리카 간 공유 메타데이터레플리카 로컬 메타데이터(예: 레플리카별 로컬 메타데이터를 사용하는 S3)입니다. 메타데이터가 공유되는 경우에만 새 파트가 모든 레플리카에 표시됩니다. 객체 스토리지를 사용한다고 해서 메타데이터까지 공유된다는 의미는 아닙니다.
  • 객체 스토리지(예: disk = 's3')는 공유 메타데이터를 의미하지 않습니다. 메타데이터가 기본값처럼 레플리카별로 로컬에 저장되면, 각 레플리카는 객체 스토리지의 blob을 가리키는 포인터를 독립적으로 관리합니다. 한 레플리카에서 발생한 변경 사항은 다른 레플리카에 보이지 않습니다. 이 경우 각 레플리카가 읽는 메타데이터가 레플리카 로컬이므로, refresh_parts_interval을 사용해도 새 파트가 레플리카 간에 표시되지 않습니다.
  • 자동 파트 갱신이 작동하려면 파일 시스템 메타데이터가 공유되어야 합니다(또는 갱신이 적용될 수 있도록 테이블이 테이블 소유의 읽기 전용 메타데이터를 사용해야 합니다). 테이블 로컬 디스크와 함께 table_disk = true를 설정하는 것(예: SETTINGS disk = disk(type=object_storage, ...), table_disk = true)은 올바른 동작 의미를 얻는 한 가지 방법입니다. 이 경우 테이블이 메타데이터 수명 주기를 관리하고 스토리지는 읽기 전용으로 취급되므로, refresh_parts_interval이 실행되어 외부에서 추가된 파트를 감지할 수 있습니다.
  • 전역적으로 정의된 디스크(예: storage_configuration에서 disk = 's3')와 기본 로컬 메타데이터를 사용하는 경우, 각 레플리카는 자체 메타데이터 상태를 가집니다. blob이 S3에 있더라도 refresh_parts_interval의 관점에서는 해당 스토리지가 공유된 것으로 간주되지 않으므로, ClickHouse 외부 또는 다른 레플리카에서 생성된 새 파트는 감지되지 않습니다.
자동 파트 갱신을 사용하려면 메타데이터가 공유되도록 구성하거나, 위와 같이 table_disk = true를 사용하는 테이블 수준 디스크를 사용하십시오. 레플리카 로컬 메타데이터에서 refresh_parts_interval에만 의존하면 예상대로 파트가 갱신되지 않습니다.
refresh_parts_interval은 ReplicatedMergeTree 테이블에는 사용되지 않습니다. 복제된 테이블은 이미 복제 메커니즘을 통해 파트를 동기화합니다. 이 설정은 파트가 외부에서 작성되고 메타데이터 갱신이 필요한 비복제 MergeTree 테이블에만 적용됩니다.

동적 구성

설정 파일의 구성에서 디스크를 미리 정의하지 않고도 스토리지 구성을 지정할 수 있으며, 대신 CREATE/ATTACH 쿼리 설정에서 구성할 수도 있습니다. 다음 예시 쿼리는 위의 동적 디스크 구성을 바탕으로, URL에 저장된 테이블의 데이터를 캐시하기 위해 로컬 디스크를 사용하는 방법을 보여줍니다.
아래 예시에서는 외부 스토리지에 캐시를 추가합니다.
아래에서 강조 표시된 설정을 보면 type=web 디스크가 type=cache 디스크 내부에 중첩되어 있음을 알 수 있습니다.
이 예시에서는 type=web을 사용하지만, 로컬 디스크를 포함해 어떤 디스크 유형이든 동적으로 구성할 수 있습니다. 로컬 디스크를 사용하려면 경로 인수가 server config 매개변수 custom_local_disks_base_directory 안에 있어야 합니다. 이 매개변수에는 기본값이 없으므로, 로컬 디스크를 사용할 때는 이 값도 함께 설정하십시오.
구성 파일 기반 구성과 SQL로 정의한 구성을 함께 사용하는 것도 가능합니다:
여기서 web은 서버 구성 설정 파일의 값입니다:

S3 스토리지 사용

필수 매개변수

선택적 매개변수

Google Cloud Storage(GCS)도 s3 유형을 사용해 지원됩니다. GCS backed MergeTree를 참조하십시오.

Plain Storage 사용

22.10에는 한 번만 쓸 수 있는 저장소를 제공하는 새로운 디스크 유형 s3_plain이 도입되었습니다. 이 디스크 유형의 구성 매개변수는 s3 디스크 유형과 동일합니다. s3 디스크 유형과 달리 데이터를 있는 그대로 저장합니다. 즉, 무작위로 생성된 blob 이름 대신 일반 파일 이름을 사용하며 (ClickHouse가 로컬 디스크에 파일을 저장하는 방식과 동일) 로컬에 메타데이터를 저장하지 않습니다. 예를 들어, s3의 데이터에서 파생됩니다. 이 디스크 유형은 기존 데이터에 대해 머지를 실행할 수 없고 새 데이터를 삽입할 수도 없으므로 테이블의 정적 버전을 유지할 수 있습니다. 이 디스크 유형의 활용 사례 중 하나는 여기에 backup을 생성하는 것이며, 이는 BACKUP TABLE data TO Disk('plain_disk_name', 'backup_name')를 통해 수행할 수 있습니다. 이후 RESTORE TABLE data AS data_restored FROM Disk('plain_disk_name', 'backup_name')를 실행하거나 ATTACH TABLE data (...) ENGINE = MergeTree() SETTINGS disk = 'plain_disk_name'를 사용할 수 있습니다. 구성:
24.1부터 plain 메타데이터 유형을 사용해 모든 객체 스토리지 디스크(s3, azure, hdfs (지원되지 않음), local)를 구성할 수 있습니다. 구성:

S3 Plain Rewritable Storage 사용

새 디스크 유형 s3_plain_rewritable24.4에서 도입되었습니다. s3_plain 디스크 유형과 마찬가지로, 메타데이터 파일을 위한 추가 저장소가 필요하지 않습니다. 대신 메타데이터는 S3에 저장됩니다. s3_plain 디스크 유형과 달리, s3_plain_rewritable는 머지를 실행할 수 있으며 INSERT 작업을 지원합니다. 뮤테이션과 테이블 복제는 지원되지 않습니다. 이 디스크 유형의 사용 사례 중 하나는 복제되지 않은 MergeTree 테이블입니다. s3 디스크 유형도 복제되지 않은 MergeTree 테이블에 적합하지만, 테이블의 로컬 메타데이터가 필요하지 않고 지원되는 작업이 제한적이라는 점을 수용할 수 있다면 s3_plain_rewritable 디스크 유형을 선택할 수 있습니다. 예를 들어 시스템 테이블에 유용할 수 있습니다. 구성:
와 같습니다
24.5부터는 plain_rewritable 메타데이터 타입을 사용해 모든 객체 스토리지 디스크(s3, azure, local)를 구성할 수 있습니다.

Azure Blob Storage 사용하기

MergeTree 계열 테이블 엔진은 azure_blob_storage 유형의 디스크를 사용해 Azure Blob Storage에 데이터를 저장할 수 있습니다. 구성 예시:

연결 매개변수

인증 매개변수(디스크는 사용 가능한 모든 메서드와 Managed Identity Credential을 시도합니다):

제한 매개변수

기타 매개변수

작동하는 구성 예시는 integration tests 디렉터리에서 확인할 수 있습니다(예: test_merge_tree_azure_blob_storage 또는 test_azure_blob_storage_zero_copy_replication).
Zero-copy 복제는 프로덕션용으로는 아직 준비되지 않았습니다ClickHouse 버전 22.8 이상에서는 zero-copy 복제가 기본적으로 비활성화되어 있습니다. 이 기능은 프로덕션 환경에서 사용하도록 권장되지 않습니다.

HDFS 스토리지 사용(지원되지 않음)

이 예시 구성은 다음과 같습니다:
  • 디스크 유형은 hdfs입니다(지원되지 않음)
  • 데이터는 hdfs://hdfs1:9000/clickhouse/에 저장됩니다
참고로 HDFS는 지원되지 않으므로 사용 시 문제가 발생할 수 있습니다. 문제가 발생하면 수정 사항을 반영한 Pull Request를 보내주십시오.
HDFS는 일부 예외적인 상황에서는 작동하지 않을 수 있다는 점을 유의하십시오.

데이터 암호화 사용

S3, HDFS(지원되지 않음) 같은 외부 디스크나 로컬 디스크에 저장된 데이터를 암호화할 수 있습니다. 암호화 모드를 사용하려면 설정 파일에서 유형이 encrypted인 디스크를 정의하고, 데이터가 저장될 디스크를 선택해야 합니다. encrypted 디스크는 쓰여지는 모든 파일을 실시간으로 암호화하며, encrypted 디스크에서 파일을 읽을 때는 자동으로 복호화합니다. 따라서 encrypted 디스크도 일반 디스크처럼 사용할 수 있습니다. 디스크 구성 예시:
예를 들어, ClickHouse가 일부 테이블의 데이터를 disk1의 파일 store/all_1_1_0/data.bin에 기록하면, 실제로 이 파일은 물리 디스크의 /path1/store/all_1_1_0/data.bin 경로에 기록됩니다. 동일한 파일을 disk2에 기록하면, 실제로는 물리 디스크의 /path1/path2/store/all_1_1_0/data.bin 경로에 암호화된 상태로 기록됩니다.

필수 매개변수

선택적 매개변수

디스크 구성 예시:

로컬 캐시 사용

버전 22.3부터 스토리지 구성의 디스크에 로컬 캐시를 설정할 수 있습니다. 버전 22.3~22.7에서는 s3 디스크 유형에서만 캐시를 지원합니다. 버전 >= 22.8에서는 S3, Azure, Local, Encrypted 등 모든 디스크 유형에서 캐시를 지원합니다. 버전 >= 23.5에서는 S3, Azure, HDFS(미지원)와 같은 원격 디스크 유형에서만 캐시를 지원합니다. 캐시는 LRU 캐시 정책을 사용합니다. 버전 22.8 이상에서의 구성 예시는 다음과 같습니다:
22.8 이전 버전용 구성 예시:
파일 캐시 디스크 구성 설정: 이 설정은 디스크 구성 섹션에 정의해야 합니다.
참고: 크기 값은 ki, Mi, Gi 등의 단위를 지원합니다(예: 10Gi).

파일 캐시 쿼리/프로필 설정

캐시 구성 설정과 캐시 쿼리 설정은 최신 ClickHouse 버전에 해당하므로, 이전 버전에서는 일부 기능이 지원되지 않을 수 있습니다.

캐시 시스템 테이블

캐시 명령어

SYSTEM CLEAR|DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER)ON CLUSTER
이 명령은 <cache_name>을 지정하지 않은 경우에만 지원됩니다
SHOW FILESYSTEM CACHES
server에 구성된 파일 시스템 캐시 목록을 표시합니다. (22.8 이하 버전에서는 이 명령의 이름이 SHOW CACHES입니다)
Query
Response
DESCRIBE FILESYSTEM CACHE '<cache_name>'
특정 파일 시스템 캐시의 구성과 일부 일반 통계를 표시합니다. 캐시 이름은 SHOW FILESYSTEM CACHES 명령으로 확인할 수 있습니다. (22.8 이하 버전에서는 이 명령의 이름이 DESCRIBE CACHE입니다)
Query
Response

정적 Web 스토리지 사용(읽기 전용)

이 디스크는 읽기 전용 디스크입니다. 데이터는 읽기만 가능하며 수정되지는 않습니다. 새 테이블은 ATTACH TABLE 쿼리로 이 디스크에 로드됩니다(아래 예시 참조). 로컬 디스크는 실제로 사용되지 않으며, 각 SELECT 쿼리는 필요한 데이터를 가져오기 위해 http 요청을 보냅니다. 테이블 데이터를 수정하려는 모든 작업은 예외를 발생시키므로, 다음과 같은 쿼리 유형은 허용되지 않습니다: CREATE TABLE, ALTER TABLE, RENAME TABLE, DETACH TABLETRUNCATE TABLE. Web 스토리지는 읽기 전용 용도로 사용할 수 있습니다. 예를 들어 샘플 데이터를 호스팅하거나 데이터를 마이그레이션할 때 사용할 수 있습니다. clickhouse-static-files-uploader라는 도구는 지정한 테이블의 데이터 디렉터리를 준비합니다(SELECT data_paths FROM system.tables WHERE name = 'table_name'). 필요한 각 테이블마다 파일 디렉터리가 생성됩니다. 이 파일들은 예를 들어 정적 파일을 제공하는 웹 서버에 업로드할 수 있습니다. 이 준비가 끝나면, DiskWeb를 통해 이 테이블을 어느 ClickHouse 서버에서나 로드할 수 있습니다. 이 예시 구성에서는:
  • 디스크 유형은 web입니다
  • 데이터는 http://nginx:80/test1/에서 호스팅됩니다
  • 로컬 스토리지의 캐시를 사용합니다
웹 데이터셋을 정기적으로 사용할 예정이 아니라면, 스토리지는 쿼리 내에서 일시적으로 구성할 수도 있습니다. 동적 구성을 참조하고 설정 파일 편집은 건너뛰십시오.GitHub에는 데모 데이터세트가 호스팅되어 있습니다. 직접 테이블을 웹 스토리지용으로 준비하려면 clickhouse-static-files-uploader 도구를 참조하십시오.
ATTACH TABLE 쿼리에서는 제공된 UUID가 데이터 디렉터리 이름과 일치하고, 엔드포인트는 GitHub 원본 콘텐츠의 URL입니다.
바로 사용할 수 있는 테스트 사례입니다. 이 구성을 config에 추가해야 합니다:
그런 다음 다음 쿼리를 실행하세요:

필수 매개변수

선택적 매개변수

쿼리가 DB:Exception Unreachable URL 예외와 함께 실패하면 다음 설정을 조정해 볼 수 있습니다: http_connection_timeout, http_receive_timeout, keep_alive_timeout. 업로드할 파일을 가져오려면 다음을 실행하십시오: clickhouse static-files-disk-uploader --metadata-path <path> --output-dir <dir> (--metadata-path는 쿼리 SELECT data_paths FROM system.tables WHERE name = 'table_name'로 확인할 수 있습니다). endpoint로 파일을 로드할 때는 반드시 <endpoint>/store/ 경로에 로드해야 하지만, 구성에는 endpoint만 포함되어야 합니다. 서버 시작 시 테이블을 로드하는 과정에서 디스크의 URL에 연결할 수 없으면 모든 오류가 포착됩니다. 이 경우 오류가 발생했다면 DETACH TABLE table_name -> ATTACH TABLE table_name을 통해 테이블을 다시 로드해 다시 표시되도록 할 수 있습니다. 서버 시작 시 메타데이터가 성공적으로 로드되었다면 테이블을 즉시 사용할 수 있습니다. 단일 HTTP 읽기 중 최대 재시도 횟수를 제한하려면 http_max_single_read_retries 설정을 사용하십시오.

zero-copy 복제(프로덕션 환경에서는 아직 사용할 수 없음)

S3HDFS(미지원) 디스크에서 zero-copy 복제를 사용할 수는 있지만, 권장되지는 않습니다. zero-copy 복제는 데이터가 여러 머신의 원격 스토리지에 저장되어 있고 이를 동기화해야 할 때, 데이터 자체는 복제하지 않고 메타데이터(데이터 파트의 경로)만 복제하는 방식입니다.
zero-copy 복제는 프로덕션 환경에서 아직 사용할 수 없습니다ClickHouse 버전 22.8 이상에서는 zero-copy 복제가 기본적으로 비활성화되어 있습니다. 이 기능은 프로덕션 환경에서 사용하는 것을 권장하지 않습니다.
마지막 수정일 2026년 7월 3일