> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# ウェアハウス

> ClickHouse Cloud のコンピュート-コンピュート分離

export const ScalePlanFeatureBadge = ({feature = 'この機能', linking_verb_are = false}) => {
  return <div className="scalePlanFeatureContainer">
            <div className="scalePlanFeatureBadge">
                Scale プランの機能
            </div>
            <div>
                <p>{feature} {linking_verb_are ? 'は' : 'は'} Scale および Enterprise プランで利用できます。アップグレードするには、Cloud Console のプランページをご覧ください。</p>
            </div>
        </div>;
};

export const Image = ({img, alt, size = "lg"}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} />
      </Frame>
    </div>;
};

<ScalePlanFeatureBadge feature="Compute-compute separation" />

<div id="what-is-compute-compute-separation">
  ## コンピュート分離とは？
</div>

コンピュート分離について説明する前に、ClickHouse Cloud における**サービス**とは何かを理解しておくとわかりやすいでしょう。

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

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

<Image img="https://mintcdn.com/private-7c7dfe99/Ph2XgLY43sq6v4yO/images/cloud/reference/compute-compute-1.webp?fit=max&auto=format&n=Ph2XgLY43sq6v4yO&q=85&s=8f1dff55c2897cb907ef4ff19dd28120" size="md" alt="ClickHouse Cloud 内の単一サービス" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-1.webp" />

<br />

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

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

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

また、コンピュート分離を使うことで、読み取り処理と書き込み処理を分離し、相互に干渉しないようにすることもできます。

<Image img="https://mintcdn.com/private-7c7dfe99/Ph2XgLY43sq6v4yO/images/cloud/reference/compute-compute-2.webp?fit=max&auto=format&n=Ph2XgLY43sq6v4yO&q=85&s=a6c2b159f9e36750f8f8851eb36bdb3f" size="md" alt="ClickHouse Cloud におけるコンピュート分離" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-2.webp" />

<br />

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

<div id="what-is-a-warehouse">
  ## ウェアハウス とは何ですか？
</div>

ClickHouse Cloud では、*ウェアハウス* とは同じデータを共有する**サービス**の集合です。
各 ウェアハウス には、プライマリ サービス (最初に作成されるサービス) と、1 つ以上のセカンダリ サービスがあります。
たとえば、以下のスクリーンショットでは、2 つのサービスで構成される ウェアハウス「DWH Prod」を確認できます。

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

<Image img="https://mintcdn.com/private-7c7dfe99/Ph2XgLY43sq6v4yO/images/cloud/reference/compute-compute-8.webp?fit=max&auto=format&n=Ph2XgLY43sq6v4yO&q=85&s=164aea4e5ce44b816263fdcf51c707b6" size="lg" alt="プライマリ サービスとセカンダリ サービスを含む ウェアハウス の例" background="white" width="1582" height="226" data-path="images/cloud/reference/compute-compute-8.webp" />

<br />

*図 3 - ウェアハウス の例*

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

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

<div id="access-controls">
  ## アクセス制御
</div>

<div id="database-credentials">
  ### データベース認証情報
</div>

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

<Image img="https://mintcdn.com/private-7c7dfe99/Ph2XgLY43sq6v4yO/images/cloud/reference/compute-compute-3.webp?fit=max&auto=format&n=Ph2XgLY43sq6v4yO&q=85&s=b70fdda165fbecccddffb7b39abf2fb3" size="md" alt="同じデータを共有するサービス間でのユーザーアクセス" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-3.webp" />

<br />

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

<div id="network-access-control">
  ### ネットワークアクセス制御
</div>

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

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

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

<Image img="https://mintcdn.com/private-7c7dfe99/Ph2XgLY43sq6v4yO/images/cloud/reference/compute-compute-4.webp?fit=max&auto=format&n=Ph2XgLY43sq6v4yO&q=85&s=10d732df194d97d8ea74b8a96779ad32" size="md" alt="ネットワークアクセス制御の設定" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-4.webp" />

<br />

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

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

<div id="read-vs-read-write">
  ### 読み取り専用サービスと読み書きサービス
</div>

サービスの種類は次のいずれかです。

* **読み書き**
  * ClickHouse に対してデータの読み取りと書き込みの両方が可能
  * バックグラウンドマージ処理 (例: データ挿入後のパーツのマージ) を実行するため、CPU とメモリを消費する
  * データを外部にエクスポートできる
* **読み取り専用**
  * データの読み取りのみ可能で、ClickHouse 内のデータの書き込みや変更はできない
  * システムテーブルを除きバックグラウンドマージ処理を実行しないため、リソースを読み取りクエリに全面的に使える
  * 外部へのデータエクスポート (例: テーブル関数経由) は引き続き可能だが、ClickHouse 内のデータは変更できない
  * バックグラウンドマージによって稼働状態が維持されることがある読み書きサービスとは異なり、すぐにアイドル状態になる

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

<Image img="https://mintcdn.com/private-7c7dfe99/Ph2XgLY43sq6v4yO/images/cloud/reference/compute-compute-5.webp?fit=max&auto=format&n=Ph2XgLY43sq6v4yO&q=85&s=26a21056fbf8c8752b333151834b7c7b" size="lg" alt="ウェアハウス内の読み書きサービスと読み取り専用サービス" width="1349" height="1100" data-path="images/cloud/reference/compute-compute-5.webp" />

<br />

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

