> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 워크로드에 맞는 서비스 선택

> 분석 또는 트랜잭션 처리에는 ClickHouse Cloud의 ClickHouse 또는 Postgres 서비스를, 관측성에는 Managed ClickStack을, 로컬 분석에는 chDB를 선택하십시오.

애플리케이션이 지원해야 하는 쿼리와 정확성 요구 사항에서 출발하십시오. 행 수가 많다는 사실만으로 데이터베이스가 결정되지는 않으며, 리포트를 생성하는 애플리케이션에도 분석 워크로드와 트랜잭션 워크로드가 함께 존재할 수 있습니다.

ClickHouse Cloud는 분석용 ClickHouse와 트랜잭션 워크로드용 ClickHouse Managed Postgres를 비롯한 관리형 서비스를 제공하는 플랫폼입니다. 두 서비스는 각각 ClickHouse와 PostgreSQL이라는 서로 다른 데이터베이스 엔진에서 실행되며, SQL 동작 방식도 다릅니다. 각 서비스를 독립적으로 사용할 수도 있고, ClickHouse Cloud 내에서 함께 사용할 수도 있습니다.

<h2 id="workload-map">
  워크로드에 맞는 시작점 찾기
</h2>

| 애플리케이션에 필요한 것 | 먼저 검토할 대상 | 선택 전에 확인할 사항 |
| - | - | - |
| 대규모 이벤트 또는 결과 이력에 대한 집계, 필터링, 비교 | [ClickHouse Cloud의 ClickHouse 서비스](/ko/products/cloud/getting-started/intro) | 대표 쿼리, 수집 배치, 데이터 신선도, 동시 쿼리, 업데이트 및 재시도 설계 |
| 주문, 재고 예약, 상태 전이에 트랜잭션과 제약 조건이 필요한 작업처럼 트랜잭션 기반 애플리케이션 상태 | [ClickHouse Cloud의 ClickHouse Managed Postgres](/ko/products/managed-postgres/overview) | 트랜잭션 경계, 제약 조건, 인덱스, 커넥션 관리, 해당 서비스가 지원하는 기능과 가용성 |
| 트랜잭션 기반 애플리케이션 상태와 더불어 독립적인 서빙 시스템이 필요한 분석 쿼리 | [ClickHouse Cloud의 Postgres 및 ClickHouse 서비스](/ko/products/managed-postgres/sync-to-clickhouse/clickpipes) | 복제가 필요한 테이블, 허용 가능한 복제 지연, 스키마 변경, 두 서비스의 비용과 운영 |
| 애플리케이션 로그, 메트릭, 트레이스를 검색하고 분석하기 위한 관리형 환경 | [Managed ClickStack](/ko/clickstack/getting-started/managed) | 계측, 텔레메트리 수집, 보존 기간, 팀에 필요한 관측성 워크플로 |
| 로컬 애플리케이션이나 노트북 내 파일 또는 인메모리 데이터 분석 | [chDB](/ko/chdb/index) | 로컬 리소스, 별도로 호스팅되는 공유 데이터베이스 서비스의 필요 여부 |

현재 제공 여부, 리전, 제한 사항은 링크된 제품 문서를 확인하십시오. ClickHouse Managed Postgres는 현재 퍼블릭 베타 단계이며, [빠른 시작](/ko/products/managed-postgres/quickstart)을 참조하십시오.

자가 관리형 ClickHouse 서버나 기타 로컬 옵션은 [배포 모드](/ko/get-started/about/deployment-modes)를 참조하십시오.

<h2 id="report-results-and-history">
  예시: 리포트 결과 및 실행 이력
</h2>

애플리케이션이 업로드된 파일을 처리해 리포트를 생성하고, 쿼리 가능한 결과와 실행 이력을 보관해야 하는 상황을 가정해 보겠습니다. 데이터베이스를 선택하기 전에 결과 행과 실행 기록을 구분해야 합니다:

* **결과:** 쿼리가 하나의 리포트에서 몇 개의 행만 조회합니까, 아니면 여러 리포트와 데이터셋, 여러 시간 범위에 걸쳐 집계합니까? 수억 행에 도달할 것으로 예상되는 테이블은 무엇입니까?
* **실행 기록:** 실행이 완료될 때 변경 불가능한 기록 하나만 기록됩니까, 아니면 애플리케이션이 진행 중인 job의 소유권과 status 전이를 조율해야 합니까?
* **정확성:** 여러 기록이 하나의 트랜잭션 안에서 함께 변경되어야 합니까? 데이터베이스가 고유성을 보장하거나 두 worker가 동일한 job을 동시에 점유하지 못하도록 막아야 합니까?
* **최신성:** 성공한 쓰기가 얼마나 빨리 조회 가능해야 합니까? 또한 쿼리가 불완전하거나 지연된 분석용 복사본을 허용할 수 있습니까?

<h3 id="completed-runs">
  완료된 실행과 분석 결과
</h3>

주된 워크로드가 결과 행 전반에 대한 분석이고 실행 기록을 완료 시점에 추가할 수 있다면, ClickHouse Cloud의 ClickHouse 서비스가 후보가 됩니다. 작은 메타데이터 테이블이 있다는 사실만으로 두 번째 데이터베이스가 필요해지지는 않습니다.

