워크로드에 맞는 서비스 선택하기
워크로드에 맞는 서비스 선택하기
애플리케이션이 지원해야 하는 쿼리와 정확성(correctness) 요구 사항부터 먼저 살펴보세요. 행 수가 많다고 해서 데이터베이스가 정해지는 건 아니에요. 보고서를 생성하는 애플리케이션에도 분석 워크로드와 트랜잭션 워크로드가 함께 있을 수 있거든요. ClickHouse Cloud는 관리형 서비스의 플랫폼으로, 분석용 ClickHouse와 트랜잭션 워크로드용 ClickHouse Managed Postgres를 제공해요.
출처: 문서
본문
이 두 서비스는 각각 다른 데이터베이스 엔진 — ClickHouse와 PostgreSQL — 을 사용하며 SQL 동작도 달라요. 어느 쪽이든 독립적으로 쓸 수 있고, ClickHouse Cloud 안에서 함께 결합해 쓸 수도 있어요.
워크로드를 시작점에 매핑하기
| 애플리케이션이 필요한 것 | 시작할 평가 항목 | 선택 전에 확인할 것 |
|---|---|---|
| 대규모 이벤트·결과 이력에 대한 집계, 필터링, 비교 | ClickHouse Cloud의 ClickHouse 서비스 | 대표 쿼리, 수집 배치(ingestion batch), 데이터 신선도, 동시 쿼리, 업데이트·재시도 설계 |
| 트랜잭션 애플리케이션 상태 (주문, 재고 예약, 상태 전이에 트랜잭션·제약이 필요한 작업 등) | ClickHouse Cloud의 ClickHouse Managed Postgres | 트랜잭션 경계, 제약, 인덱스, 연결 관리, 서비스가 지원하는 기능과 가용성 |
| 트랜잭션 상태 + 독립적인 서빙 시스템이 필요한 분석 쿼리 | ClickHouse Cloud의 Postgres 및 ClickHouse 서비스 | 어느 테이블을 복제할지, 허용 가능한 복제 지연, 스키마 변경, 두 서비스의 비용과 운영 |
| 애플리케이션 로그·메트릭·트레이스 검색 및 조사를 위한 관리형 환경 | 관리형 ClickStack | 계측(instrumentation), 텔레메트리 수집, 보존 기간, 팀에 필요한 가시성 워크플로 |
| 로컬 애플리케이션·노트북 안의 파일·인메모리 데이터 분석 | chDB | 로컬 리소스와 별도로 호스팅되는 공유 데이터베이스 서비스가 필요한지 여부 |
연결된 제품 문서에서 최신 가용성, 리전, 제한 사항을 확인하세요. ClickHouse Managed Postgres는 현재 공개 베타예요. 퀵스타트를 참고하세요. 자체 관리형 ClickHouse 서버나 다른 로컬 옵션은 배포 모드를 보세요.
예시: 보고서 결과와 실행 이력
애플리케이션이 업로드된 파일을 처리하고 보고서를 생성하며, 쿼리 가능한 결과와 실행 이력을 보관해야 한다고 가정해 볼게요. 데이터베이스를 고르기 전에 결과 행과 실행 기록을 구분해 주세요.
- 결과(Results): 쿼리가 하나의 보고서에 대한 몇 개 행만 가져오는지, 아니면 여러 보고서·데이터셋·시간 범위에 걸쳐 집계하는지 확인해요. 어느 테이블이 수억 개 행에 이를 것으로 예상되나요?
- 실행 기록(Run records): 실행이 완료될 때 변경 불가능한(immutable) 기록 하나만 쓰는지, 아니면 라이브 작업 소유권과 상태 전이를 조정해야 하는지 확인해요.
- 정확성(Correctness): 여러 레코드가 하나의 트랜잭션에서 함께 변경돼야 하나요? 데이터베이스가 고유성(uniqueness)을 강제하거나 두 작업자가 같은 작업을 차지하지 못하게 막아야 하나요?
- 신선도(Freshness): 성공한 쓰기가 얼마나 빨리 보여야 하며, 불완전하거나 지연된 분석 복사본을 쿼리가 감당할 수 있나요?
완료된 실행과 분석 결과
결과 행에 대한 분석이 주 워크로드이고, 실행 기록은 완료 시 추가만 하면 된다면 ClickHouse Cloud의 ClickHouse 서비스가 후보가 돼요. 작은 메타데이터 테이블이 있다고 해서 반드시 두 번째 데이터베이스가 필요한 건 아니에요. 독자가 완료된 실행과 부분 수집된 실행을 구분하는 방법을 설계하고 테스트해 보세요. 안정적인 실행 식별자, 재시도 동작, 중복 결과 행 처리 방법을 정의해 주세요. 결과 테이블과 실행 이력 테이블에 대한 삽입을 하나의 크로스 테이블 트랜잭션으로 취급하면 안 돼요. 실행 기록의 여러 버전을 저장한다면 쿼리가 현재 버전을 선택하는 방법을 정의하세요. ReplacingMergeTree는 FINAL을 사용한 쿼리 시점 중복 제거를 지원해요. 정확성이 백그라운드 병합이 이미 일어났는지에 의존하면 안 돼요. update 참조는 또 다른 업데이트 메커니즘과 그 한계를 설명해요. 어느 패턴도 PostgreSQL 스타일의 트랜잭션 보장을 제공한다고 가정하면 안 돼요.
트랜잭션 작업 상태
실행 테이블이 트랜잭션 작업 큐나 시스템 기록(system of record)이기도 하다면 ClickHouse Managed Postgres를 평가해 보세요. 예를 들어 작업자가 제약이 강제되는 상태에서 다른 작업자와 경쟁하며 작업을 원자적으로 차지해야 하거나, 여러 애플리케이션 레코드가 함께 변경돼야 하는 경우예요. Postgres는 보고 쿼리도 서빙할 수 있어요. 모든 보고 애플리케이션에 두 데이터베이스가 필요하다고 가정하지 말고, 대표 쿼리 성능·동시성·격리 요구 사항이 이를 정당화할 때만 분석 서비스를 추가하는 게 좋아요.
트랜잭션과 분석의 결합
두 워크로드가 모두 별도 서비스를 정당화한다면 트랜잭션 상태는 Postgres에 두고, 필요한 테이블을 ClickPipes나 WalShadow로 ClickHouse에 복제해요. 복제 지연을 고려하고, 현재 애플리케이션 상태가 필요한 결정에는 계속 트랜잭션 소스를 사용해요. 복제가 Postgres 쓰기와 ClickHouse 읽기를 하나의 트랜잭션으로 만드는 건 아니에요. pg_clickhouse 확장은 Postgres를 통해 ClickHouse에 접근할 수 있게 해줘요. 공유 쿼리 진입점이 두 서비스를 하나의 데이터베이스 엔진으로 만들어주지도, 데이터 신선도를 고려할 필요를 없애주지도 않아요.
프로비저닝 전에 적합성 확인하기
작은 대표 쿼리 세트를 적어 두고 현실적인 데이터 볼륨으로 테스트해 보세요. 좁은 조회(narrow lookup)와 이력 전체에 걸친 집계, 예상 동시 부하, 애플리케이션에 중요한 정확성 사례를 모두 포함하세요. 벤치마크 결과와 함께 스키마, 쿼리 형태, 하드웨어 또는 서비스 크기, 수집 동작을 보고해야 해요. 관리형 배포라면 다음도 확인하세요.
- 리전, 네트워킹, 접근 제어, 복구 요구 사항
- ClickHouse Cloud 청구 가이드나 Managed Postgres 가격 안내의 예상 활성 시간, 저장 데이터, 백업, 전송 비용
- 간헐적인 분석 워크로드가 자동 유휴 처리(automatic idling)와 관련된 연결 지연을 감당할 수 있는지
- 서비스가 인프라를 관리하더라도 스키마 설계, 애플리케이션 재시도, 쿼리 튜닝, 비용 관리에 대한 팀의 책임
ClickHouse Cloud의 ClickHouse 또는 Postgres 서비스에서는 ClickHouse CLI로 터미널에서 리소스를 생성·관리해요. Managed ClickStack과 chDB는 워크로드 매핑에 연결된 제품 가이드를 따르면 돼요.