ウェアハウス

Scale plan feature

Compute-compute separation is available in the Scale and Enterprise plans. To upgrade, visit the plans page in the cloud console.

コンピュート-コンピュート分離とは何ですか？

コンピュート-コンピュート分離について説明する前に、ClickHouse Cloud における サービス とは何かを理解しておくと役立ちます。

各 ClickHouse Cloud サービスには、次のものが含まれます。

• 専用の CPU およびメモリクラスタを持つ ClickHouse の compute ノード (レプリカ と呼ばれます)
• サービスに接続するためのエンドポイント (または ClickHouse Cloud UI コンソール経由で作成される複数のエンドポイント) 。ローカル接続やサードパーティ製アプリケーションからの接続に使用します (例: https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443)
• サービスがすべてのデータとメタデータの一部を保存するオブジェクトストレージ内のフォルダ:

図 1 - ClickHouse Cloud 内の単一サービス

単一のサービスではなく、同じ共有ストレージにアクセスできる複数のサービスを作成することもできます。これにより、データを複製することなく、特定のワークロード専用にリソースを割り当てることができます。 この概念を コンピュート-コンピュート分離 と呼びます。

コンピュート-コンピュート分離では、各サービスはそれぞれ独自のレプリカ群とエンドポイントを持ちながら、同じオブジェクトストレージ内のフォルダを使用し、同じテーブルやビューなどにアクセスします。 つまり、ワークロードに適したサイズの compute を選択できます。小さなサイズのレプリカ 1 つで十分なワークロードもあれば、完全な高可用性 (HA) や、複数のレプリカにまたがる数百 GB のメモリを必要とするワークロードもあります。

コンピュート-コンピュート分離では、読み取り操作と書き込み操作を分離し、互いに干渉しないようにすることもできます。

図 2 - ClickHouse Cloud におけるコンピュート分離

ウェアハウスとは何ですか？

ClickHouse Cloud において、ウェアハウス は同じデータを共有するサービスの集合です。 各ウェアハウスには、プライマリサービス (最初に作成されたサービス) と 1 つ以上のセカンダリサービスが存在します。 たとえば、以下のスクリーンショットでは、2 つのサービスで構成されるウェアハウス "DWH Prod" が表示されています。

• プライマリサービス DWH Prod
• セカンダリサービス DWH Prod Subservice

図 3 - ウェアハウスの例

ウェアハウス内のすべてのサービスは、次の項目を共有しています。

• リージョン (例: us-east1)
• クラウドサービスプロバイダー (AWS、GCP、または Azure)
• ClickHouse データベースのバージョン
• ClickHouse Keeper (レプリカを管理するため)

アクセス制御

データベース認証情報

同じウェアハウス内のすべてのサービスは同じテーブルセットを共有しているため、サービス間のアクセス制御も共有されます。これは、Service 1 で作成されたすべてのデータベースユーザーは、同じ権限 (テーブルやビューへの GRANT など) で Service 2 も利用でき、その逆も成り立つことを意味します。サービスごとに異なるエンドポイントを使用しますが、すべてのサービスで同じユーザー名とパスワードを使用します。言い換えると、以下の図に示すように、同じストレージを利用するサービス間でユーザーは共有されます。

図 4 - ユーザー Alice は Service 1 で作成されたが、同じ認証情報を使って同じデータを共有するすべてのサービスにアクセスできる

ネットワークアクセス制御

他のアプリケーションやアドホックユーザーによる特定のサービスへのアクセスを制限するには、ネットワーク制限を適用できます。 そのためには、ClickHouse Cloudコンソールで、アクセスを制限したいサービスのサービスタブにある設定に移動します。

IPフィルタリング設定はサービスごとに個別に適用できるため、どのアプリケーションがどのサービスにアクセスできるかを制御できます。 これにより、ユーザーが特定のサービスを利用できないように制限できます。

以下の例では、Alice はウェアハウス内のサービス 2 へのアクセスを制限されています。

図 5 - ネットワークアクセス制御設定により、Alice はサービス 2 へのアクセスを制限されています

