워크로드에 맞는 시작점 찾기
현재 제공 여부, 리전, 제한 사항은 링크된 제품 문서를 확인하십시오. ClickHouse Managed Postgres는 현재 퍼블릭 베타 단계이며, 빠른 시작을 참조하십시오.
자가 관리형 ClickHouse 서버나 기타 로컬 옵션은 배포 모드를 참조하십시오.
예시: 리포트 결과 및 실행 이력
애플리케이션이 업로드된 파일을 처리해 리포트를 생성하고, 쿼리 가능한 결과와 실행 이력을 보관해야 하는 상황을 가정해 보겠습니다. 데이터베이스를 선택하기 전에 결과 행과 실행 기록을 구분해야 합니다:- 결과: 쿼리가 하나의 리포트에서 몇 개의 행만 조회합니까, 아니면 여러 리포트와 데이터셋, 여러 시간 범위에 걸쳐 집계합니까? 수억 행에 도달할 것으로 예상되는 테이블은 무엇입니까?
- 실행 기록: 실행이 완료될 때 변경 불가능한 기록 하나만 기록됩니까, 아니면 애플리케이션이 진행 중인 job의 소유권과 status 전이를 조율해야 합니까?
- 정확성: 여러 기록이 하나의 트랜잭션 안에서 함께 변경되어야 합니까? 데이터베이스가 고유성을 보장하거나 두 worker가 동일한 job을 동시에 점유하지 못하도록 막아야 합니까?
- 최신성: 성공한 쓰기가 얼마나 빨리 조회 가능해야 합니까? 또한 쿼리가 불완전하거나 지연된 분석용 복사본을 허용할 수 있습니까?
완료된 실행과 분석 결과
주된 워크로드가 결과 행 전반에 대한 분석이고 실행 기록을 완료 시점에 추가할 수 있다면, ClickHouse Cloud의 ClickHouse 서비스가 후보가 됩니다. 작은 메타데이터 테이블이 있다는 사실만으로 두 번째 데이터베이스가 필요해지지는 않습니다. 완료된 실행과 일부만 수집된 실행을 사용자가 어떻게 구분할지 설계하고 테스트하십시오. 안정적인 실행 식별자, 재시도 동작, 중복 결과 행의 처리 방식을 정의하십시오. 결과 테이블과 실행 이력 테이블에 각각 수행되는 삽입을 하나의 테이블 간 트랜잭션으로 취급해서는 안 됩니다. 실행 기록을 여러 버전으로 저장한다면, 쿼리가 현재 버전을 선택하는 방식을 정의하십시오. ReplacingMergeTree는FINAL을 사용한 쿼리 시점 중복 제거를 지원하지만, 백그라운드 머지가 이미 수행되었다는 전제에 정확성이 의존해서는 안 됩니다. update 참고 문서는 또 다른 UPDATE 메커니즘과 그 제약을 설명합니다. 두 방식 모두 PostgreSQL과 같은 트랜잭션 보장을 제공한다고 가정해서는 안 됩니다.
트랜잭션 작업 상태
실행 테이블이 트랜잭션 작업 큐나 기록 시스템(system of record) 역할을 겸한다면 ClickHouse Managed Postgres를 검토하십시오. 예를 들어 여러 worker가 서로 경쟁하는 상황에서 하나의 worker가 job을 원자적으로 선점해야 하거나, 여러 애플리케이션 레코드가 제약 조건(constraints)을 지키면서 함께 변경되어야 하는 경우입니다. Postgres는 리포팅 쿼리도 처리할 수 있습니다. 모든 리포팅 애플리케이션에 데이터베이스가 두 개 필요하다고 단정하지 마시고, 실제 워크로드의 쿼리 성능, 동시성 또는 격리 요구사항이 이를 정당화할 때 분석용 서비스를 추가하십시오.트랜잭션과 분석을 함께 사용하기
두 워크로드가 각각 별도의 서비스를 둘 만한 이유가 있다면, 트랜잭션 상태는 Postgres에 유지하고 필요한 테이블만 ClickPipes 또는 WalShadow로 ClickHouse에 복제하십시오. 이때 복제 지연(replication lag)을 감안해야 하며, 최신 애플리케이션 상태가 필요한 판단에는 계속 트랜잭션 원본을 사용하십시오. 복제한다고 해서 Postgres 쓰기와 ClickHouse 읽기가 하나의 트랜잭션으로 묶이지는 않습니다. pg_clickhouse 확장 기능을 사용하면 Postgres를 통해 ClickHouse에 액세스할 수 있습니다. 다만 쿼리 진입점을 공유한다고 해서 두 서비스가 하나의 데이터베이스 엔진이 되는 것은 아니며, 데이터 신선도를 고려해야 할 필요가 사라지는 것도 아닙니다.프로비저닝 전 적합성 확인
대표적인 쿼리를 몇 가지 정리한 뒤 실제와 유사한 데이터 규모를 대상으로 테스트하십시오. 좁은 범위의 조회는 물론 전체 이력에 걸친 집계, 예상되는 동시 부하, 애플리케이션에서 중요한 정확성 검증 사례까지 포함하십시오. 벤치마크 결과를 보고할 때는 스키마, 쿼리 형태, 하드웨어 또는 서비스 규모, 수집 동작을 함께 기록하십시오. 관리형 배포라면 다음 항목도 확인하십시오:- Region, 네트워킹, 액세스 제어, 복구 요구 사항.
- ClickHouse Cloud 청구 가이드 또는 Managed Postgres 가격 가이드에서 예상 활성 시간, 저장 데이터, Backup, 전송 요금.
- 간헐적으로 실행되는 분석 워크로드가 자동 유휴 상태 전환으로 인한 연결 지연을 감내할 수 있는지 여부.
- 서비스가 인프라를 관리하더라도 스키마 설계, 애플리케이션 재시도 처리, 쿼리 튜닝, 비용 관리는 팀의 책임이라는 점.