> ## 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. # スケーリング > スケーラビリティを実現するよう設計されたアーキテクチャ例を紹介するページ export const Image = ({img, alt, size = "lg"}) => { const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg"; return
{alt}
; }; > この例では、スケール可能なシンプルな ClickHouse クラスターのセットアップ方法を学びます。 > 5 台のサーバーを構成します。そのうち 2 台はデータの分片化に使用します。 > 残りの 3 台のサーバーは協調に使用します。 これからセットアップするクラスターのアーキテクチャを以下に示します。 2 つの分片と 1 つのレプリカのアーキテクチャ図 ClickHouse Server と ClickHouse Keeper を同じサーバー上でまとめて実行することも可能ですが、 本番環境では ClickHouse Keeper 用に*専用*ホストを使用することを強く推奨します。 この例でも、その構成を示します。 Keeper サーバーはより小規模なものでも問題なく、通常は各 Keeper サーバーにつき 4GB の RAM があれば、 ClickHouse Server が大規模になるまでは十分です。
## 前提条件
* 事前に[ローカルのClickHouseサーバー](/docs/ja/get-started/setup/install)をセットアップしていること * [設定ファイル](/docs/ja/concepts/features/configuration/server-config/configuration-files) など、ClickHouse の基本的な設定の概念を理解していること * 使用しているマシンに Docker がインストールされていること **サンプルファイル** 以下の手順では、クラスターを一からセットアップする方法を順を追って説明します。これらの手順を省略して、すぐにクラスターを実行したい場合は、examplesリポジトリの['docker-compose-recipes' ディレクトリ](https://github.com/ClickHouse/examples/tree/main/docker-compose-recipes/recipes)からサンプルファイルを取得できます。 このチュートリアルでは、[Docker compose](https://docs.docker.com/compose/) を使用して ClickHouse クラスターをセットアップします。このセットアップは、個別のローカルマシン、仮想マシン、またはクラウドインスタンス向けに変更することも可能です。 次のコマンドを実行して、この例のディレクトリ構造を作成します。 ```bash theme={null} mkdir cluster_2S_1R cd cluster_2S_1R # Create clickhouse-keeper directories for i in {01..03}; do mkdir -p fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper done # Create clickhouse-server directories for i in {01..02}; do mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server done ``` 以下の `docker-compose.yml` ファイルを `cluster_2S_1R` ディレクトリに追加します。 ```yaml title="docker-compose.yml" theme={null} version: '3.8' services: clickhouse-01: image: "clickhouse/clickhouse-server:latest" user: "101:101" container_name: clickhouse-01 hostname: clickhouse-01 networks: cluster_2S_1R: ipv4_address: 192.168.7.1 volumes: - ${PWD}/fs/volumes/clickhouse-01/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml - ${PWD}/fs/volumes/clickhouse-01/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml ports: - "127.0.0.1:8123:8123" - "127.0.0.1:9000:9000" depends_on: - clickhouse-keeper-01 - clickhouse-keeper-02 - clickhouse-keeper-03 clickhouse-02: image: "clickhouse/clickhouse-server:latest" user: "101:101" container_name: clickhouse-02 hostname: clickhouse-02 networks: cluster_2S_1R: ipv4_address: 192.168.7.2 volumes: - ${PWD}/fs/volumes/clickhouse-02/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml - ${PWD}/fs/volumes/clickhouse-02/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml ports: - "127.0.0.1:8124:8123" - "127.0.0.1:9001:9000" depends_on: - clickhouse-keeper-01 - clickhouse-keeper-02 - clickhouse-keeper-03 clickhouse-keeper-01: image: "clickhouse/clickhouse-keeper:latest-alpine" user: "101:101" container_name: clickhouse-keeper-01 hostname: clickhouse-keeper-01 networks: cluster_2S_1R: ipv4_address: 192.168.7.5 volumes: - ${PWD}/fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml ports: - "127.0.0.1:9181:9181" clickhouse-keeper-02: image: "clickhouse/clickhouse-keeper:latest-alpine" user: "101:101" container_name: clickhouse-keeper-02 hostname: clickhouse-keeper-02 networks: cluster_2S_1R: ipv4_address: 192.168.7.6 volumes: - ${PWD}/fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml ports: - "127.0.0.1:9182:9181" clickhouse-keeper-03: image: "clickhouse/clickhouse-keeper:latest-alpine" user: "101:101" container_name: clickhouse-keeper-03 hostname: clickhouse-keeper-03 networks: cluster_2S_1R: ipv4_address: 192.168.7.7 volumes: - ${PWD}/fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml ports: - "127.0.0.1:9183:9181" networks: cluster_2S_1R: driver: bridge ipam: config: - subnet: 192.168.7.0/24 gateway: 192.168.7.254 ``` 以下のサブディレクトリとファイルを作成してください： ```bash theme={null} for i in {01..02}; do mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server/config.d mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server/users.d touch fs/volumes/clickhouse-${i}/etc/clickhouse-server/config.d/config.xml touch fs/volumes/clickhouse-${i}/etc/clickhouse-server/users.d/users.xml done ``` * `config.d` ディレクトリには、ClickHouse server の構成ファイル `config.xml` が含まれており、 ここで各 ClickHouse ノード用のカスタム構成を定義します。この 構成は、すべての ClickHouse インストールに含まれるデフォルトの `config.xml` 構成 ファイルと組み合わされます。 * `users.d` ディレクトリにはユーザー構成ファイル `users.xml` が含まれており、ここで ユーザーごとのカスタム構成を定義します。この構成は、すべての ClickHouse インストールに含まれるデフォルトの `users.xml` 構成ファイルと組み合わされます。 **カスタム構成ディレクトリ** 独自の構成を記述する場合は、`/etc/clickhouse-server/config.xml` および `etc/clickhouse-server/users.xml` の デフォルト構成を直接変更するのではなく、`config.d` と `users.d` ディレクトリを 使用することをベストプラクティスとして推奨します。 次の行 ```xml theme={null} ``` により、`config.d` および `users.d` ディレクトリで定義した構成セクションが、デフォルトの `config.xml` および `users.xml` ファイルで定義された構成セクションを上書きするようになります。 ### サーバーのセットアップ 次に、`fs/volumes/clickhouse-{}/etc/clickhouse-server/config.d` にある空の設定ファイル `config.xml` をそれぞれ編集します。以下でハイライトされている行は、各ノードに固有の値に変更する必要があります。 ```xml highlight={9,54-57} theme={null} debug /var/log/clickhouse-server/clickhouse-server.log /var/log/clickhouse-server/clickhouse-server.err.log 1000M 3 cluster_2S_1R node 1 0.0.0.0 8123 9000 users.xml /var/lib/clickhouse/access/ /clickhouse/task_queue/ddl clickhouse-01 9000 clickhouse-02 9000 clickhouse-keeper-01 9181 clickhouse-keeper-02 9181 clickhouse-keeper-03 9181 01 01 ``` | ディレクトリ | File | | --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `fs/volumes/clickhouse-01/etc/clickhouse-server/config.d` | [`config.xml`](https://github.com/ClickHouse/examples/blob/main/docker-compose-recipes/recipes/cluster_2S_1R/fs/volumes/clickhouse-01/etc/clickhouse-server/config.d/config.xml) | | `fs/volumes/clickhouse-02/etc/clickhouse-server/config.d` | [`config.xml`](https://github.com/ClickHouse/examples/blob/main/docker-compose-recipes/recipes/cluster_2S_1R/fs/volumes/clickhouse-02/etc/clickhouse-server/config.d/config.xml) | 上記の設定ファイルの各セクションについて、以下で詳しく説明します。 #### ネットワークとログ ネットワークインターフェイスで外部からの通信を有効にするには、listen host 設定を有効化します。これにより、ClickHouse server のホストに他の ホストからアクセスできるようになります: ```xml theme={null} 0.0.0.0 ``` HTTP API のポートは `8123` に設定されています。 ```xml theme={null} 8123 ``` clickhouse-client や他のネイティブ ClickHouse ツール、ならびに clickhouse-server と他の clickhouse-servers の間で ClickHouse のネイティブプロトコルによる通信に使用される TCP ポートは、`9000` に設定されています。 ```xml theme={null} 9000 ``` ログは `` ブロックで定義します。以下の設定例では、1000M に達するとローテーションするデバッグログを3回分保持します： ```xml theme={null} debug /var/log/clickhouse-server/clickhouse-server.log /var/log/clickhouse-server/clickhouse-server.err.log 1000M 3 ``` ロギング設定の詳細については、デフォルトの ClickHouse [設定ファイル](https://github.com/ClickHouse/ClickHouse/blob/master/programs/server/config.xml)に含まれるコメントを参照してください。 #### クラスターの設定 クラスターの設定は `` ブロックで行います。 ここでクラスター名 `cluster_2S_1R` を定義します。 `` ブロックは、`` および `` の設定を使用してクラスターのレイアウトを定義し、`ON CLUSTER` 句を使用してクラスター全体で実行される distributed DDL クエリのテンプレートとして機能します。デフォルトでは distributed DDL クエリは許可されていますが、`allow_distributed_ddl_queries` の設定で無効にすることもできます。 `internal_replication` は、分片ごとのレプリカが1つのみであるため、デフォルトで false のままにしています。 ```xml theme={null} clickhouse-01 9000 clickhouse-02 9000 ``` 各サーバーに対して、次のパラメーターを指定します。 | Parameter | Description | Default Value | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | | `host` | リモートサーバーのアドレスです。ドメイン名、IPv4 アドレス、IPv6 アドレスのいずれかを使用できます。ドメイン名を指定すると、サーバーは起動時に DNS ルックアップを実行し、その結果はサーバーの稼働中保持されます。DNS ルックアップに失敗すると、サーバーは起動しません。DNS レコードを変更した場合は、サーバーを再起動する必要があります。 | - | | `port` | メッセンジャー通信用の TCP ポートです (設定ファイルでは `tcp_port`、通常は 9000 に設定されています) 。`http_port` と混同しないでください。 | - | #### Keeper の設定 `` セクションでは、ClickHouse Keeper (または ZooKeeper) の実行場所を ClickHouse に指定します。 ClickHouse Keeper クラスターを使用する場合、クラスター内の各 `` に対して、`` タグおよび `` タグでそれぞれホスト名とポート番号を指定する必要があります。 ClickHouse Keeper のセットアップについては、チュートリアルの次のステップで説明します。 ```xml theme={null} clickhouse-keeper-01 9181 clickhouse-keeper-02 9181 clickhouse-keeper-03 9181 ``` ClickHouse Keeper を ClickHouse Server と同じサーバー上で実行することもできますが、 本番環境では、ClickHouse Keeper は専用ホストで実行することを強く推奨します。 #### マクロの設定 また、`` セクションはレプリケートテーブル向けのパラメータ置換を定義するために使用されます。これらは `system.macros` に一覧表示され、クエリ内で `{shard}` や `{replica}` などの置換を利用できます。 ```xml theme={null} 01 01 ``` これらは、クラスターの構成に応じてそれぞれ定義されます。 ### ユーザー設定 次に、`fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d` にある空の設定ファイル `users.xml` をそれぞれ以下の内容に変更します。 ```xml title="/users.d/users.xml" theme={null} 10000000000 0 in_order 1 1 default ::/0 default 1 1 1 1 3600 0 0 0 0 0 ``` | ディレクトリ | File | | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `fs/volumes/clickhouse-01/etc/clickhouse-server/users.d` | [`users.xml`](https://github.com/ClickHouse/examples/blob/main/docker-compose-recipes/recipes/cluster_2S_1R/fs/volumes/clickhouse-01/etc/clickhouse-server/users.d/users.xml) | | `fs/volumes/clickhouse-02/etc/clickhouse-server/users.d` | [`users.xml`](https://github.com/ClickHouse/examples/blob/main/docker-compose-recipes/recipes/cluster_2S_1R/fs/volumes/clickhouse-02/etc/clickhouse-server/users.d/users.xml) | この例では、簡略化のためにデフォルトユーザーをパスワードなしで設定しています。 実際の運用では、この方法は推奨されません。 この例では、`users.xml` ファイルはクラスター内のすべてのノードで同一です。 ### Keeperのセットアップ レプリケーションを機能させるには、ClickHouse Keeper クラスターをセットアップして 設定する必要があります。ClickHouse Keeper はデータレプリケーションのための 調整システムを提供し、ZooKeeper の代替として動作します。ZooKeeper を使用することも可能ですが、 より優れた保証と信頼性を備え、 ZooKeeper よりも少ないリソースで動作するため、ClickHouse Keeper の使用が推奨されます。高可用性を確保し、 クォーラムを維持するため、少なくとも 3 台の ClickHouse Keeper ノードを実行することを推奨します。 ClickHouse Keeper は、ClickHouse と併せてクラスター内の任意のノードで実行できますが、 スケーリングや ClickHouse Keeper クラスターの管理をデータベースクラスターから独立して行えるため、 専用ノードで実行することを推奨します。 各 ClickHouse Keeper ノード用の `keeper_config.xml` ファイルを、 example フォルダーのルートで次のコマンドを使用して作成します。 ```bash theme={null} for i in {01..03}; do touch fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper/keeper_config.xml done ``` 各 ノードディレクトリ `fs/volumes/clickhouse-keeper-{}/etc/clickhouse-keeper` に作成された空の設定ファイルを編集します。以下で 強調表示されている行は、各ノードごとに対応する内容へ変更する必要があります。 ```xml title="/clickhouse-keeper/keeper_config.xml" highlight={12} theme={null} information /var/log/clickhouse-keeper/clickhouse-keeper.log /var/log/clickhouse-keeper/clickhouse-keeper.err.log 1000M 3 0.0.0.0 9181 1 /var/lib/clickhouse/coordination/log /var/lib/clickhouse/coordination/snapshots 10000 30000 information 1 clickhouse-keeper-01 9234 2 clickhouse-keeper-02 9234 3 clickhouse-keeper-03 9234 ``` | ディレクトリ | ファイル | | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper` | [`keeper_config.xml`](https://github.com/ClickHouse/examples/blob/main/docker-compose-recipes/recipes/cluster_2S_1R/fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper/keeper_config.xml) | | `fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper` | [`keeper_config.xml`](https://github.com/ClickHouse/examples/blob/main/docker-compose-recipes/recipes/cluster_2S_1R/fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper/keeper_config.xml) | | `fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper` | [`keeper_config.xml`](https://github.com/ClickHouse/examples/blob/main/docker-compose-recipes/recipes/cluster_2S_1R/fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper/keeper_config.xml) | 各設定ファイルには、次のような固有の設定 (以下参照) を含めます。 使用する `server_id` は、クラスター内の該当する ClickHouse Keeper ノードごとに一意であり、 `` セクションで定義されたサーバーの `` と一致している必要があります。 `tcp_port` は、ClickHouse Keeper の*クライアント*が使用するポートです。 ```xml theme={null} 9181 {id} ``` 次のセクションでは、 [Raftコンセンサスアルゴリズム](https://en.wikipedia.org/wiki/Raft_\(algorithm\))のクォーラムに参加する サーバーを設定します。 ```xml highlight={6} theme={null} 1 clickhouse-keeper-01 9234 2 clickhouse-keeper-02 9234 3 clickhouse-keeper-03 9234 ``` **ClickHouse Cloud なら管理がシンプルになります** [ClickHouse Cloud](/docs/ja/products/cloud/getting-started/intro) を利用すると、分片やレプリカの管理に伴う運用負荷を軽減できます。この プラットフォームでは、高可用性、レプリケーション、スケーリングに関する処理が自動的に行われます。 コンピュートとストレージは分離されており、手動での 設定や継続的な保守を必要とせず、需要に応じてスケールします。 [詳細はこちら](/docs/ja/products/cloud/features/autoscaling/overview) お使いのマシンで Docker が実行中であることを確認してください。 `cluster_2S_1R` ディレクトリのルートで `docker-compose up` コマンドを実行して、クラスターを起動します。 ```bash theme={null} docker-compose up -d ``` docker が ClickHouse と Keeper のイメージのプルを開始し、 その後コンテナーを起動するはずです。 ```bash theme={null} [+] Running 6/6 ✔ Network cluster_2s_1r_default Created ✔ Container clickhouse-keeper-03 Started ✔ Container clickhouse-keeper-02 Started ✔ Container clickhouse-keeper-01 Started ✔ Container clickhouse-01 Started ✔ Container clickhouse-02 Started ``` クラスターが稼働していることを確認するには、`clickhouse-01` または `clickhouse-02` のいずれかに接続して、次の クエリを実行します。以下は、最初のノードに接続するコマンドです。 ```bash theme={null} # Connect to any node docker exec -it clickhouse-01 clickhouse-client ``` 成功すると、ClickHouse clientのプロンプトが表示されます。 ```response theme={null} cluster_2S_1R node 1 :) ``` 各ホストにどのクラスターのトポロジーが定義されているかを確認するには、次のクエリを実行します。 ```sql title="Query" theme={null} SELECT cluster, shard_num, replica_num, host_name, port FROM system.clusters; ``` ```response title="Response" theme={null} ┌─cluster───────┬─shard_num─┬─replica_num─┬─host_name─────┬─port─┐ 1. │ cluster_2S_1R │ 1 │ 1 │ clickhouse-01 │ 9000 │ 2. │ cluster_2S_1R │ 2 │ 1 │ clickhouse-02 │ 9000 │ 3. │ default │ 1 │ 1 │ localhost │ 9000 │ └───────────────┴───────────┴─────────────┴───────────────┴──────┘ ``` ClickHouse Keeper クラスターの状態を確認するには、次のクエリを実行します。 ```sql title="Query" theme={null} SELECT * FROM system.zookeeper WHERE path IN ('/', '/clickhouse') ``` ```response title="Response" theme={null} ┌─name───────┬─value─┬─path────────┐ 1. │ task_queue │ │ /clickhouse │ 2. │ sessions │ │ /clickhouse │ 3. │ clickhouse │ │ / │ 4. │ keeper │ │ / │ └────────────┴───────┴─────────────┘ ``` `mntr` コマンドは、ClickHouse Keeper が稼働していることを確認し、 3 つの Keeper ノード間の関係に関する状態情報を取得するためにも一般的に使用されます。 この例で使用する構成では、3 つのノードが連携して動作します。 ノードは leader を選出し、残りのノードは followers になります。 `mntr` コマンドでは、パフォーマンスに関する情報に加え、 特定のノードが follower か leader かも確認できます。 `mntr` コマンドを Keeper に送信するには、`netcat` のインストールが必要になる場合があります。 ダウンロード方法については、[nmap.org](https://nmap.org/ncat/) のページを参照してください。 以下のコマンドを `clickhouse-keeper-01`、`clickhouse-keeper-02`、および `clickhouse-keeper-03` のシェルで実行し、各 Keeper ノードのステータスを確認します。`clickhouse-keeper-01` で実行するコマンドを以下に示します。 ```bash theme={null} docker exec -it clickhouse-keeper-01 /bin/sh -c 'echo mntr | nc 127.0.0.1 9181' ``` 以下は、フォロワーノードからのレスポンス例です。 ```response title="Response" highlight={9} theme={null} zk_version v23.3.1.2823-testing-46e85357ce2da2a99f56ee83a079e892d7ec3726 zk_avg_latency 0 zk_max_latency 0 zk_min_latency 0 zk_packets_received 0 zk_packets_sent 0 zk_num_alive_connections 0 zk_outstanding_requests 0 zk_server_state follower zk_znode_count 6 zk_watch_count 0 zk_ephemerals_count 0 zk_approximate_data_size 1271 zk_key_arena_size 4096 zk_latest_snapshot_size 0 zk_open_file_descriptor_count 46 zk_max_file_descriptor_count 18446744073709551615 ``` 以下は、リーダーノードからのレスポンス例です: ```response title="Response" highlight={9,18-19} theme={null} zk_version v23.3.1.2823-testing-46e85357ce2da2a99f56ee83a079e892d7ec3726 zk_avg_latency 0 zk_max_latency 0 zk_min_latency 0 zk_packets_received 0 zk_packets_sent 0 zk_num_alive_connections 0 zk_outstanding_requests 0 zk_server_state leader zk_znode_count 6 zk_watch_count 0 zk_ephemerals_count 0 zk_approximate_data_size 1271 zk_key_arena_size 4096 zk_latest_snapshot_size 0 zk_open_file_descriptor_count 48 zk_max_file_descriptor_count 18446744073709551615 zk_followers 2 zk_synced_followers 2 ``` これで、2 つの分片と、各分片に 1 つのレプリカを持つ ClickHouse クラスターのセットアップは正常に完了です。 次のステップでは、クラスター内にテーブルを作成します。 クラスターが正しくセットアップされ、稼働していることを確認できたので、次は [UK property prices](/docs/ja/get-started/sample-datasets/uk-price-paid) のサンプルデータセットのチュートリアルで使用したものと同じテーブルを再作成します。これには、1995 年以降のイングランドおよびウェールズの不動産売買価格に関する 約 3,000 万行のデータが含まれています。 各ホストのクライアントに接続するには、それぞれ別のターミナルタブまたはウィンドウで、以下の各コマンドを実行します: ```bash theme={null} docker exec -it clickhouse-01 clickhouse-client docker exec -it clickhouse-02 clickhouse-client ``` デフォルトのものを除いて、まだデータベースが作成されていないことを確認するには、 各ホストのclickhouse-clientから以下のクエリを実行できます。 ```sql title="Query" theme={null} SHOW DATABASES; ``` ```response title="Response" theme={null} ┌─name───────────────┐ 1. │ INFORMATION_SCHEMA │ 2. │ default │ 3. │ information_schema │ 4. │ system │ └────────────────────┘ ``` `clickhouse-01` クライアントから、`ON CLUSTER` 句を使用して `uk` という 新しいデータベースを作成する次の **分散** DDL クエリを実行します: ```sql highlight={2} theme={null} CREATE DATABASE IF NOT EXISTS uk ON CLUSTER cluster_2S_1R; ``` 各ホストのクライアントから先ほどと同じクエリをもう一度実行すると、 クエリは `clickhouse-01` でしか実行していないにもかかわらず、データベースがクラスター全体に作成されていることを確認できます: ```sql theme={null} SHOW DATABASES; ``` ```response highlight={6} theme={null} ┌─name───────────────┐ 1. │ INFORMATION_SCHEMA │ 2. │ default │ 3. │ information_schema │ 4. │ system │ 5. │ uk │ └────────────────────┘ ``` データベースを作成したので、次にテーブルを作成します。 次のクエリを任意のホストクライアントから実行します。 ```sql highlight={2} theme={null} CREATE TABLE IF NOT EXISTS uk.uk_price_paid_local ON CLUSTER cluster_2S_1R ( price UInt32, date Date, postcode1 LowCardinality(String), postcode2 LowCardinality(String), type Enum8('terraced' = 1, 'semi-detached' = 2, 'detached' = 3, 'flat' = 4, 'other' = 0), is_new UInt8, duration Enum8('freehold' = 1, 'leasehold' = 2, 'unknown' = 0), addr1 String, addr2 String, street LowCardinality(String), locality LowCardinality(String), town LowCardinality(String), district LowCardinality(String), county LowCardinality(String) ) ENGINE = MergeTree ORDER BY (postcode1, postcode2, addr1, addr2); ``` これは、元の `CREATE` ステートメントで使用されているクエリと同一で、 [UK property prices](/docs/ja/get-started/sample-datasets/uk-price-paid) サンプルデータセットのチュートリアルと違うのは、 `ON CLUSTER` 句だけです。 `ON CLUSTER` 句は、`CREATE`、`DROP`、`ALTER`、`RENAME` などの DDL (データ定義言語) クエリを分散実行するためのもので、これらの スキーマ変更がクラスター内のすべてのノードに適用されるようにします。 以下のクエリを各ホストのクライアントから実行すると、テーブルがクラスター全体で作成されていることを確認できます。 ```sql title="Query" theme={null} SHOW TABLES IN uk; ``` ```response title="Response" theme={null} ┌─name────────────────┐ 1. │ uk_price_paid_local │ └─────────────────────┘ ``` UK の price paid data を挿入する前に、簡単な実験として、いずれかのホストから通常のテーブルにデータを挿入するとどうなるかを確認してみましょう。 いずれかのホストで、次のクエリを実行してテスト用のデータベースとテーブルを作成します。 ```sql theme={null} CREATE DATABASE IF NOT EXISTS test ON CLUSTER cluster_2S_1R; CREATE TABLE test.test_table ON CLUSTER cluster_2S_1R ( `id` UInt64, `name` String ) ENGINE = MergeTree() ORDER BY id; ``` 次に、`clickhouse-01` で以下の `INSERT` クエリを実行します。 ```sql theme={null} INSERT INTO test.test_table (id, name) VALUES (1, 'Clicky McClickface'); ``` `clickhouse-02` に切り替え、次の `INSERT` クエリを実行します。 ```sql title="Query" theme={null} INSERT INTO test.test_table (id, name) VALUES (1, 'Alexey Milovidov'); ``` 次に、`clickhouse-01` または `clickhouse-02` で、次のクエリを実行します。 ```sql theme={null} -- from clickhouse-01 SELECT * FROM test.test_table; -- ┌─id─┬─name───────────────┐ -- 1.│ 1 │ Clicky McClickface │ -- └────┴────────────────────┘ --from clickhouse-02 SELECT * FROM test.test_table; -- ┌─id─┬─name───────────────┐ -- 1.│ 1 │ Alexey Milovidov │ -- └────┴────────────────────┘ ``` `ReplicatedMergeTree` テーブルとは異なり、この特定のホスト上で テーブルに挿入された行だけが返され、両方の行が返されるわけではないことがわかります。 2 つの分片にまたがるデータを読み取るには、すべての分片にまたがるクエリを処理できる インターフェイスが必要です。これにより、そのインターフェイスに対して select クエリを実行すると両方の分片のデータを組み合わせ、 insert クエリを実行すると両方の分片にデータを挿入できます。 ClickHouse では、このインターフェイスは **分散テーブル** と呼ばれ、 [`Distributed`](/docs/ja/reference/engines/table-engines/special/distributed) テーブルエンジンを使って作成します。どのように動作するのか見てみましょう。 以下のクエリを使用して分散テーブルを作成します。 ```sql theme={null} CREATE TABLE test.test_table_dist ON CLUSTER cluster_2S_1R AS test.test_table ENGINE = Distributed('cluster_2S_1R', 'test', 'test_table', rand()) ``` この例では、`rand()` 関数がシャーディングキーとして選択されているため、 挿入データは各分片にランダムに分散されます。 次に、どちらかのホストから分散テーブルに対してクエリを実行すると、 前の例とは異なり、2 つのホストに挿入された両方の行が返されます。 ```sql theme={null} SELECT * FROM test.test_table_dist; ``` ```response theme={null} ┌─id─┬─name───────────────┐ 1. │ 1 │ Alexey Milovidov │ 2. │ 1 │ Clicky McClickface │ └────┴────────────────────┘ ``` 同じことを、英国の不動産価格データについても行いましょう。いずれかのホストクライアントから、 先ほど `ON CLUSTER` を使って作成した既存のテーブルを使用して分散テーブルを作成するには、 次のクエリを実行します。 ```sql theme={null} CREATE TABLE IF NOT EXISTS uk.uk_price_paid_distributed ON CLUSTER cluster_2S_1R ENGINE = Distributed('cluster_2S_1R', 'uk', 'uk_price_paid_local', rand()); ``` いずれかのホストに接続し、データを挿入します。 ```sql theme={null} INSERT INTO uk.uk_price_paid_distributed SELECT toUInt32(price_string) AS price, parseDateTimeBestEffortUS(time) AS date, splitByChar(' ', postcode)[1] AS postcode1, splitByChar(' ', postcode)[2] AS postcode2, transform(a, ['T', 'S', 'D', 'F', 'O'], ['terraced', 'semi-detached', 'detached', 'flat', 'other']) AS type, b = 'Y' AS is_new, transform(c, ['F', 'L', 'U'], ['freehold', 'leasehold', 'unknown']) AS duration, addr1, addr2, street, locality, town, district, county FROM url( 'http://prod1.publicdata.landregistry.gov.uk.s3-website-eu-west-1.amazonaws.com/pp-complete.csv', 'CSV', 'uuid_string String, price_string String, time String, postcode String, a String, b String, c String, addr1 String, addr2 String, street String, locality String, town String, district String, county String, d String, e String' ) SETTINGS max_http_get_redirects=10; ``` データが挿入されたら、distributedテーブルを使用して行数を確認できます： ```sql title="Query" theme={null} SELECT count(*) FROM uk.uk_price_paid_distributed ``` ```response title="Response" theme={null} ┌──count()─┐ 1. │ 30212555 │ -- 30.21 million └──────────┘ ``` いずれかのホストで次のクエリを実行すると、データが各分片にほぼ均等に分散されていることを確認できます (どの分片に挿入するかは `rand()` によってランダムに決定されるため、実行環境によって結果が異なる場合があります) ： ```sql theme={null} -- from clickhouse-01 SELECT count(*) FROM uk.uk_price_paid_local -- ┌──count()─┐ -- 1. │ 15107353 │ -- 15.11 million -- └──────────┘ --from clickhouse-02 SELECT count(*) FROM uk.uk_price_paid_local -- ┌──count()─┐ -- 1. │ 15105202 │ -- 15.11 million -- └──────────┘ ``` ホストの1つに障害が発生した場合、どうなるでしょうか？`clickhouse-01`をシャットダウンして実際に確認してみましょう： ```bash theme={null} docker stop clickhouse-01 ``` 次のコマンドを実行して、ホストがダウンしていることを確認します： ```bash theme={null} docker-compose ps ``` ```response title="Response" theme={null} NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS clickhouse-02 clickhouse/clickhouse-server:latest "/entrypoint.sh" clickhouse-02 X minutes ago Up X minutes 127.0.0.1:8124->8123/tcp, 127.0.0.1:9001->9000/tcp clickhouse-keeper-01 clickhouse/clickhouse-keeper:latest-alpine "/entrypoint.sh" clickhouse-keeper-01 X minutes ago Up X minutes 127.0.0.1:9181->9181/tcp clickhouse-keeper-02 clickhouse/clickhouse-keeper:latest-alpine "/entrypoint.sh" clickhouse-keeper-02 X minutes ago Up X minutes 127.0.0.1:9182->9181/tcp clickhouse-keeper-03 clickhouse/clickhouse-keeper:latest-alpine "/entrypoint.sh" clickhouse-keeper-03 X minutes ago Up X minutes 127.0.0.1:9183->9181/tcp ``` 次に、`clickhouse-02` から、先ほど Distributed テーブルに対して実行したのと同じ select クエリを実行します： ```sql theme={null} SELECT count(*) FROM uk.uk_price_paid_distributed ``` ```response title="Response" highlight={6} theme={null} Received exception from server (version 25.5.2): Code: 279. DB::Exception: Received from localhost:9000. DB::Exception: All connection tries failed. Log: Code: 32. DB::Exception: Attempt to read after eof. (ATTEMPT_TO_READ_AFTER_EOF) (version 25.5.2.47 (official build)) Code: 209. DB::NetException: Timeout: connect timed out: 192.168.7.1:9000 (clickhouse-01:9000, 192.168.7.1, local address: 192.168.7.2:37484, connection timeout 1000 ms). (SOCKET_TIMEOUT) (version 25.5.2.47 (official build)) Code: 198. DB::NetException: Not found address of host: clickhouse-01: (clickhouse-01:9000, 192.168.7.1, local address: 192.168.7.2:37484). (DNS_ERROR) (version 25.5.2.47 (official build)) : While executing Remote. (ALL_CONNECTION_TRIES_FAILED) ``` 残念ながら、このクラスターはフォールトトレラントではありません。いずれかのホストに障害が発生すると、クラスターは異常とみなされてクエリが失敗します。[前の例](/docs/ja/guides/oss/deployment-and-scaling/examples/1-shard-2-replicas)で確認したレプリケートテーブルでは、ホストの1つに障害が発生してもデータを挿入できたのとは対照的です。
## 結論
このクラスター構成の利点は、データが複数のホストに分散されるため、各ノードで必要なストレージ容量を半分に抑えられることです。さらに重要なのは、クエリが両方の分片にまたがって処理されるため、メモリ使用効率が向上し、各ホストの I/O も削減されることです。 もちろん、このクラスター構成の最大の欠点は、ホストの 1 台が失われると、 クエリを提供できなくなることです。 [次の例](/docs/ja/guides/oss/deployment-and-scaling/examples/2-shards-2-replicas)では、拡張性と 耐障害性の両方を備えた、2 つの分片と 2 つのレプリカを持つクラスターの 構成方法を見ていきます。