삽입 전략 선택하기

삽입 전략 선택하기

효율적인 데이터 수집은 고성능 ClickHouse 배포의 기초입니다. 올바른 삽입 전략을 선택하면 처리량, 비용, 신뢰성에 큰 영향을 줍니다. 이 문서에서는 동기/비동기 삽입의 모범 사례와 트레이드오프, 구성 옵션을 설명할게요.

출처: 문서

본문

효율적인 데이터 수집은 고성능 ClickHouse 배포의 기초를 이룹니다. 올바른 삽입 전략을 선택하면 처리량, 비용, 신뢰성에 극적인 영향을 줄 수 있습니다. 이 섹션에서는 워크로드에 맞는 올바른 결정을 내리는 데 도움이 되는 모범 사례, 트레이드오프, 구성 옵션을 설명합니다.

다음은 클라이언트를 통해 ClickHouse로 데이터를 푸시한다고 가정합니다. s3와 gcs 같은 내장 테이블 함수를 사용해 ClickHouse로 데이터를 가져오는 경우 “S3 삽입 및 읽기 성능 최적화” 가이드를 권장합니다.

기본적으로 동기 삽입

기본적으로 ClickHouse에 대한 삽입은 동기적입니다. 각 삽입 쿼리는 메타데이터와 인덱스를 포함한 저장 파트를 디스크에 즉시 만듭니다.

클라이언트 측에서 데이터를 배치할 수 있으면 동기 삽입을 사용하세요. 그렇지 않으면 아래의 비동기 삽입을 참고하세요.

아래에서 ClickHouse의 MergeTree 삽입 메커니즘을 간략히 살펴봅니다:

클라이언트 측 단계

최적의 성능을 위해 데이터는 ① 배치(batched)되어야 하며, 배치 크기가 첫 번째 결정입니다. ClickHouse는 삽입된 데이터를 테이블의 프라이머리 키 컬럼으로 정렬하여 디스크에 저장합니다. 두 번째 결정은 전송 전에 데이터를 ② 사전 정렬할지 여부입니다. 배치가 프라이머리 키 컬럼으로 미리 정렬되어 도착하면 ClickHouse는 ⑩ 정렬 단계를 건너뛸 수 있어 수집 속도가 빨라집니다. 수집할 데이터에 미리 정의된 형식이 없다면 핵심 결정은 형식 선택입니다. ClickHouse는 70개 이상의 형식으로 데이터 삽입을 지원합니다. 하지만 ClickHouse 명령줄 클라이언트나 프로그래밍 언어 클라이언트를 사용할 때는 이 선택이 종종 자동으로 처리됩니다. 필요하면 이 자동 선택을 명시적으로 재정의할 수도 있습니다. 다음 주요 결정은 ClickHouse 서버로 전송하기 전에 데이터를 ④ 압축할지 여부입니다. 압축은 전송 크기를 줄이고 네트워크 효율을 개선하여, 특히 대규모 데이터셋에서 더 빠른 데이터 전송과 더 낮은 대역폭 사용을 이끕니다. 데이터는 ⑤ 네이티브 또는 HTTP 인터페이스(이 포스트 후반부에서 비교함) 중 하나인 ClickHouse 네트워크 인터페이스로 전송됩니다.

서버 측 단계

⑥ 데이터를 받은 후 ClickHouse는 압축이 사용되었다면 ⑦ 압축을 해제하고, ⑧ 원래 보낸 형식에서 파싱합니다. 그 형식화된 데이터의 값과 대상 테이블의 DDL 문을 사용해 ClickHouse는 ⑨ MergeTree 형식의 인메모리 블록을 만들고, 행이 미리 정렬되지 않았다면 ⑩ 프라이머리 키 컬럼으로 정렬하며, ⑪ 희소 프라이머리 인덱스를 만들고, ⑫ 컬럼별 압축을 적용하며, ⑬ 데이터를 새 ⑭ 데이터 파트로 디스크에 씁니다.

동기 삽입 시 배치하기

위 메커니즘은 삽입 크기와 무관한 일정한 오버헤드를 보여주므로, 배치 크기는 수집 처리량에서 가장 중요한 최적화입니다. 삽입을 배치하면 총 삽입 시간에서 오버헤드의 비율이 줄고 처리 효율이 개선됩니다. 최소 1,000행, 이상적으로는 10,000~100,000행 단위로 데이터를 삽입할 것을 권장합니다. 더 적고 더 큰 삽입은 쓰여지는 파츠 수를 줄이고, 머지 부하를 최소화하며, 전체 시스템 리소스 사용을 낮춥니다. 동기 삽입 전략이 효과적이려면 이 클라이언트 측 배치가 필요합니다. 클라이언트 측에서 데이터를 배치할 수 없다면 ClickHouse는 배치를 서버로 옮기는 비동기 삽입을 지원합니다(비동기 삽입 참고).

