メインコンテンツまでスキップ
メインコンテンツまでスキップ

ウェアハウス

計算の分離とは？​

計算の分離は、ScaleおよびEnterpriseティアで利用可能です。

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

  • 二つ以上のClickHouseノード（またはレプリカ）のグループが必要ですが、子サービスは単一のレプリカとなることができます。
  • エンドポイント（またはClickHouse Cloud UIコンソールを介して作成された複数のエンドポイント）、これはサービスに接続するために使用するサービスのURLです（例: https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443）。
  • サービスがすべてのデータと部分的なメタデータを保存するオブジェクトストレージフォルダー：
注記

子の単一サービスは、単一の親サービスとは異なり、垂直にスケールすることができます。


NEEDS ALT

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

計算の分離により、ユーザーは同じオブジェクトストレージフォルダーを使用する複数の計算ノードグループを作成でき、それにより同じテーブル、ビューなどを共有します。

各計算ノードグループには独自のエンドポイントがあり、ワークロードに使用するレプリカのセットを選択できます。ワークロードの一部は小型の単一レプリカで満たすことができ、他のものは完全な高可用性（HA）と数百ギガバイトのメモリを必要とするかもしれません。計算の分離は、読み取り操作と書き込み操作を分離することも可能にし、互いに干渉しないようにします。


NEEDS ALT

Fig. 2 - ClickHouse Cloudでの計算

このプライベートプレビュープログラムでは、既存のサービスと同じデータを共有する追加のサービスを作成したり、同じデータを共有する複数のサービスを持つ完全に新しいセットアップを作成することができます。

ウェアハウスとは？​

ClickHouse Cloudにおける_ウェアハウス_は、同じデータを共有するサービスのセットです。 各ウェアハウスにはプライマリーサービス（最初に作成されたサービス）とセカンダリーサービスがあります。以下のスクリーンショットでは、2つのサービスを持つウェアハウス「DWH Prod」を見ることができます：

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

NEEDS ALT

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

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

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

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

アクセス制御​

データベース認証情報​

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


NEEDS ALT

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

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

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

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


NEEDS ALT

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

読み取りと読み書き​

時には、特定のサービスへの書き込みアクセスを制限し、ウェアハウス内のsubsetのサービスのみが書き込めるようにすることが有用です。これは、二番目以降のサービスを作成する際に行うことができます（最初のサービスは常に読み書きである必要があります）：


NEEDS ALT

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

注記

読み取り専用サービスは現在、ユーザー管理操作（作成、削除など）を許可します。この挙動は将来的に変更される可能性があります。

スケーリング​

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

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

挙動の変更​

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

制限事項​

この計算の分離は現在プライベートプレビュー中であるため、この機能を使用する際にはいくつかの制限があります。これらの制限のほとんどは、機能がGA（一般提供）にリリースされると削除されます：

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

  2. ワークロードが分離されないことがあります。 データベースのワークロードを互いに分離するオプションを提供することが目標ですが、一方のサービス内のあるワークロードが同じデータを共有する別のサービスに影響を与える角ケースがある可能性があります。これはかなり稀な状況で、主にOLTPライクなワークロードに関連しています。

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

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

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

  1. 非常に稀なケースでは、長期間（数日）アイドルまたは停止しているセカンダリーサービスが、同じウェアハウス内の他のサービスのパフォーマンス低下を引き起こすことがあります。 この問題はまもなく解決され、バックグラウンドで実行されている変更に関連しています。この問題に直面していると思われる場合は、ClickHouseのサポートにご連絡ください。

価格設定​

プライベートプレビュー中に作成された追加サービスは、通常通り請求されます。計算コストは、ウェアハウス内のすべてのサービス（プライマリーおよびセカンダリー）で同じです。ストレージは1回だけ請求され、最初の（元の）サービスに含まれます。

バックアップ​

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

ウェアハウスの使用​

ウェアハウスの作成​

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


NEEDS ALT

Fig. 7 - ウェアハウスに新しいサービスを作成するにはプラス記号をクリックします

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

ウェアハウスの名前変更​

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

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

ウェアハウスの削除​

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

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