완료된 실행과 일부만 수집된 실행을 사용자가 어떻게 구분할지 설계하고 테스트하십시오. 안정적인 실행 식별자, 재시도 동작, 중복 결과 행의 처리 방식을 정의하십시오. 결과 테이블과 실행 이력 테이블에 각각 수행되는 삽입을 하나의 테이블 간 트랜잭션으로 취급해서는 안 됩니다.

실행 기록을 여러 버전으로 저장한다면, 쿼리가 현재 버전을 선택하는 방식을 정의하십시오. [ReplacingMergeTree](/ko/reference/engines/table-engines/mergetree-family/replacingmergetree)는 `FINAL`을 사용한 쿼리 시점 중복 제거를 지원하지만, 백그라운드 머지가 이미 수행되었다는 전제에 정확성이 의존해서는 안 됩니다. [update 참고 문서](/ko/reference/statements/update)는 또 다른 UPDATE 메커니즘과 그 제약을 설명합니다. 두 방식 모두 PostgreSQL과 같은 트랜잭션 보장을 제공한다고 가정해서는 안 됩니다.

<h3 id="transactional-job-state">
  트랜잭션 작업 상태
</h3>

실행 테이블이 트랜잭션 작업 큐나 기록 시스템(system of record) 역할을 겸한다면 ClickHouse Managed Postgres를 검토하십시오. 예를 들어 여러 worker가 서로 경쟁하는 상황에서 하나의 worker가 job을 원자적으로 선점해야 하거나, 여러 애플리케이션 레코드가 제약 조건(constraints)을 지키면서 함께 변경되어야 하는 경우입니다.

Postgres는 리포팅 쿼리도 처리할 수 있습니다. 모든 리포팅 애플리케이션에 데이터베이스가 두 개 필요하다고 단정하지 마시고, 실제 워크로드의 쿼리 성능, 동시성 또는 격리 요구사항이 이를 정당화할 때 분석용 서비스를 추가하십시오.

<h3 id="transactions-and-analytics">
  트랜잭션과 분석을 함께 사용하기
</h3>

두 워크로드가 각각 별도의 서비스를 둘 만한 이유가 있다면, 트랜잭션 상태는 Postgres에 유지하고 필요한 테이블만 [ClickPipes](/ko/products/managed-postgres/sync-to-clickhouse/clickpipes) 또는 [WalShadow](/ko/products/managed-postgres/sync-to-clickhouse/walshadow)로 ClickHouse에 복제하십시오. 이때 복제 지연(replication lag)을 감안해야 하며, 최신 애플리케이션 상태가 필요한 판단에는 계속 트랜잭션 원본을 사용하십시오. 복제한다고 해서 Postgres 쓰기와 ClickHouse 읽기가 하나의 트랜잭션으로 묶이지는 않습니다.

[pg\_clickhouse 확장 기능](/ko/products/managed-postgres/extensions/pg_clickhouse/introduction)을 사용하면 Postgres를 통해 ClickHouse에 액세스할 수 있습니다. 다만 쿼리 진입점을 공유한다고 해서 두 서비스가 하나의 데이터베이스 엔진이 되는 것은 아니며, 데이터 신선도를 고려해야 할 필요가 사라지는 것도 아닙니다.

<h2 id="check-fit">
  프로비저닝 전 적합성 확인
</h2>

대표적인 쿼리를 몇 가지 정리한 뒤 실제와 유사한 데이터 규모를 대상으로 테스트하십시오. 좁은 범위의 조회는 물론 전체 이력에 걸친 집계, 예상되는 동시 부하, 애플리케이션에서 중요한 정확성 검증 사례까지 포함하십시오. 벤치마크 결과를 보고할 때는 스키마, 쿼리 형태, 하드웨어 또는 서비스 규모, 수집 동작을 함께 기록하십시오.

관리형 배포라면 다음 항목도 확인하십시오:

* Region, 네트워킹, 액세스 제어, 복구 요구 사항.
* [ClickHouse Cloud 청구 가이드](/ko/products/cloud/reference/billing/billing-overview) 또는 [Managed Postgres 가격 가이드](/ko/products/managed-postgres/pricing)에서 예상 활성 시간, 저장 데이터, Backup, 전송 요금.
* 간헐적으로 실행되는 분석 워크로드가 [자동 유휴 상태 전환](/ko/products/cloud/features/autoscaling/idling)으로 인한 연결 지연을 감내할 수 있는지 여부.
* 서비스가 인프라를 관리하더라도 스키마 설계, 애플리케이션 재시도 처리, 쿼리 튜닝, 비용 관리는 팀의 책임이라는 점.

ClickHouse Cloud의 ClickHouse 또는 Postgres 서비스는 [ClickHouse CLI](/ko/products/cloud/features/cli)를 사용해 터미널에서 리소스를 생성하고 관리하십시오. Managed ClickStack과 chdb는 워크로드 맵에 연결된 제품 가이드를 참고하십시오.