삽입 크기와 관계없이 삽입 쿼리 수를 초당 약 1개의 삽입 쿼리로 유지할 것을 권장합니다. 이 권장 이유는 생성된 파츠가 (읽기 쿼리를 위해 데이터를 최적화하기 위해) 백그라운드에서 더 큰 파츠로 머지되는데, 초당 너무 많은 삽입 쿼리를 보내면 백그라운드 머지가 새 파츠 수를 따라가지 못하는 상황이 생길 수 있기 때문입니다. 다만 비동기 삽입을 사용하면 초당 더 높은 삽입 쿼리 비율을 사용할 수 있습니다(비동기 삽입 참고).

멱등적 재시도 보장하기

동기 삽입은 또한 멱등적(idempotent) 입니다. MergeTree 엔진을 사용할 때 ClickHouse는 기본적으로 삽입을 중복 제거합니다. 이는 모호한 실패 상황을 방지합니다. 예:

  • 삽입은 성공했지만 네트워크 중단으로 클라이언트가 확인을 받지 못한 경우.
  • 삽입이 서버 측에서 실패하고 타임아웃된 경우.

두 경우 모두 배치 내용과 순서가 동일하게 유지된다면 삽입을 재시도해도 안전합니다. 이런 이유로 클라이언트가 데이터를 수정하거나 재정렬하지 않고 일관되게 재시도하는 것이 중요합니다.

올바른 삽입 대상 선택하기

샤딩된 클러스터에는 두 가지 옵션이 있습니다:

  • MergeTree 또는 ReplicatedMergeTree 테이블에 직접 삽입. 클라이언트가 샤드 간에 로드 밸런싱을 수행할 수 있을 때 가장 효율적인 옵션입니다. internal_replication = true로 설정하면 ClickHouse가 복제를 투명하게 처리합니다.
  • Distributed 테이블에 삽입. 클라이언트가 아무 노드에나 데이터를 보내고 ClickHouse가 올바른 샤드로 전달하게 합니다. 더 단순하지만 추가 전달 단계 때문에 약간 덜 성능이 좋습니다. internal_replication = true가 여전히 권장됩니다.

ClickHouse Cloud에서는 모든 노드가 같은 단일 샤드에 읽고 씁니다. 삽입은 노드 간에 자동으로 균형을 이룹니다. 노출된 엔드포인트로 삽입을 보내기만 하면 됩니다.

올바른 형식 선택하기

올바른 입력 형식을 선택하는 것은 ClickHouse에서 효율적인 데이터 수집에 중요합니다. 70개 이상의 지원 형식 중 가장 성능이 좋은 옵션을 선택하는 것이 삽입 속도, CPU와 메모리 사용, 전체 시스템 효율에 큰 영향을 줄 수 있습니다. 유연성이 데이터 엔지니어링과 파일 기반 가져오기에 유용하지만, 애플리케이션은 성능 지향 형식을 우선시해야 합니다:

  • Native 형식 (권장): 가장 효율적입니다. 컬럼 지향이며 서버 측 파싱이 최소입니다. Go와 Python 클라이언트에서 기본적으로 사용됩니다.
  • RowBinary: 효율적인 행 기반 형식이며, 클라이언트 측에서 컬럼형 변환이 어려울 때 이상적입니다. Java 클라이언트에서 사용됩니다.
  • JSONEachRow: 사용하기 쉽지만 파싱 비용이 비쌉니다. 낮은 볼륨 사용 사례나 빠른 통합에 적합합니다.

압축 사용하기

압축은 네트워크 오버헤드를 줄이고, 삽입을 빠르게 하며, ClickHouse에서 저장 비용을 낮추는 데 중요한 역할을 합니다. 효과적으로 사용하면 데이터 형식이나 스키마를 변경하지 않고도 수집 성능을 향상시킵니다. 삽입 데이터를 압축하면 네트워크로 보내는 페이로드 크기가 줄어 대역폭 사용을 최소화하고 전송을 가속화합니다. 삽입에서 압축은 ClickHouse의 내부 컬럼형 저장 모델과 이미 일치하는 Native 형식과 함께 사용할 때 특히 효과적입니다. 이 설정에서 서버는 최소한의 변환으로 효율적으로 압축을 해제하고 데이터를 직접 저장할 수 있습니다.

