- Amazon S3 객체 스토리지.
- Azure Blob Storage.
- 지원되지 않음: Hadoop 분산 파일 시스템(HDFS)
ClickHouse는 외부 테이블 엔진도 지원합니다. 이는 이 페이지에서 설명하는
외부 스토리지 옵션과는 다르며, 일반적인 파일 포맷(예: Parquet)으로 저장된 데이터를
읽을 수 있게 해줍니다. 이 페이지에서는 ClickHouse
MergeTree 계열 또는 Log 계열 테이블의
스토리지 구성을 설명합니다.Amazon S3디스크에 저장된 데이터를 사용하려면 S3 테이블 엔진을 사용합니다.- Azure Blob Storage에 저장된 데이터를 사용하려면 AzureBlobStorage 테이블 엔진을 사용합니다.
- Hadoop 분산 파일 시스템(지원되지 않음)에 저장된 데이터를 사용하려면 HDFS 테이블 엔진을 사용합니다.
외부 스토리지 구성
MergeTree 및 Log
계열 테이블 엔진은 각각 s3, azure_blob_storage, hdfs(지원되지 않음) 타입의 디스크를 사용해 데이터를 S3, AzureBlobStorage, HDFS(지원되지 않음)에 저장할 수 있습니다.
디스크를 구성하려면 다음이 필요합니다.
type섹션: 값은s3,azure_blob_storage,hdfs(지원되지 않음),local_blob_storage,web중 하나여야 합니다.- 특정 외부 스토리지 타입에 대한 구성.
object_storage로 설정한types3,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 버전부터):
MergeTree 테이블에 특정 유형의 스토리지를 기본 옵션으로 설정하려면,
설정 파일에 다음 섹션을 추가하십시오:
storage_policy 대신 disk를 사용할 수도 있습니다. 이 경우 설정 파일에 storage_policy 섹션이
필요하지 않으며, disk 섹션만 있으면 충분합니다.
refresh_parts_interval 및 table_disk
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 안에 있어야 합니다. 이 매개변수에는 기본값이
없으므로, 로컬 디스크를 사용할 때는 이 값도 함께 설정하십시오.web은 서버 구성 설정 파일의 값입니다:
S3 스토리지 사용
필수 매개변수
| 매개변수 | 설명 |
|---|---|
endpoint | path 또는 virtual hosted 방식의 S3 endpoint URL입니다. 데이터 저장용 버킷과 루트 경로를 포함해야 합니다. |
access_key_id | 인증에 사용되는 S3 액세스 키 ID입니다. |
secret_access_key | 인증에 사용되는 S3 시크릿 액세스 키입니다. |
선택적 매개변수
| 매개변수 | 설명 | 기본값 |
|---|---|---|
region | S3 리전 이름입니다. | - |
support_batch_delete | 일괄 삭제(batch delete) 지원 여부를 확인할지 제어합니다. GCS는 일괄 삭제를 지원하지 않으므로 Google Cloud Storage(GCS)를 사용할 때는 false로 설정합니다. | true |
use_environment_credentials | 환경 변수 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN가 있으면 AWS 자격 증명을 해당 환경 변수에서 읽습니다. 참고: 환경 자격 증명은 모든 S3 디스크에서 공유됩니다. 디스크마다 서로 다른 자격 증명을 사용하려면 대신 각 디스크에 access_key_id와 secret_access_key를 명시적으로 지정하십시오. | false |
use_insecure_imds_request | true이면 Amazon EC2 메타데이터에서 자격 증명을 가져올 때 안전하지 않은 IMDS 요청을 사용합니다. | false |
expiration_window_seconds | 만료 기반 자격 증명이 만료되었는지 확인할 때 적용하는 유예 기간(초)입니다. | 120 |
proxy | S3 엔드포인트용 프록시 구성입니다. proxy 블록 내부의 각 uri 요소에는 프록시 URL이 포함되어야 합니다. | - |
connect_timeout_ms | 소켓 연결 타임아웃(밀리초)입니다. | 10000 (10초) |
request_timeout_ms | 요청 타임아웃(밀리초)입니다. | 5000 (5초) |
retry_attempts | 실패한 요청에 대한 재시도 횟수입니다. | 10 |
single_read_retries | 읽기 중 연결이 끊어졌을 때의 재시도 횟수입니다. | 4 |
min_bytes_for_seek | 순차 읽기 대신 seek 작업을 사용하기 위한 최소 바이트 수입니다. | 1 MB |
metadata_path | S3 메타데이터 파일을 저장할 로컬 파일 시스템 경로입니다. | /var/lib/clickhouse/disks/<disk_name>/ |
skip_access_check | true이면 시작 시 디스크 접근 검사를 건너뜁니다. | false |
header | 지정한 HTTP 헤더를 요청에 추가합니다. 여러 번 지정할 수 있습니다. | - |
server_side_encryption_customer_key_base64 | SSE-C 암호화가 적용된 S3 객체에 접근하는 데 필요한 헤더입니다. | - |
server_side_encryption_kms_key_id | SSE-KMS 암호화가 적용된 S3 객체에 접근하는 데 필요한 헤더입니다. 빈 문자열이면 AWS 관리형 S3 키를 사용합니다. | - |
server_side_encryption_kms_encryption_context | SSE-KMS용 암호화 컨텍스트 헤더입니다(server_side_encryption_kms_key_id와 함께 사용). | - |
server_side_encryption_kms_bucket_key_enabled | SSE-KMS용 S3 버킷 키를 활성화합니다(server_side_encryption_kms_key_id와 함께 사용). | 버킷 수준 설정과 동일 |
s3_max_put_rps | 스로틀링이 적용되기 전의 초당 최대 PUT 요청 수입니다. | 0 (무제한) |
s3_max_put_burst | RPS 제한에 도달하기 전까지 허용되는 최대 동시 PUT 요청 수입니다. | s3_max_put_rps와 동일 |
s3_max_get_rps | 스로틀링이 적용되기 전의 초당 최대 GET 요청 수입니다. | 0 (무제한) |
s3_max_get_burst | RPS 제한에 도달하기 전까지 허용되는 최대 동시 GET 요청 수입니다. | s3_max_get_rps와 동일 |
read_resource | 읽기 요청을 스케줄링하기 위한 리소스 이름입니다. | 빈 문자열(비활성화) |
write_resource | 쓰기 요청을 스케줄링하기 위한 리소스 이름입니다. | 빈 문자열(비활성화) |
key_template | re2 구문을 사용해 객체 키 생성 포맷을 정의합니다. storage_metadata_write_full_object_key 플래그가 필요합니다. endpoint의 root path와 호환되지 않습니다. key_compatibility_prefix가 필요합니다. | - |
key_compatibility_prefix | key_template과 함께 필요합니다. 이전 메타데이터 버전을 읽기 위해 endpoint의 기존 root path를 지정합니다. | - |
read_only | 디스크에서 읽기만 허용합니다. | - |
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_rewritable는 24.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에 데이터를 저장할 수 있습니다.
구성 예시:
연결 매개변수
| 매개변수 | 설명 | 기본값 |
|---|---|---|
storage_account_url (필수) | Azure Blob Storage 스토리지 계정 URL입니다. 예시: http://account.blob.core.windows.net 또는 http://azurite1:10000/devstoreaccount1입니다. | - |
container_name | 대상 컨테이너 이름입니다. | default-container |
container_already_exists | 컨테이너 생성 동작을 제어합니다: - false: 새 컨테이너를 생성합니다 - true: 기존 컨테이너에 직접 연결합니다 - 설정되지 않음: 컨테이너가 있는지 확인한 후, 필요하면 생성합니다 | - |
| 매개변수 | 설명 |
|---|---|
connection_string | connection string을 사용한 인증에 사용합니다. |
account_name | Shared Key를 사용한 인증에 사용합니다(account_key와 함께 사용). |
account_key | Shared Key를 사용한 인증에 사용합니다(account_name과 함께 사용). |
제한 매개변수
| 매개변수 | 설명 |
|---|---|
s3_max_single_part_upload_size | Blob Storage로 단일 블록을 업로드할 때의 최대 크기입니다. |
min_bytes_for_seek | seek 가능한 영역의 최소 크기입니다. |
max_single_read_retries | Blob Storage에서 데이터 청크를 읽을 때의 최대 재시도 횟수입니다. |
max_single_download_retries | Blob Storage에서 읽기 가능한 버퍼를 다운로드할 때의 최대 재시도 횟수입니다. |
thread_pool_size | IDiskRemote 인스턴스화를 위한 최대 스레드 수입니다. |
s3_max_inflight_parts_for_one_file | 단일 객체에 대한 동시 put 요청의 최대 수입니다. |
기타 매개변수
| 매개변수 | 설명 | 기본값 |
|---|---|---|
metadata_path | Blob Storage용 메타데이터 파일을 저장할 로컬 파일 시스템 경로입니다. | /var/lib/clickhouse/disks/<disk_name>/ |
skip_access_check | true이면 시작 시 디스크 접근 검사를 건너뜁니다. | false |
read_resource | 읽기 요청 스케줄링에 사용할 리소스 이름입니다. | 빈 문자열(비활성화됨) |
write_resource | 쓰기 요청 스케줄링에 사용할 리소스 이름입니다. | 빈 문자열(비활성화됨) |
metadata_keep_free_space_bytes | 메타데이터 디스크에 예약해 둘 여유 공간의 크기입니다. | - |
Zero-copy 복제는 프로덕션용으로는 아직 준비되지 않았습니다ClickHouse 버전 22.8 이상에서는 zero-copy 복제가 기본적으로 비활성화되어 있습니다. 이 기능은 프로덕션 환경에서 사용하도록 권장되지 않습니다.
HDFS 스토리지 사용(지원되지 않음)
- 디스크 유형은
hdfs입니다(지원되지 않음) - 데이터는
hdfs://hdfs1:9000/clickhouse/에 저장됩니다
데이터 암호화 사용
encrypted인 디스크를 정의하고, 데이터가 저장될 디스크를 선택해야 합니다. encrypted 디스크는 쓰여지는 모든 파일을 실시간으로 암호화하며, encrypted 디스크에서 파일을 읽을 때는 자동으로 복호화합니다. 따라서 encrypted 디스크도 일반 디스크처럼 사용할 수 있습니다.
디스크 구성 예시:
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 경로에 암호화된 상태로 기록됩니다.
필수 매개변수
| 매개변수 | 유형 | 설명 |
|---|---|---|
type | String | 암호화된 디스크를 생성하려면 encrypted로 설정해야 합니다. |
disk | String | underlying storage에 사용할 디스크 유형입니다. |
key | Uint64 | 암호화 및 복호화에 사용할 키입니다. key_hex를 사용해 16진수로 지정할 수 있습니다. id 속성을 사용하면 여러 키를 지정할 수 있습니다. |
선택적 매개변수
| 매개변수 | 유형 | 기본값 | 설명 |
|---|---|---|---|
path | String | 루트 디렉터리 | 디스크에서 데이터가 저장될 위치입니다. |
current_key_id | String | - | 암호화에 사용되는 키 ID입니다. 지정된 모든 키는 복호화에 사용할 수 있습니다. |
algorithm | Enum | AES_128_CTR | 암호화 알고리즘입니다. 옵션: - AES_128_CTR (16바이트 키) - AES_192_CTR (24바이트 키) - AES_256_CTR (32바이트 키) |
로컬 캐시 사용
s3 디스크 유형에서만 캐시를 지원합니다. 버전 >= 22.8에서는 S3, Azure, Local, Encrypted 등 모든 디스크 유형에서 캐시를 지원합니다.
버전 >= 23.5에서는 S3, Azure, HDFS(미지원)와 같은 원격 디스크 유형에서만 캐시를 지원합니다.
캐시는 LRU 캐시 정책을 사용합니다.
버전 22.8 이상에서의 구성 예시는 다음과 같습니다:
| Parameter | Type | Default | Description |
|---|---|---|---|
path | String | - | 필수. 캐시가 저장될 디렉터리 경로입니다. |
max_size | Size | - | 필수. 바이트 또는 읽기 쉬운 형식(예: 10Gi)으로 지정하는 최대 캐시 크기입니다. 한도에 도달하면 파일은 LRU 정책에 따라 제거됩니다. ki, Mi, Gi 포맷을 지원합니다(v22.10부터). |
cache_on_write_operations | Boolean | false | INSERT 쿼리와 백그라운드 머지에 대해 write-through 캐시를 활성화합니다. 쿼리별로 enable_filesystem_cache_on_write_operations를 사용해 재정의할 수 있습니다. |
enable_filesystem_query_cache_limit | Boolean | false | max_query_cache_size를 기준으로 쿼리별 캐시 크기 제한을 활성화합니다. |
enable_cache_hits_threshold | Boolean | false | 활성화하면 데이터를 여러 번 읽은 뒤에만 캐시합니다. |
cache_hits_threshold | Integer | 0 | 데이터가 캐시되기 전에 필요한 읽기 횟수입니다(enable_cache_hits_threshold 필요). |
enable_bypass_cache_with_threshold | Boolean | false | 큰 읽기 범위에서는 캐시를 건너뜁니다. |
bypass_cache_threshold | Size | 256Mi | 이 값을 초과하는 읽기 범위 크기에서는 캐시를 우회합니다(enable_bypass_cache_with_threshold 필요). |
max_file_segment_size | Size | 8Mi | 바이트 또는 읽기 쉬운 형식으로 지정하는 단일 캐시 파일의 최대 크기입니다. |
max_elements | Integer | 10000000 | 캐시 파일의 최대 개수입니다. |
load_metadata_threads | Integer | 16 | 시작 시 캐시 메타데이터를 로드하는 데 사용할 스레드 수입니다. |
use_split_cache | Boolean | false | 파일을 시스템/데이터로 분리해 사용합니다. |
split_cache_ratio | Double | 0.1 | split_cache에서 시스템 세그먼트가 전체 캐시 크기에서 차지하는 비율입니다. |
참고: 크기 값은ki,Mi,Gi등의 단위를 지원합니다(예:10Gi).
파일 캐시 쿼리/프로필 설정
| 설정 | 유형 | 기본값 | 설명 |
|---|---|---|---|
enable_filesystem_cache | 불리언 | true | cache 디스크 유형을 사용하는 경우에도 쿼리별로 캐시 사용을 활성화하거나 비활성화합니다. |
read_from_filesystem_cache_if_exists_otherwise_bypass_cache | 불리언 | false | 활성화하면 데이터가 있을 때만 캐시를 사용하며, 새 데이터는 캐시되지 않습니다. |
enable_filesystem_cache_on_write_operations | 불리언 | false (Cloud: true) | write-through 캐시를 활성화합니다. 캐시 구성에서 cache_on_write_operations를 설정해야 합니다. |
enable_filesystem_cache_log | 불리언 | false | system.filesystem_cache_log에 상세한 캐시 사용 로깅을 활성화합니다. |
filesystem_cache_allow_background_download | 불리언 | true | 부분적으로 다운로드된 세그먼트를 백그라운드에서 마저 다운로드하도록 허용합니다. 비활성화하면 현재 쿼리/세션에 대해 다운로드가 포그라운드에서 계속 진행됩니다. |
max_query_cache_size | 크기 | false | 쿼리별 최대 캐시 크기입니다. 캐시 구성에서 enable_filesystem_query_cache_limit를 설정해야 합니다. |
filesystem_cache_skip_download_if_exceeds_per_query_cache_write_limit | 불리언 | true | max_query_cache_size에 도달했을 때의 동작을 제어합니다: - true: 새 데이터 다운로드를 중지합니다 - false: 새 데이터를 위한 공간을 확보하기 위해 오래된 데이터를 제거합니다 |
캐시 시스템 테이블
| 테이블 이름 | 설명 | 요구 사항 |
|---|---|---|
system.filesystem_cache | 파일 시스템 캐시의 현재 상태를 표시합니다. | 없음 |
system.filesystem_cache_log | 쿼리별 상세 캐시 사용 통계를 제공합니다. | enable_filesystem_cache_log = true가 필요합니다. |
캐시 명령어
SYSTEM CLEAR|DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER) — ON CLUSTER
<cache_name>을 지정하지 않은 경우에만 지원됩니다
SHOW FILESYSTEM CACHES
22.8 이하 버전에서는 이 명령의 이름이 SHOW CACHES입니다)
Query
Response
DESCRIBE FILESYSTEM CACHE '<cache_name>'
SHOW FILESYSTEM CACHES 명령으로 확인할 수 있습니다. (22.8
이하 버전에서는 이 명령의 이름이 DESCRIBE CACHE입니다)
Query
Response
| 캐시 현재 메트릭 | 캐시 비동기 메트릭 | 캐시 프로파일 이벤트 |
|---|---|---|
FilesystemCacheSize | FilesystemCacheBytes | CachedReadBufferReadFromSourceBytes, CachedReadBufferReadFromCacheBytes |
FilesystemCacheElements | FilesystemCacheFiles | CachedReadBufferReadFromSourceMicroseconds, CachedReadBufferReadFromCacheMicroseconds |
CachedReadBufferCacheWriteBytes, CachedReadBufferCacheWriteMicroseconds | ||
CachedWriteBufferCacheWriteBytes, CachedWriteBufferCacheWriteMicroseconds |
정적 Web 스토리지 사용(읽기 전용)
ATTACH TABLE 쿼리로 이 디스크에 로드됩니다(아래 예시 참조). 로컬 디스크는 실제로 사용되지 않으며, 각 SELECT 쿼리는 필요한 데이터를 가져오기 위해 http 요청을 보냅니다. 테이블 데이터를 수정하려는 모든 작업은 예외를 발생시키므로, 다음과 같은 쿼리 유형은 허용되지 않습니다: CREATE TABLE,
ALTER TABLE, RENAME TABLE,
DETACH TABLE 및 TRUNCATE TABLE.
Web 스토리지는 읽기 전용 용도로 사용할 수 있습니다. 예를 들어 샘플 데이터를 호스팅하거나 데이터를 마이그레이션할 때 사용할 수 있습니다. clickhouse-static-files-uploader라는 도구는 지정한 테이블의 데이터 디렉터리를 준비합니다(SELECT data_paths FROM system.tables WHERE name = 'table_name').
필요한 각 테이블마다 파일 디렉터리가 생성됩니다. 이 파일들은
예를 들어 정적 파일을 제공하는 웹 서버에 업로드할 수 있습니다. 이 준비가 끝나면,
DiskWeb를 통해 이 테이블을 어느 ClickHouse 서버에서나 로드할 수 있습니다.
이 예시 구성에서는:
- 디스크 유형은
web입니다 - 데이터는
http://nginx:80/test1/에서 호스팅됩니다 - 로컬 스토리지의 캐시를 사용합니다
ATTACH TABLE 쿼리에서는 제공된 UUID가 데이터 디렉터리 이름과 일치하고, 엔드포인트는 GitHub 원본 콘텐츠의 URL입니다.
필수 매개변수
| 매개변수 | 설명 |
|---|---|
type | web여야 합니다. 그렇지 않으면 디스크가 생성되지 않습니다. |
endpoint | path 형식의 엔드포인트 URL입니다. 엔드포인트 URL에는 데이터가 업로드되는 루트 저장 경로가 포함되어야 합니다. |
선택적 매개변수
| 매개변수 | 설명 | 기본값 |
|---|---|---|
min_bytes_for_seek | 순차 읽기 대신 seek 작업을 사용하기 위한 최소 바이트 수 | 1 MB |
remote_fs_read_backoff_threashold | 원격 디스크의 데이터를 읽으려 할 때의 최대 대기 시간 | 10000초 |
remote_fs_read_backoff_max_tries | 백오프를 사용해 읽기를 시도하는 최대 횟수 | 5 |
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 복제(프로덕션 환경에서는 아직 사용할 수 없음)
S3 및 HDFS(미지원) 디스크에서 zero-copy 복제를 사용할 수는 있지만, 권장되지는 않습니다. zero-copy 복제는 데이터가 여러 머신의 원격 스토리지에 저장되어 있고 이를 동기화해야 할 때, 데이터 자체는 복제하지 않고 메타데이터(데이터 파트의 경로)만 복제하는 방식입니다.
zero-copy 복제는 프로덕션 환경에서 아직 사용할 수 없습니다ClickHouse 버전 22.8 이상에서는 zero-copy 복제가 기본적으로 비활성화되어 있습니다. 이 기능은 프로덕션 환경에서 사용하는 것을 권장하지 않습니다.