ワークロードを始点に対応付ける
現在の提供状況、リージョン、制限事項については、リンク先の製品ドキュメントを確認してください。ClickHouse Managed Postgres は現在パブリックベータです。クイックスタートを参照してください。
セルフマネージドの ClickHouse サーバーやその他のローカル環境の選択肢については、デプロイメントモードを参照してください。
例: レポート結果と実行履歴
アップロードされたファイルを処理してレポートを生成し、クエリ可能な結果と実行履歴を保持する必要があるアプリケーションを考えてみましょう。データベースを選定する前に、結果行と実行記録を区別しておきます。- 結果: クエリは1つのレポートについて数行を取得するのか、それとも多数のレポート、データセット、時間範囲にまたがって集計するのか。数億行に達すると見込まれるのはどのテーブルか。
- 実行記録: 実行完了時に不変の記録が1件書き込まれるだけか、それともアプリケーション側で実行中のジョブの所有権やステータス遷移を調整する必要があるのか。
- 正確性: 複数の記録を1つのトランザクションで変更する必要があるか。データベース側で一意性を強制したり、2つのワーカーが同じジョブを取得するのを防いだりする必要があるか。
- 鮮度: 書き込みの成功はどれだけ早く参照可能になる必要があるか。また、クエリは不完全または遅延した分析用コピーを許容できるか。
完了した実行と分析結果
主要なワークロードが結果行を横断する分析であり、実行記録を完了時に追記できる場合、ClickHouse Cloud の ClickHouse サービスが候補になります。小規模なメタデータテーブルがあるというだけでは、2 つ目のデータベースを用意する理由にはなりません。 完了した実行と、部分的にしか取り込まれていない実行とを読み手がどのように区別するかを設計し、テストしてください。安定した実行識別子、再試行の挙動、重複する結果行の扱いを定義します。結果テーブルへの挿入と実行履歴テーブルへの挿入は別々の操作であり、単一のテーブル横断トランザクションとして扱ってはなりません。 実行記録を複数バージョン保存する場合は、クエリが現在のバージョンをどのように選択するかを定義してください。ReplacingMergeTree はFINAL によるクエリ時の重複排除をサポートしますが、正しさが background merges の完了に依存するような設計にしてはなりません。update リファレンス では、別の更新メカニズムとその制限について説明しています。いずれのパターンについても、PostgreSQL のようなトランザクション保証が得られると想定すべきではありません。
トランザクショナルなジョブ状態
実行テーブルがトランザクショナルな作業キューや記録の正本(system of record)を兼ねている場合は、ClickHouse Managed Postgres の採用を検討してください。たとえば、複数の worker が同じジョブを奪い合う中で 1 つの worker がアトミックにジョブを取得(claim)する必要がある場合や、複数のアプリケーションレコードを制約を効かせたまま一括で変更する必要がある場合です。 Postgres はレポート用のクエリにも対応できます。分析用の service は、代表的なクエリパフォーマンス、同時実行性、分離性の要件から見て必要だと判断できる場合に追加すればよく、すべてのレポートアプリケーションに 2 つの database が必要だと決めつける必要はありません。トランザクションと分析を組み合わせる
両方のワークロードに別々のサービスを用意する妥当性がある場合は、トランザクションの状態はPostgresに保持し、必要なテーブルをClickPipesまたはWalShadowでClickHouseへレプリケートします。レプリケーションラグを考慮し、最新のアプリケーション状態を必要とする判断には引き続きトランザクション側のソースを使用してください。レプリケーションを行っても、Postgresへの書き込みとClickHouseからの読み取りが1つのトランザクションとして扱われるようになるわけではありません。 pg_clickhouse拡張機能を使うと、Postgres経由でClickHouseへアクセスできます。ただし、クエリのエントリポイントを共通化しても、2つのサービスが1つのデータベースエンジンになるわけではなく、データの鮮度を考慮する必要がなくなるわけでもありません。プロビジョニング前に適合性を確認する
代表的なクエリを少数書き出し、現実的なデータ量に対してテストしてください。絞り込まれたルックアップだけでなく、履歴全体にまたがる集計、想定される同時実行負荷、アプリケーションにとって重要となる正確性の検証ケースも含めます。ベンチマーク結果を報告する際は、スキーマ、クエリの形状、ハードウェアまたはサービスのサイズ、インジェストの挙動を併せて記載してください。 マネージドデプロイメントの場合は、次の点も確認してください。- リージョン、ネットワーク、アクセス制御、復旧に関する要件。
- 想定されるアクティブ時間、保存データ量、バックアップ、転送料金 (ClickHouse Cloud 課金ガイド または Managed Postgres 料金ガイドを参照) 。
- 断続的に発生する分析ワークロードが、自動アイドル化に伴う接続遅延を許容できるかどうか。
- サービス側がインフラストラクチャを管理する場合であっても、スキーマ設計、アプリケーション側の再試行、クエリチューニング、コスト管理はチームの責任であること。