<Note>
  1. 読み取り専用サービスは現在、ユーザー管理操作 (CREATE、DROP など) をサポートしています。
  2. [リフレッシュ可能なマテリアライズドビュー](/docs/ja/concepts/features/materialized-views/refreshable-materialized-view) は、ウェアハウス内の読み書き (RW) サービスで**のみ**実行されます。
  3. サービスのタイプ (読み取り専用 または 読み書き) は作成時に固定され、その後 Cloud Console から変更することはできません。読み取り専用 と 読み書き を切り替えるには、ウェアハウス内に希望するタイプの新しいサービスを作成してください。
</Note>

<div id="scaling">
  ## スケーリング
</div>

ウェアハウス内の各サービスは、次の項目についてワークロードに合わせて調整できます。

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

詳細については、["オートスケーリング"](/docs/ja/products/cloud/features/autoscaling/overview) ページを参照してください。

<div id="changes-in-behavior">
  ## `clusterAllReplicas` の動作の変更
</div>

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

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

```sql theme={null}
SELECT * FROM clusterAllReplicas('all_groups.default', system, processes)
```

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

<div id="limitations">
  ## 制限事項
</div>

<div id="workload-isolation-limitations">
  ### ワークロード分離の制限事項
</div>

一部のワークロードは特定のサービスに分離できません。つまり、あるサービス上のワークロードが、同じウェアハウス内の別のサービスに影響するケースがあります。具体的には、次のようなものがあります。

* **すべての読み書きサービスは、デフォルトでバックグラウンドマージ処理を実行します。** ClickHouse にデータを挿入すると、データベースはまずデータを一時的なパーティションに書き込み、その後バックグラウンドでマージを実行します。これらのマージは、メモリや CPU リソースを消費することがあります。2 つの読み書きサービスが同じストレージを共有している場合、両方のサービスでバックグラウンド処理が実行されます。つまり、Service 1 で `INSERT` クエリが実行されても、そのマージ処理自体は Service 2 で完了することがあります。
  読み取り専用サービスはバックグラウンドマージを実行しないため、この処理にリソースを消費しない点に注意してください。なお、サポートではサービス上のマージを無効にすることもできます。

* **すべての読み書きサービスで S3Queue テーブルエンジンの insert 操作が実行されます。** 読み書きサービス上に S3Queue テーブルを作成すると、そのウェアハウス内の他のすべての読み書きサービスでも、S3 からのデータの読み取りとデータベースへの書き込みが実行される場合があります。

* **idling が有効な場合、ある読み書きサービスでの inserts によって、別の読み書きサービスがアイドル状態に移行できなくなることがあります。** あるサービスが、別のサービスのためにバックグラウンドマージ処理を実行する場合があります。こうしたバックグラウンド処理によって、後者のサービスがアイドル状態に移行できなくなることがあります。バックグラウンド処理が完了すると、そのサービスはアイドル状態になります。読み取り専用サービスは影響を受けません。

<div id="callouts">
  ### 参考情報
</div>

* **ClickHouse のバージョン**: [アップグレードスケジュール](/docs/ja/products/cloud/features/admin-features/upgrades)は、プライマリサービスの設定によって決まります。セカンダリサービスに、プライマリサービスとは独立したリリーススケジュールを設定することはできません。

* **`CREATE`/`RENAME`/`DROP DATABASE` クエリは、デフォルトでアイドル化または停止中のサービスによってブロックされることがあります。** サービスがアイドル化または停止中のときにこれらのクエリを実行すると、処理がハングする場合があります。これを回避するには、セッション単位またはクエリ単位で [`settings distributed_ddl_task_timeout=0`](/docs/ja/reference/settings/session-settings#distributed_ddl_task_timeout) を指定して、データベース管理クエリを実行できます。

たとえば:

```sql theme={null}
CREATE DATABASE db_test_ddl_single_query_setting
SETTINGS distributed_ddl_task_timeout=0
```

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

* **単一レプリカのプライマリサービス** 現在のデフォルト動作では、セカンダリサービスはレプリカを 1 つにできますが、プライマリサービスには少なくとも 2 つのレプリカが必要です。
  単一レプリカのプライマリサービスを有効にするには、サポートにお問い合わせください。この動作は 2026 年第 2 四半期にデフォルトで有効になる予定です。
* **プライマリサービスのアイドル化**: プライマリサービスの自動アイドル化はデフォルトで有効になっています。

<div id="pricing">
  ## 料金
</div>

コンピュートの価格は、1 つの ウェアハウス 内のすべてのサービス (プライマリおよびセカンダリ) で共通です。ストレージ料金が課金されるのは 1 回のみで、最初の (元の) サービスに含まれます。

ワークロードの規模と選択したティアに基づいてコストを見積もるには、[pricing](https://clickhouse.com/pricing) ページの料金計算ツールを参照してください。Usage Breakdown テーブルには、サービスごとのコンピュートコストの内訳が表示されます。

<div id="backups">
  ## バックアップ
</div>

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

<div id="setup-warehouses">
  ## ウェアハウス の設定方法
</div>

<div id="creating-a-warehouse">
  ### ウェアハウスの作成
</div>

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

<Image img="https://mintcdn.com/private-7c7dfe99/Ph2XgLY43sq6v4yO/images/cloud/reference/compute-compute-7.webp?fit=max&auto=format&n=Ph2XgLY43sq6v4yO&q=85&s=94b27d2207df2afa1c2c057049ff1895" size="md" alt="ウェアハウス内で新しいサービスを作成" width="1504" height="484" data-path="images/cloud/reference/compute-compute-7.webp" />

<br />

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

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

<div id="renaming-a-warehouse">
  ### ウェアハウス名の変更
</div>

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

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

<div id="deleting-a-warehouse">
  ### ウェアハウスの削除
</div>

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

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