ClickHouse のロールと権限付与を使用して、ユーザーが default ユーザーではなく個別のユーザーとして接続する場合のデータアクセスを制御することもできます。

read-write サービスと read-only サービス

サービスは次のいずれかになります。

• read-write
  • ClickHouse に対してデータの読み取りと書き込みの両方が可能です
  • バックグラウンドのマージ処理 (例: データ insert 後のパーツのマージ) を実行するため、CPU とメモリを消費します
  • データを外部にエクスポートできます
• read-only
  • データの読み取りのみ可能で、ClickHouse 内のデータの書き込みや変更はできません
  • バックグラウンドのマージ処理を実行しないため、リソースをすべて読み取りクエリに割り当てられます
  • データを外部にエクスポートすることも可能です (例: table function 経由) 。ただし、ClickHouse 内のデータは変更できません
  • バックグラウンドマージによって稼働状態が維持されることがある read-write サービスとは異なり、遅延なくアイドル状態になります

重要な読み取りワークロードを、サービスを read-only にすることで、書き込みやマージのオーバーヘッドから分離したい場合があります。 これは 2 つ目のサービスと、追加で作成するすべてのサービスに対して設定できます。ただし、最初のサービスは常に read-write です。以下の図を参照してください。

図 6 - ウェアハウス内の read-write サービスと read-only サービス

注記

1. 現在、read-only サービスはユーザー管理操作 (CREATE、DROP など) をサポートしています。
2. リフレッシャブルmaterialized view は、ウェアハウス内の read-write (RW) サービスでのみ実行されます。

スケーリング

ウェアハウス内の各サービスは、ワークロードに応じて次の点を調整できます：

• ノード数 (レプリカ数) 。プライマリサービス (ウェアハウス内で最初に作成されたサービス) は 2 つ以上のノードが必要です。各セカンダリサービスは 1 つ以上のノードを持つことができます。
• ノード (レプリカ) のサイズ
• サービスを自動スケーリングするかどうか (水平および垂直)
• サービスを非アクティブ時にアイドル状態にするかどうか

詳細については、"Autoscaling" ページを参照してください。

clusterAllReplicas の動作変更

ウェアハウスに複数のサービスがある場合、clusterAllReplicas() の動作が変わります。 default クラスタ名を使用すると、ウェアハウス内のすべてのサービスではなく、現在のサービス内のレプリカのみが対象になります。

たとえば、service 1 から clusterAllReplicas(default, system, processes) を呼び出した場合、返されるのは service 1 で実行中のプロセスのみです。 ウェアハウス内のすべてのサービスに対してクエリを実行するには、代わりに all_groups.default クラスタ名を使用します:

SELECT * FROM clusterAllReplicas('all_groups.default', system, processes)

注記

セカンダリのシングルノードサービスは垂直スケーリングできますが、プライマリのシングルノードサービスはできません。

制限事項

ワークロード分離の制限事項

一部のワークロードは特定のサービスに分離できません。あるサービスの 1 つのワークロードが、ウェアハウス内の別のサービスに影響を与えるエッジケースがあります。以下が含まれます。

• すべての読み書きサービスはデフォルトでバックグラウンドのマージ処理を実行します。 ClickHouse にデータを挿入する際、データベースはまず一部のステージングパーティションにデータを挿入し、その後バックグラウンドでマージ処理を実行します。これらのマージ処理はメモリと CPU リソースを消費します。2 つの読み書きサービスが同じストレージを共有している場合、両方がバックグラウンド処理を実行します。つまり、Service 1 で INSERT クエリが実行されているが、マージ処理は Service 2 によって完了するといった状況が発生し得ます。なお、読み取り専用サービスはバックグラウンドマージを実行しないため、この処理にリソースを消費しません。サポートは、サービス上のマージを無効にすることができます。

• すべての読み書きサービスは S3Queue テーブルエンジンの挿入処理を実行します。 読み書きサービス上で S3Queue テーブルを作成すると、ウェアハウス上の他のすべての読み書きサービスが、S3 からデータを読み取りデータベースに書き込む処理を実行する場合があります。

