コンピュート-コンピュート分離とは？
- 専用の CPU とメモリ クラスターを備えた ClickHouse のコンピュートノード (レプリカと呼ばれます)
- サービスに接続するためのエンドポイント (または ClickHouse Cloud の UI コンソールから作成された複数のエンドポイント) 。ローカル接続やサードパーティアプリからの接続に使用します (例:
https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443) - サービスがすべてのデータとメタデータの一部を保存するオブジェクトストレージ フォルダー:
図 1 - ClickHouse Cloud 内の単一サービス 単一のサービスだけでなく、同じ共有ストレージにアクセスできる複数のサービスを作成することもできます。これにより、データを複製することなく、特定のワークロードに専用のリソースを割り当てられます。 この考え方をコンピュート-コンピュート分離と呼びます。 コンピュート-コンピュート分離では、各サービスがそれぞれ独自のレプリカ群とエンドポイントを持ちながら、同じオブジェクトストレージ フォルダーを使用し、同じテーブルやビューなどにアクセスします。 つまり、ワークロードに適したサイズのコンピュートを選択できます。小規模なレプリカ 1 つで十分なワークロードもあれば、完全な高可用性 (HA) と、複数のレプリカにまたがる数百 GB のメモリを必要とするワークロードもあります。 また、コンピュート-コンピュート分離を使うことで、読み取り処理と書き込み処理を分離し、相互に干渉しないようにすることもできます。
図 2 - ClickHouse Cloud におけるコンピュート分離
ウェアハウス とは何ですか？
- プライマリ サービス
DWH Prod - セカンダリ サービス
DWH Prod Subservice
図 3 - ウェアハウス の例 ウェアハウス 内のすべてのサービスは、以下を共有します。
- Region (例: us-east1)
- クラウドサービスプロバイダー (AWS、GCP、または Azure)
- ClickHouse データベースのバージョン
- ClickHouse Keeper (レプリカの管理用)
アクセス制御
データベース認証情報
図 4 - ユーザー Alice は Service 1 で作成されましたが、同じ認証情報を使って、同じデータを共有するすべてのサービスにアクセスできます
ネットワークアクセス制御
図 5 - Alice は、ネットワークアクセス制御の設定によりサービス 2 へのアクセスを制限されています また、ユーザーが default ユーザーではなく個別のユーザーとして接続する場合は、ClickHouse のロールと権限を適用してデータへのアクセスを制御することもできます。
読み取り専用サービスと読み書きサービス
- 読み書き
- ClickHouse に対してデータの読み取りと書き込みの両方が可能
- バックグラウンドマージ操作 (例: データ挿入後のパーツのマージ) を実行するため、CPU とメモリを消費する
- データを外部にエクスポートできる
- 読み取り専用
- データの読み取りのみ可能で、ClickHouse 内のデータの書き込みや変更はできない
- システムテーブルを除きバックグラウンドマージ操作を実行しないため、リソースを読み取りクエリに全面的に使える
- 外部へのデータエクスポート (例: テーブル関数経由) は引き続き可能だが、ClickHouse 内のデータは変更できない
- バックグラウンドマージによって稼働状態が維持されることがある読み書きサービスとは異なり、すぐにアイドル状態になる
図 6 - ウェアハウス内の読み書きサービスと読み取り専用サービス
- 読み取り専用サービスは現在、ユーザー管理操作 (CREATE、DROP など) をサポートしています。
- リフレッシュ可能なマテリアライズドビュー は、ウェアハウス内の読み書き (RW) サービスでのみ実行されます。
- サービスのタイプ (読み取り専用 または 読み書き) は作成時に固定され、その後 Cloud Console から変更することはできません。読み取り専用 と 読み書き を切り替えるには、ウェアハウス内に希望するタイプの新しいサービスを作成してください。
スケーリング
- ノード数 (レプリカ数) 。プライマリサービス (ウェアハウス内で最初に作成されたサービス) は 2 ノード以上である必要があります。各セカンダリサービスは 1 ノード以上にできます。
- ノード (レプリカ) のサイズ
- サービスを自動的にスケーリングするかどうか (水平および垂直)
- 非アクティブ時にサービスをアイドル状態にするかどうか
clusterAllReplicas の動作の変更
clusterAllReplicas() の動作が変わります。
default クラスター名を使用した場合、対象になるのは ウェアハウス 内のすべての サービス ではなく、現在の サービス に属するレプリカのみです。
たとえば、サービス 1 から clusterAllReplicas(default, system, processes) を呼び出すと、返されるのは サービス 1 上で実行中のプロセスだけです。
ウェアハウス 内のすべての サービス をまたいでクエリを実行するには、代わりに all_groups.default クラスター名を使用してください。
セカンダリのシングルノードサービスは垂直スケーリングできますが、プライマリのシングルノードサービスはできません。
制限事項
ワークロード分離の制限事項
-
すべての読み書きサービスは、デフォルトでバックグラウンドマージ処理を実行します。 ClickHouse にデータを挿入すると、データベースはまずデータを一時的なパーティションに書き込み、その後バックグラウンドでマージを実行します。これらのマージは、メモリや CPU リソースを消費することがあります。2 つの読み書きサービスが同じストレージを共有している場合、両方のサービスでバックグラウンド処理が実行されます。つまり、Service 1 で
INSERTクエリが実行されても、そのマージ処理自体は Service 2 で完了することがあります。 読み取り専用サービスはバックグラウンドマージを実行しないため、この処理にリソースを消費しない点に注意してください。なお、サポートではサービス上のマージを無効にすることもできます。 - すべての読み書きサービスで S3Queue テーブルエンジンの insert 操作が実行されます。 読み書きサービス上に S3Queue テーブルを作成すると、そのウェアハウス内の他のすべての読み書きサービスでも、S3 からのデータの読み取りとデータベースへの書き込みが実行される場合があります。
- idling が有効な場合、ある読み書きサービスでの inserts によって、別の読み書きサービスがアイドル状態に移行できなくなることがあります。 あるサービスが、別のサービスのためにバックグラウンドマージ処理を実行する場合があります。こうしたバックグラウンド処理によって、後者のサービスがアイドル状態に移行できなくなることがあります。バックグラウンド処理が完了すると、そのサービスはアイドル状態になります。読み取り専用サービスは影響を受けません。
参考情報
- ClickHouse のバージョン: アップグレードスケジュールは、プライマリサービスの設定によって決まります。セカンダリサービスに、プライマリサービスとは独立したリリーススケジュールを設定することはできません。
-
CREATE/RENAME/DROP DATABASEクエリは、デフォルトでアイドル化または停止中のサービスによってブロックされることがあります。 サービスがアイドル化または停止中のときにこれらのクエリを実行すると、処理がハングする場合があります。これを回避するには、セッション単位またはクエリ単位でsettings distributed_ddl_task_timeout=0を指定して、データベース管理クエリを実行できます。
- 単一レプリカのプライマリサービス 現在のデフォルト動作では、セカンダリサービスはレプリカを 1 つにできますが、プライマリサービスには少なくとも 2 つのレプリカが必要です。 単一レプリカのプライマリサービスを有効にするには、サポートにお問い合わせください。この動作は 2026 年第 2 四半期にデフォルトで有効になる予定です。
- プライマリサービスのアイドル化: プライマリサービスの自動アイドル化はデフォルトで有効になっています。
料金
バックアップ
- 1 つの ウェアハウス 内のすべての サービス は同じストレージを共有するため、バックアップはプライマリ (初期) サービス でのみ作成されます。これにより、ウェアハウス 内のすべての サービス のデータがバックアップされます。
- ウェアハウス のプライマリ サービス からバックアップを復元すると、既存の ウェアハウス には接続されていない、まったく新しい サービス として復元されます。復元が完了したらすぐに、その新しい サービス にさらに サービス を追加できます。
ウェアハウス の設定方法
ウェアハウスの作成
図 7 - プラス記号をクリックして、ウェアハウス内に新しいサービスを作成します サービス作成画面では、新しいサービスのデータ元として、元のサービスがドロップダウンで選択された状態になります。作成後、これら 2 つのサービスで 1 つのウェアハウスが構成されます。
ウェアハウス名の変更
- services ページの右上にある「Sort by warehouse」を選択し、ウェアハウス名の横にある鉛筆アイコンをクリックします
- いずれかのサービスでウェアハウス名をクリックし、そこで名前を変更できます
ウェアハウスの削除
- 最初に作成したサービス以外の、すべてのサービスを削除します。
- 最初のサービスを削除します (警告: この手順ですべてのウェアハウスデータが削除されます) 。