ウェアハウス

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

コンピュートコンピュート分離は、Scale および Enterprise ティアで利用できます。

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

• 2 つ以上の ClickHouse ノード（またはレプリカ）のグループが必須ですが、子サービスは単一レプリカ構成でもかまいません。
• エンドポイント（または ClickHouse Cloud UI コンソールから作成された複数のエンドポイント）。これはサービスへ接続する際に使用するサービス URL です（例: https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443）。
• サービスがすべてのデータおよび一部のメタデータを保存する、オブジェクトストレージ上のフォルダ。

注記

単一の親サービスとは異なり、単一の子サービスは垂直方向にスケール可能です。

図 1 - ClickHouse Cloud における現在のサービス

コンピュートコンピュート分離により、同一のオブジェクトストレージフォルダ（したがって同じテーブルやビューなど）を共有しつつ、それぞれに専用のエンドポイントを持つ複数のコンピュートノードグループを作成できます。

各コンピュートノードグループには専用のエンドポイントが割り当てられるため、ワークロードに使用するレプリカのセットを選択できます。ワークロードによっては、小さいレプリカ 1 台で十分な場合もあれば、フルの高可用性 (HA) と数百 GB のメモリが必要な場合もあります。コンピュートコンピュート分離により、読み取り処理と書き込み処理を分離し、互いに干渉しないようにすることも可能です。

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

既存のサービスと同じデータを共有する追加のサービスを作成したり、複数のサービスが同じデータを共有する、まったく新しいセットアップを構成したりすることが可能です。

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

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

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

図 3 - ウェアハウスの例

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

• リージョン（例: us-east1）
• クラウドサービスプロバイダー（AWS、GCP、または Azure）
• ClickHouse データベースバージョン

サービスは、所属するウェアハウスごとに並べ替えることができます。

アクセス制御

データベース認証情報

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

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

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

特定のサービスが他のアプリケーションやアドホックなユーザーから利用されないように制限したい場合があります。これはネットワーク制限を使用することで実現でき、通常のサービスと同様の方法で設定します（ClickHouse Cloud コンソール内の対象サービスのタブで Settings に移動します）。

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

図 5 - ネットワーク設定により、Alice は Service 2 にアクセスできない

読み取り専用と読み書き

特定のサービスへの書き込みアクセスを制限し、ウェアハウス内の一部のサービスからのみ書き込みできるようにしたい場合があります。これは、2 つ目以降のサービスを作成する際に設定できます（最初のサービスは常に読み書き可能にする必要があります）。

図 6 - ウェアハウス内の読み書き可能サービスと読み取り専用サービス

注記

1. 読み取り専用サービスでも現在はユーザー管理操作（create、drop など）が可能です。この動作は将来変更される可能性があります。
2. 現在、更新可能なマテリアライズドビューは、読み取り専用サービスを含むウェアハウス内のすべてのサービス上で実行されます。ただし、この動作は将来変更され、読み書き可能（Read-write）サービス上でのみ実行されるようになります。

スケーリング

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

• ノード数（レプリカ数）。プライマリサービス（ウェアハウス内で最初に作成されたサービス）は 2 つ以上のノードが必要です。各セカンダリサービスは 1 つ以上のノードを持つことができます。
• ノード（レプリカ）のサイズ
• サービスを自動スケーリングするかどうか
• サービスを非アクティブ時にアイドル状態にするかどうか（グループ内の最初のサービスには適用できません。制限事項 セクションを参照してください）

動作の変更点

あるサービスで compute-compute が有効になり（少なくとも 1 つのセカンダリサービスが作成され）ると、default クラスター名を指定した clusterAllReplicas() 関数呼び出しは、その関数が呼び出されたサービスのレプリカのみを使用します。つまり、同じデータセットに接続された 2 つのサービスがあり、サービス 1 から clusterAllReplicas(default, system, processes) を呼び出した場合、サービス 1 上で動作しているプロセスのみが表示されます。必要であれば、すべてのレプリカにアクセスするために、例えば clusterAllReplicas('all_groups.default', system, processes) を呼び出すことも可能です。

制限事項

1. プライマリサービスは常に稼働しており、アイドル状態にはできません（この制限は GA 後しばらくして削除される予定です）。 プライベートプレビュー期間中および GA 後しばらくの間、プライマリサービス（通常は、他のサービスを追加して拡張したい既存のサービス）は常に稼働しており、アイドル設定は無効になっています。少なくとも 1 つのセカンダリサービスが存在する場合、プライマリサービスを停止したりアイドル状態にしたりすることはできません。すべてのセカンダリサービスを削除すると、元のサービスを再び停止またはアイドル状態にすることができます。

2. ワークロードを分離できない場合があります。 目的は、データベースワークロード同士を相互に分離できるオプションを提供することですが、同じデータを共有するサービス上の 1 つのワークロードが、別のサービスに影響を与えるケースもあり得ます。これは、主に OLTP 的なワークロードに関連する、ごくまれな状況です。

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

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

5. 1 つの読み書きサービスでの挿入が、アイドル化が有効な場合に別の読み書きサービスのアイドル化を妨げる可能性があります。 その結果、2 番目のサービスが 1 番目のサービスのためのバックグラウンドマージ処理を実行します。これらのバックグラウンド処理によって、2 番目のサービスがアイドル状態（スリープ）への移行を妨げられることがあります。バックグラウンド処理が完了すると、そのサービスはアイドル状態になります。読み取り専用サービスは影響を受けず、遅延なくアイドル状態になります。

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

CREATE DATABASE db_test_ddl_single_query_setting
SETTINGS distributed_ddl_task_timeout=0

7. 現在、1つのウェアハウスあたりサービスは5つまでというソフトリミットがあります。 1つのウェアハウス内で5つを超えるサービスが必要な場合は、サポートチームにお問い合わせください。

料金

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

ワークロードの規模や選択したティアに基づいてコストを見積もるには、料金 ページにある料金計算ツールを参照してください。

バックアップ

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

ウェアハウスの使用

ウェアハウスの作成

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

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

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

ウェアハウス名の変更

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

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

ウェアハウスの削除

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

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