속도에는 LZ4, 압축률에는 ZSTD

ClickHouse는 데이터 전송 중 여러 압축 코덱을 지원합니다. 두 가지 일반적인 옵션은:

  • LZ4: 빠르고 가볍습니다. 최소한의 CPU 오버헤드로 데이터 크기를 크게 줄여, 높은 처리량의 삽입에 이상적이며 대부분의 ClickHouse 클라이언트에서 기본입니다.
  • ZSTD: 더 높은 압축률이지만 CPU 집약적입니다. 네트워크 전송 비용이 높을 때 — 예: 크로스 리전이나 클라우드 제공자 시나리오 — 유용하며, 클라이언트 측 계산과 서버 측 압축 해제 시간이 약간 증가합니다.

모범 사례: 대역폭이 제한되거나 데이터 이그레스 비용이 발생하지 않는다면 LZ4를 사용하고, 그런 경우에만 ZSTD를 고려하세요.

FastFormats 벤치마크 테스트에서 LZ4로 압축된 Native 삽입은 데이터 크기를 50% 이상 줄여, 5.6 GiB 데이터셋의 수집 시간을 150초에서 131초로 단축했습니다. ZSTD로 전환하면 같은 데이터셋이 1.69 GiB로 압축되었지만 서버 측 처리 시간이 약간 늘었습니다.

압축은 리소스 사용을 줄입니다

압축은 네트워크 트래픽만 줄이는 것이 아니라 서버의 CPU와 메모리 효율도 개선합니다. 압축된 데이터로 ClickHouse는 더 적은 바이트를 받고 큰 입력을 파싱하는 데 시간을 덜 씁니다. 이 이점은 관측성 시나리오처럼 여러 동시 클라이언트에서 수집할 때 특히 중요합니다. CPU와 메모리에 대한 압축의 영향은 LZ4에서 미미하고 ZSTD에서 적당합니다. 부하가 걸리더라도 데이터 볼륨이 줄어 서버 측 효율이 개선됩니다. 압축을 배치와 효율적인 입력 형식(Native 같은)과 결합하면 최상의 수집 성능을 얻습니다. 네이티브 인터페이스(예: clickhouse-client)를 사용할 때 LZ4 압축이 기본적으로 활성화됩니다. 설정을 통해 선택적으로 ZSTD로 전환할 수 있습니다. HTTP 인터페이스에서는 Content-Encoding 헤더를 사용해 압축을 적용합니다(예: Content-Encoding: lz4). 전체 페이로드는 전송 전에 압축되어야 합니다.

비용이 낮으면 사전 정렬하기

삽입 전에 데이터를 프라이머리 키로 사전 정렬하면 ClickHouse 수집 효율을 개선할 수 있으며, 특히 큰 배치에서 그렇습니다. 데이터가 미리 정렬되어 도착하면 ClickHouse는 파트 생성 중 내부 정렬 단계를 건너뛰거나 단순화하여 CPU 사용을 줄이고 삽입 과정을 가속화합니다. 사전 정렬은 유사한 값이 함께 그룹화되므로 압축 효율도 개선합니다 — LZ4나 ZSTD 같은 코덱이 더 나은 압축률을 달성할 수 있게 합니다. 이는 큰 배치 삽입과 압축과 결합할 때 특히 유리하며, 처리 오버헤드와 전송되는 데이터 양을 모두 줄입니다. 그렇지만 사전 정렬은 선택적 최적화이지 요구 사항이 아닙니다. ClickHouse는 병렬 처리를 사용해 데이터를 매우 효율적으로 정렬하므로, 많은 경우 서버 측 정렬이 클라이언트 측 사전 정렬보다 빠르거나 더 편리합니다. 데이터가 이미 거의 정렬되어 있거나 클라이언트 측 리소스(CPU, 메모리)가 충분하고 활용도가 낮은 경우에만 사전 정렬을 권장합니다. 관측성과 같은 지연 시간 민감 또는 고처리량 사용 사례에서, 데이터가 순서 없이 또는 많은 에이전트에서 도착한다면 사전 정렬을 건너뛰고 ClickHouse의 내장 성능에 의존하는 것이 종종 더 낫습니다.

비동기 삽입