• 1 つの読み書きサービスでの挿入が、アイドル化が有効な場合に別の読み書きサービスのアイドル化を妨げる可能性があります。 次のような状況があります あるサービスが別のサービスのためにバックグラウンドマージ処理を実行することがあります。これらのバックグラウンド処理によって、2 番目のサービスがアイドル状態になるのを妨げられることがあります。バックグラウンド処理が完了すると、そのサービスはアイドル状態になります。読み取り専用サービスは影響を受けません。

参考情報

• デフォルトでは、CREATE/RENAME/DROP DATABASE クエリは、アイドル状態または停止中のサービスによってブロックされる可能性があります。 サービスがアイドル状態または停止中のときにこれらのクエリを実行すると、処理がハングすることがあります。これを回避するには、データベース管理クエリをセッション単位またはクエリ単位で settings distributed_ddl_task_timeout=0 を指定して実行します。

例:

CREATE DATABASE db_test_ddl_single_query_setting
SETTINGS distributed_ddl_task_timeout=0

サービスを手動で停止した場合、クエリを実行するには、再度起動する必要があります。

• 現在、1つのウェアハウスあたりのサービス数のソフト上限は5です。 1つのウェアハウスで5つを超えるサービスが必要な場合は、サポートチームにお問い合わせください。
• プライマリサービスを1レプリカのみにすることはできません セカンダリサービスは1レプリカでも構いませんが、プライマリサービスは少なくとも2レプリカ必要です。
• プライマリサービスのアイドル化 現在、デフォルトの動作では、プライマリサービスは自動アイドル化できません。これは、セカンダリサービスが作成されると無効になります。これを有効にするには、サポートに連絡して親サービスのアイドル化を有効にしてください。親サービスの自動アイドル化は2026年第2四半期にデフォルトで有効になる予定です (既存のサービスでもこの機能を利用でき、新しいサービスではデフォルトで有効になります) 。

料金

コンピュート料金は、ウェアハウス内のすべてのサービス (プライマリおよびセカンダリ) で同一です。ストレージ料金は最初の (元の) サービスに含まれており、1 回だけ請求されます。

ワークロードの規模や選択したティアに基づいてコストを見積もるには、料金 ページにある料金計算ツールを参照してください。Usage Breakdown テーブルには、各サービスのコンピュートコストの内訳が表示されます。

バックアップ

• 単一のウェアハウス内のすべてのサービスは同じストレージを共有するため、バックアップはプライマリ（最初の）サービスに対してのみ実行されます。このため、そのウェアハウス内のすべてのサービスのデータがバックアップされます。
• ウェアハウスのプライマリサービスのバックアップからリストアを行うと、そのバックアップは既存のウェアハウスとは関連付けられていない、完全に新しいサービスとしてリストアされます。リストアが完了した直後に、その新しいサービスに対して追加のサービスを作成できます。

ウェアハウスの設定方法

ウェアハウスの作成

ウェアハウスを作成するには、既存のサービスとデータを共有する 2 つ目のサービスを作成する必要があります。これは、既存のいずれかのサービスでプラス記号 (＋) をクリックすることで行えます。

図 7 - プラス記号をクリックしてウェアハウス内に新しいサービスを作成します

サービス作成画面では、新しいサービスのデータソースとして、元のサービスがドロップダウンであらかじめ選択されています。作成が完了すると、これら 2 つのサービスが 1 つのウェアハウスを構成します。

ウェアハウス名の変更

ウェアハウス名を変更する方法は 2 つあります。

• サービスページの右上で「Sort by warehouse」を選択し、ウェアハウス名の横にある鉛筆アイコンをクリックする
• いずれかのサービスのウェアハウス名をクリックし、その画面でウェアハウス名を変更する

ウェアハウスの削除

ウェアハウスを削除すると、すべてのコンピュートサービスとデータ（テーブル、ビュー、ユーザーなど）が削除されます。この操作は元に戻せません。 ウェアハウスは、最初に作成されたサービスを削除することでのみ削除できます。次の手順で実行します。

1. 最初に作成されたサービス以外に、追加で作成されたすべてのサービスを削除します。
2. 最初のサービスを削除します（警告: この手順でウェアハウスのすべてのデータが削除されます）。