ウェアハウス

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

コンピュート-コンピュート分離は、ScaleおよびEnterpriseのティアで利用可能です。

各ClickHouse Cloudサービスには以下が含まれます：

• 2つ以上のClickHouseノード（またはレプリカ）のグループが必要ですが、子サービスは単一のレプリカでもかまいません。
• サービスに接続するために使用するサービスURLであるエンドポイント（またはClickHouse Cloud UIコンソールを介して作成された複数のエンドポイント）。
• サービスがすべてのデータを保存するオブジェクトストレージフォルダー（部分的なメタデータも含む）：

注記

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

Fig. 1 - ClickHouse Cloudの現在のサービス

コンピュート-コンピュート分離により、ユーザーは複数のコンピュートノードグループを作成でき、それぞれ独自のエンドポイントを持ち、同じオブジェクトストレージフォルダーを使用するため、同じテーブル、ビューなどを使用することができます。

各コンピュートノードグループは独自のエンドポイントを持つため、ワークロードに使用するレプリカのセットを選択できます。ワークロードの中には、1つの小さなレプリカだけで満足するものもありますが、他のものは高可用性（HA）と数百ギガのメモリを必要とするかもしれません。コンピュート-コンピュート分離は、読み取り操作と書き込み操作を分離して、それらが互いに干渉しないようにすることも可能にします：

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

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

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

ClickHouse Cloudにおいて、_ウェアハウス_は同じデータを共有する一連のサービスです。 各ウェアハウスには、主要サービス（最初に作成されたサービス）と、1つ以上の副次サービスがあります。例えば、以下のスクリーンショットでは、"DWH Prod"というウェアハウスが2つのサービスを持つ様子が見えます：

• 主要サービス DWH Prod
• 副次サービス DWH Prod Subservice

Fig. 3 - ウェアハウスの例

ウェアハウス内のすべてのサービスは、同じ以下のものを共有します：

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

サービスを所属ウェアハウスでソートすることができます。

アクセス制御

データベース資格情報

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

Fig. 4 - ユーザーAliceはサービス1で作成されましたが、同じ資格情報を使用して同じデータを共有するすべてのサービスにアクセスできます。

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

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

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

Fig. 5 - ネットワーク設定のためにAliceはサービス2へのアクセスが制限されています。

読み取り vs 読み書き

特定のサービスへの書き込みアクセスを制限し、ウェアハウス内のサービスのサブセットのみが書き込みを許可することが便利な場合もあります。これは、2番目およびその後のサービスを作成する際に行うことができます（最初のサービスは常に読み書き可能である必要があります）：

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

注記

1. 読み取り専用サービスは現在、ユーザー管理操作（作成、削除など）を許可しています。この動作は将来的に変更される可能性があります。
2. 現在、リフレッシュ可能なマテリアライズドビューは、読み取り専用サービスを含むウェアハウス内のすべてのサービスで実行されます。この動作は将来的に変更され、RWサービスのみで実行されるようになります。

スケーリング

ウェアハウス内の各サービスは、以下の点でワークロードに合わせて調整できます：

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

挙動の変更

コンピュート-コンピュートがサービスに対して有効化されると（少なくとも1つの副次サービスが作成されている場合）、clusterAllReplicas()関数呼び出しとdefaultクラスタ名は、呼び出しが行われたサービスのレプリカのみを利用します。つまり、同じデータセットに接続されている2つのサービスがあり、サービス1からclusterAllReplicas(default, system, processes)が呼び出された場合、サービス1で実行されているプロセスのみが表示されます。必要に応じて、すべてのレプリカにアクセスするために、例えばclusterAllReplicas('all_groups.default', system, processes)を呼び出すことができます。

制限事項

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

2. ワークロードを隔離できない場合があります。 データベースワークロードを相互に隔離するオプションを提供することが目標ですが、同じデータを共有する他のサービスに影響を与えるサービス内のワークロードが存在する場合があります。これは、主にOLTPライクなワークロードに関連するかなり稀な状況です。

3. すべての読み書きサービスはバックグラウンドマージ操作を実行しています。 データがClickHouseに挿入されると、最初にデータは一時的なパーティションに挿入され、その後バックグラウンドでマージが実行されます。これらのマージはメモリおよびCPUリソースを消費する可能性があります。2つの読み書きサービスが同じストレージを共有する場合、両方ともバックグラウンド操作を実行しています。つまり、サービス1でINSERTクエリがありましたが、サービス2によってマージ操作が完了している場合があります。読み取り専用サービスはバックグラウンドマージを実行しないため、これにリソースを消費しません。

4. 1つの読み書きサービスでの挿入は、アイドル化が有効な場合に別の読み書きサービスがアイドル化されるのを妨げる可能性があります。 前のポイントにより、第2サービスが最初のサービスのためにバックグラウンドマージ操作を実行します。これらのバックグラウンド操作は、第2サービスがアイドル化するのを妨げる可能性があります。バックグラウンド操作が完了すると、サービスはアイドル化されます。読み取り専用サービスは影響を受けず、遅延なくアイドル化されます。

5. CREATE/RENAME/DROP DATABASEクエリは、アイドル化されたり停止されたサービスによってデフォルトでブロックされることがあります。 これらのクエリはハングする可能性があります。これを回避するには、settings distributed_ddl_task_timeout=0でデータベース管理クエリをセッションまたはクエリレベルで実行できます。例えば：

6. 非常にまれに、長期間（数日間）アイドル化または停止されていた副次サービスが、同じウェアハウス内の他のサービスにパフォーマンスの低下を引き起こす可能性があります。 この問題はすぐに解決され、バックグラウンドで実行されているミューテーションに関連しています。この問題が発生していると思われる場合は、ClickHouse サポート にお問い合わせください。

7. 現在、ウェアハウスあたり5つのサービスのソフト制限があります。 1つのウェアハウスに5つ以上のサービスが必要な場合は、サポートチームにお問い合わせください。

価格設定

コンピュートの価格は、ウェアハウス内のすべてのサービス（主要および副次）で同じです。ストレージは1回のみ請求され、最初（元の）サービスに含まれています。

バックアップ

• 単一のウェアハウス内のすべてのサービスは同じストレージを共有するため、バックアップは主要（初期）サービスのみに作成されます。これにより、ウェアハウス内のすべてのサービスのデータがバックアップされます。
• ウェアハウスの主要サービスからバックアップを復元すると、既存のウェアハウスに接続されていない完全に新しいサービスに復元されます。その後、復元が完了した後すぐに新しいサービスに他のサービスを追加できます。

ウェアハウスの使用

ウェアハウスの作成

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

Fig. 7 - ウェアハウス内に新しいサービスを作成するためにプラスのサインをクリック

サービス作成画面では、元のサービスが新しいサービスのデータソースとしてドロップダウンに選択されます。作成後、これら2つのサービスがウェアハウスを形成します。

ウェアハウスの名前変更

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

• サービスページの右上で「ウェアハウスでソート」を選択し、ウェアハウス名の近くにある鉛筆アイコンをクリックします。
• どのサービスでもウェアハウス名をクリックして、そこでウェアハウスの名前を変更します。

ウェアハウスの削除

ウェアハウスを削除することは、すべてのコンピュートサービスとデータ（テーブル、ビュー、ユーザーなど）を削除することを意味します。このアクションは元に戻すことができません。 ウェアハウスを削除するには、最初に作成されたサービスを削除する必要があります。これを行うためには：

1. 最初に作成されたサービスに加えて作成されたすべてのサービスを削除します。
2. 最初のサービスを削除します（警告：このステップでウェアハウスのすべてのデータが削除されます）。