ClickHouse의 비동기 삽입은 클라이언트 측 배치가 실현 불가능할 때 강력한 대안을 제공합니다. 이는 수백 또는 수천 개의 에이전트가 로그, 메트릭, 트레이스를 종종 작고 실시간 페이로드로 지속적으로 보내는 관측성 워크로드에서 특히 가치 있습니다. 이러한 환경에서 클라이언트 측 데이터 버퍼링은 복잡성을 증가시켜 충분히 큰 배치를 보낼 수 있도록 중앙 집중식 큐가 필요합니다.

동기 모드에서 많은 작은 배치를 보내는 것은 권장되지 않으며, 많은 파츠가 생성됩니다. 이는 좋지 않은 쿼리 성능과 “too many parts” 오류로 이어질 것입니다.

비동기 삽입은 들어오는 데이터를 인메모리 버퍼에 쓴 다음 설정 가능한 임계값에 따라 스토리지로 플러시하여 배치 책임을 클라이언트에서 서버로 옮깁니다. 이 접근 방식은 파츠 생성 오버헤드를 크게 줄이고, CPU 사용을 낮추며, 높은 동시성에서도 수집 효율을 보장합니다. 핵심 동작은 async_insert 설정으로 제어합니다.

비동기 삽입은 HTTP와 네이티브 TCP 인터페이스 모두에서 지원됩니다. 활성화되면(async_insert = 1) 삽입은 버퍼링되고 다음 플러시 조건 중 하나가 충족될 때만 디스크에 쓰여집니다:

먼저 도달하는 임계값이 플러시를 트리거합니다. 이 배치 과정은 클라이언트에 보이지 않으며 ClickHouse가 여러 소스의 삽입 트래픽을 효율적으로 병합하도록 돕습니다. 그러나 플러시가 일어날 때까지 데이터는 쿼리할 수 없습니다. 중요하게도 삽입 형태와 설정 조합마다 여러 버퍼가 있으며, 클러스터에서는 버퍼가 노드별로 유지됩니다 — 멀티 테넌트 환경에서 세밀한 제어가 가능합니다. 삽입 메커니즘은 그 외에는 동기 삽입에서 설명한 것과 동일합니다.

반환 모드 선택하기

비동기 삽입의 동작은 wait_for_async_insert 설정으로 더 세밀하게 다듬어집니다. 1(기본값)로 설정하면 ClickHouse는 데이터가 디스크에 성공적으로 플러시된 후에만 삽입을 확인합니다. 이는 강력한 내구성 보장을 보장하고 오류 처리를 간단하게 만듭니다: 플러시 중 문제가 발생하면 오류가 클라이언트에 반환됩니다. 이 모드는 특히 삽입 실패를 안정적으로 추적해야 할 때 대부분의 프로덕션 시나리오에 권장됩니다. 벤치마크는 적응형 삽입과 안정적인 파츠 생성 동작 덕분에 200개든 500개든 클라이언트 수에 관계없이 동시성에 잘 확장된다는 것을 보여줍니다. wait_for_async_insert = 0으로 설정하면 "fire-and-forget" 모드가 활성화됩니다. 여기서 서버는 데이터가 버퍼링되는 즉시 삽입을 확인하고, 스토리지에 도달할 때까지 기다리지 않습니다. 이는 초저지연 삽입과 최대 처리량을 제공하며, 고속·저중요도 데이터에 이상적입니다. 그러나 트레이드오프가 있습니다: 데이터가 저장될 보장이 없고, 오류는 플러시 중에만 드러나며, 실패한 삽입에 대한 데드 레터 큐가 없습니다 — 실패 추적은 사후에 서버 로그와 시스템 테이블을 검사해야 합니다. 데이터 손실을 허용할 수 있는 워크로드에서만 이 모드를 사용하세요. 벤치마크는 또한 버퍼 플러시가 드물 때(예: 30초마다) 파츠 감소와 CPU 사용 하락이 상당하다는 것을 보여주지만, 조용한 실패의 위험은 남아 있습니다. 비동기 삽입을 사용한다면 async_insert=1, wait_for_async_insert=1을 사용할 것을 강력히 권장합니다. wait_for_async_insert=0을 사용하는 것은 매우 위험합니다. INSERT 클라이언트가 오류가 있는지 인지하지 못할 수 있고, ClickHouse 서버가 따라잡아야 하는 상황에서 클라이언트가 계속 빠르게 쓰면 잠재적 과부하를 일으킬 수 있기 때문입니다.

적응형 비동기 삽입

24.2 버전부터 ClickHouse는 기본적으로 적응형 플러시 타임아웃을 사용합니다(async_insert_use_adaptive_busy_timeout). 고정 플러시 간격 대신 들어오는 데이터 속도에 따라 타임아웃이 최소(async_insert_busy_timeout_min_ms, 기본 50ms)와 최대(async_insert_busy_timeout_max_ms, 기본 200ms 또는 Cloud에서 1000ms) 사이에서 동적으로 조정됩니다. 데이터가 자주 도착하면 타임아웃은 최소에 가깝게 유지되어 더 빨리 플러시하고 종단 간 지연을 줄입니다. 데이터가 드물면 최대 쪽으로 커져 더 큰 배치를 축적합니다. 이것은 특히 기본 모드(wait_for_async_insert=1)에서 유용한데, 고정된 높은 타임아웃은 데이터가 플러시될 준비가 되어도 클라이언트가 전체 간격 동안 차단되게 하기 때문입니다.

오류 처리

스키마 검증과 데이터 파싱은 삽입을 받을 때가 아니라 버퍼 플러시 중에 발생합니다. 삽입 쿼리의 어떤 행에 파싱 또는 타입 오류가 있으면 그 쿼리의 어떤 데이터도 플러시되지 않습니다 — 쿼리 전체 페이로드가 거부됩니다. 기본 모드(wait_for_async_insert=1)에서는 오류가 클라이언트에 반환됩니다. fire-and-forget 모드에서는 오류가 서버 로그와 system.asynchronous_inserts 테이블에 기록됩니다. 각 플러시는 버퍼의 고유 파티션 키 값마다 최소한 하나의 파츠를 만듭니다. 파티션 키가 없는 테이블에서도 버퍼링된 데이터가 max_insert_block_size(기본 약 100만 행)를 초과하면 단일 플러시가 여러 파츠를 생성할 수 있습니다.

비동기 삽입을 사용해도 파티셔닝 키의 카디널리티가 높으면 “too many parts” 오류를 여전히 만날 수 있습니다.

중복 제거와 신뢰성

26.2 버전부터 ClickHouse는 동기 삽입뿐 아니라 비동기 삽입에도 자동 중복 제거를 수행하여 중복 제거 로그를 유지하는 테이블에서 재시도를 안전하게 만듭니다. *ReplicatedMergeTree 엔진은 기본적으로 하나를 유지하며, 일반 MergeTree 테이블은 non_replicated_deduplication_window를 양수로 설정해야 합니다. 두 삽입 유형 모두 deduplicate_insert로 제어되며 기본값은 enable입니다. 의존 머티리얼라이즈드 뷰가 지원됩니다. 실제로 타임아웃이나 네트워크 끊김 같은 이유로 같은 삽입이 재시도되면 ClickHouse는 중복을 안전하게 무시할 수 있습니다. 이는 멱등성을 유지하고 데이터 이중 쓰기를 피하는 데 도움이 됩니다. 비동기 삽입의 경우 중복 제거는 플러시된 배치가 아니라 사용자 쿼리별로 작동하므로, 중복 쿼리가 함께 배치된 다른 쿼리를 버리지 않습니다. 자세한 내용과 비동기 삽입에서 머티리얼라이즈드 뷰에 적용되는 한 제한 사항은 재시도 시 삽입 중복 제거를 참고하세요.

비동기 삽입 활성화하기

비동기 삽입은 특정 사용자 또는 특정 쿼리에 대해 활성화할 수 있습니다:

  • 사용자 수준에서 비동기 삽입 활성화. 이 예제는 default 사용자를 사용합니다. 다른 사용자를 만들었다면 그 사용자 이름으로 바꾸세요:
ALTER USER default SETTINGS async_insert = 1
  • 삽입 쿼리의 SETTINGS 절로 비동기 삽입 설정을 지정할 수 있습니다:
INSERT INTO YourTable SETTINGS async_insert=1, wait_for_async_insert=1 VALUES (...)
  • ClickHouse 프로그래밍 언어 클라이언트를 사용할 때 연결 매개변수로 비동기 삽입 설정을 지정할 수도 있습니다. 예를 들어 ClickHouse Java JDBC 드라이버를 사용해 ClickHouse Cloud에 연결할 때 JDBC 연결 문자열에서 이렇게 할 수 있습니다:
"jdbc:ch://HOST.clickhouse.cloud:8443/?user=default&password=PASSWORD&ssl=true&custom_http_params=async_insert=1,wait_for_async_insert=1"

비동기 삽입은 INSERT INTO ... SELECT 쿼리에는 적용되지 않습니다. 삽입에 SELECT 절이 포함되면 async_insert 설정과 관계없이 쿼리는 항상 동기적으로 실행됩니다.

종료 시 버퍼 플러시

보류 중인 모든 비동기 삽입 버퍼를 플러시하려면 — 예를 들어 정상 종료 중이거나 유지보수 전에 — 다음을 실행하세요:

SYSTEM FLUSH ASYNC INSERT QUEUE

이렇게 하면 서버가 멈추기 전에 버퍼링된 모든 데이터가 스토리지에 쓰입니다.

버퍼 테이블과의 비교

비동기 삽입은 Buffer 테이블의 현대적인 대체물입니다. 주요 차이점:

  • DDL 변경 불필요. 비동기 삽입은 투명합니다 — 추가 테이블을 만드는 것이 아니라 설정을 활성화합니다.
  • 형태별 버퍼링. 비동기 삽입은 고유한 쿼리 형태와 설정 조합마다 별도의 버퍼를 유지하여 세밀한 플러시 정책을 가능하게 합니다. Buffer 테이블은 대상 테이블당 하나의 버퍼를 사용합니다.
  • 내구성. 기본 모드(wait_for_async_insert=1)에서 데이터는 클라이언트가 확인을 받기 전에 디스크에 확정됩니다. Buffer 테이블은 fire-and-forget처럼 동작합니다 — 버퍼링된 데이터는 크래시 시 유실됩니다.
  • 클러스터 동작. 클러스터에서 비동기 삽입 버퍼는 노드별로 유지됩니다. Buffer 테이블은 각 노드에 명시적 생성이 필요합니다.

인터페이스 선택 — HTTP 또는 네이티브

네이티브

ClickHouse는 데이터 수집을 위한 두 가지 주요 인터페이스를 제공합니다: 네이티브 인터페이스와 HTTP 인터페이스 — 각각 성능과 유연성 사이의 트레이드오프가 있습니다. clickhouse-client와 Go, C++ 같은 일부 언어 클라이언트가 사용하는 네이티브 인터페이스는 성능을 위해 특별히 설계되었습니다. 항상 ClickHouse의 고도로 효율적인 Native 형식으로 데이터를 전송하고, LZ4 또는 ZSTD로 블록 단위 압축을 지원하며, 파싱과 형식 변환 같은 작업을 클라이언트로 오프로드하여 서버 측 처리를 최소화합니다. 심지어 MATERIALIZED 및 DEFAULT 컬럼 값의 클라이언트 측 계산을 가능하게 하여 서버가 이 단계들을 완전히 건너뛰게 합니다. 이는 네이티브 인터페이스를 효율성이 중요한 높은 처리량 수집 시나리오에 이상적으로 만듭니다.

HTTP

많은 전통적인 데이터베이스와 달리 ClickHouse는 HTTP 인터페이스도 지원합니다. 이것은 반대로 호환성과 유연성을 우선시합니다. JSON, CSV, Parquet 등을 포함한 모든 지원 형식으로 데이터를 보낼 수 있게 하며, Python, Java, JavaScript, Rust를 포함한 대부분의 ClickHouse 클라이언트에서 널리 지원됩니다. 이는 로드 밸런서로 트래픽을 쉽게 전환할 수 있게 하여 ClickHouse의 네이티브 프로토콜보다 선호되는 경우가 많습니다. 네이티브 프로토콜과의 삽입 성능은 약간의 차이가 있는데, 네이티브가 오버헤드가 약간 적습니다. 그러나 네이티브 프로토콜의 더 깊은 통합은 부족하며, materialized 값 계산이나 Native 형식으로의 자동 변환 같은 클라이언트 측 최적화를 수행할 수 없습니다. HTTP 삽입은 표준 HTTP 헤더(예: Content-Encoding: lz4)로 여전히 압축할 수 있지만, 압축은 개별 데이터 블록이 아니라 전체 페이로드에 적용됩니다. 이 인터페이스는 프로토콜 단순성, 로드 밸런싱, 또는 광범위한 형식 호환성이 원시 성능보다 더 중요한 환경에서 종종 선호됩니다. 이 인터페이스들에 대한 더 자세한 설명은 여기를 참고하세요.

더 알아보기 (Learn more)