スケーリング

この例では、スケールするシンプルな ClickHouse クラスターのセットアップ方法を学びます。ここでは 5 台のサーバーを構成します。うち 2 台はデータのシャーディングに使用し、残りの 3 台はコーディネーション（調停）に使用します。

これからセットアップするクラスターのアーキテクチャは、以下のとおりです。

注記

ClickHouse Server と ClickHouse Keeper を同じサーバー上で動かすことも可能ですが、本番環境では ClickHouse Keeper 用に専用ホストを使用することを強く推奨します。この例でもその構成を用いて説明します。

Keeper サーバーは小さめの構成でも問題なく、各 Keeper サーバーあたり 4GB の RAM があれば、 ClickHouse Server 群が大きくなるまでは一般的には十分です。

前提条件

以前にローカル ClickHouse サーバーをセットアップしたことがある
ClickHouse の設定ファイルなど、基本的な設定に関する概念に慣れている
手元のマシンに Docker がインストールされている

ディレクトリ構造とテスト環境のセットアップ

サンプルファイル

以下の手順では、クラスターをゼロからセットアップする方法を順を追って説明します。これらの手順をスキップしてすぐにクラスターを起動したい場合は、examples リポジトリの 'docker-compose-recipes' ディレクトリからサンプルファイルを取得できます。

このチュートリアルでは、Docker composeを使用してClickHouseクラスタをセットアップします。このセットアップは、個別のローカルマシン、仮想マシン、クラウドインスタンスでも動作するように変更可能です。

この例のディレクトリ構造をセットアップするには、以下のコマンドを実行します:

mkdir cluster_2S_1R
cd cluster_2S_1R

# clickhouse-keeperディレクトリを作成
for i in {01..03}; do
  mkdir -p fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper
done

# clickhouse-serverディレクトリを作成
for i in {01..02}; do
  mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server
done

以下の docker-compose.yml ファイルを clickhouse-cluster ディレクトリに追加します：

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

以下のサブディレクトリとファイルを作成します：

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 サーバーの設定ファイル config.xml が含まれており、各 ClickHouse ノード向けのカスタム設定がここで定義されます。この設定は、すべての ClickHouse インストールに付属するデフォルトの ClickHouse 設定ファイル config.xml とマージされて使用されます。
users.d ディレクトリにはユーザー設定ファイル users.xml が含まれており、ユーザーに対するカスタム設定がここで定義されます。この設定は、すべての ClickHouse インストールに付属するデフォルトの ClickHouse 設定ファイル users.xml とマージされて使用されます。

Custom configuration directories

独自の設定を記述する際には、/etc/clickhouse-server/config.xml および etc/clickhouse-server/users.xml のデフォルト設定を直接変更するのではなく、 config.d および users.d ディレクトリを利用することがベストプラクティスです。

The line

<clickhouse replace="true">

config.d および users.d ディレクトリで定義された設定セクションが、デフォルトの config.xml および users.xml ファイルで定義されている設定セクションより優先されるようにします。

ClickHouseノードの設定

サーバーのセットアップ

次に、fs/volumes/clickhouse-{}/etc/clickhouse-server/config.dに配置されている各空の設定ファイルconfig.xmlを修正します。以下で強調表示されている行は、各ノードに固有の内容に変更する必要があります:

<clickhouse replace="true">
    <logger>
        <level>debug</level>
        <log>/var/log/clickhouse-server/clickhouse-server.log</log>
        <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
        <size>1000M</size>
        <count>3</count>
    </logger>
    <!--highlight-next-line-->
    <display_name>cluster_2S_1R node 1</display_name>
    <listen_host>0.0.0.0</listen_host>
    <http_port>8123</http_port>
    <tcp_port>9000</tcp_port>
    <user_directories>
        <users_xml>
            <path>users.xml</path>
        </users_xml>
        <local_directory>
            <path>/var/lib/clickhouse/access/</path>
        </local_directory>
    </user_directories>
    <distributed_ddl>
        <path>/clickhouse/task_queue/ddl</path>
    </distributed_ddl>
    <remote_servers>
        <cluster_2S_1R>
            <shard>
                <replica>
                    <host>clickhouse-01</host>
                    <port>9000</port>
                </replica>
            </shard>
            <shard>
                <replica>
                    <host>clickhouse-02</host>
                    <port>9000</port>
                </replica>
            </shard>
        </cluster_2S_1R>
    </remote_servers>
    <zookeeper>
        <node>
            <host>clickhouse-keeper-01</host>
            <port>9181</port>
        </node>
        <node>
            <host>clickhouse-keeper-02</host>
            <port>9181</port>
        </node>
        <node>
            <host>clickhouse-keeper-03</host>
            <port>9181</port>
        </node>
    </zookeeper>
    <!--highlight-start-->
    <macros>
        <shard>01</shard>
        <replica>01</replica>
    </macros>
    <!--highlight-end-->
</clickhouse>

ディレクトリ	ファイル
`fs/volumes/clickhouse-01/etc/clickhouse-server/config.d`	`config.xml`
`fs/volumes/clickhouse-02/etc/clickhouse-server/config.d`	`config.xml`

上記の設定ファイルの各セクションについて、以下で詳細に説明します。

ネットワーキングとロギング

ネットワークインターフェースへの外部からの通信は、listen_host 設定を有効にすることで行えるようになります。これにより、ClickHouse サーバーホストには他のホストから接続できるようになります。

<listen_host>0.0.0.0</listen_host>

HTTP API 用のポートは 8123 に設定されています：

<http_port>8123</http_port>

ClickHouse のネイティブプロトコルを使用した clickhouse-client と他のネイティブ ClickHouse ツール間、ならびに clickhouse-server と他の clickhouse-server 間の通信に用いられる TCP ポートは 9000 です。

<tcp_port>9000</tcp_port>

ログ記録は <logger> ブロックで定義します。この設定例では、1000Mに達すると3回ローテーションするデバッグログが出力されます:

<logger>
    <level>debug</level>
    <log>/var/log/clickhouse-server/clickhouse-server.log</log>
    <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
    <size>1000M</size>
    <count>3</count>
</logger>

ログ設定の詳細については、デフォルトのClickHouse設定ファイルに含まれているコメントを参照してください。

クラスター設定

クラスタの設定は <remote_servers> ブロックで設定します。ここでクラスタ名 cluster_2S_1R を定義しています。

<cluster_2S_1R></cluster_2S_1R> ブロックは、<shard></shard> および <replica></replica> 設定を使用してクラスタのレイアウトを定義し、分散DDLクエリのテンプレートとして機能します。分散DDLクエリは、ON CLUSTER 句を使用してクラスタ全体で実行されるクエリです。デフォルトでは分散DDLクエリは許可されていますが、allow_distributed_ddl_queries 設定により無効化することも可能です。

internal_replicationは、シャードごとにレプリカが1つのみであるため、デフォルトでfalseに設定されたままになっています。

<remote_servers>
    <cluster_2S_1R>
        <shard>
            <replica>
                <host>clickhouse-01</host>
                <port>9000</port>
            </replica>
        </shard>
        <shard>
            <replica>
                <host>clickhouse-02</host>
                <port>9000</port>
            </replica>
        </shard>
    </cluster_2S_1R>
</remote_servers>

各サーバーごとに、次のパラメータを指定します。

Parameter	Description	Default Value
`host`	リモートサーバーのアドレス。ドメイン名、IPv4 アドレス、または IPv6 アドレスのいずれかを使用できます。ドメイン名を指定した場合、サーバー起動時に DNS リクエストが行われ、その結果はサーバーの動作中保持されます。DNS リクエストが失敗した場合、サーバーは起動しません。DNS レコードを変更した場合は、サーバーを再起動する必要があります。	-
`port`	messenger の動作に使用する TCP ポート（設定ファイルの `tcp_port`。通常は 9000 に設定）。`http_port` と混同しないでください。	-

Keeper の設定

<ZooKeeper> セクションは、ClickHouse Keeper（または ZooKeeper）の実行場所を ClickHouse に指定します。 ClickHouse Keeper クラスタを使用する場合、クラスタの各 <node> を指定する必要があります。ホスト名とポート番号はそれぞれ <host> タグと <port> タグを使用して指定します。

ClickHouse Keeperのセットアップは、チュートリアルの次のステップで説明されています。

<zookeeper>
    <node>
        <host>clickhouse-keeper-01</host>
        <port>9181</port>
    </node>
    <node>
        <host>clickhouse-keeper-02</host>
        <port>9181</port>
    </node>
    <node>
        <host>clickhouse-keeper-03</host>
        <port>9181</port>
    </node>
</zookeeper>

注記

ClickHouse KeeperをClickHouse Serverと同じサーバー上で実行することは可能ですが、本番環境では専用ホスト上で実行することを強く推奨します。

マクロの設定

また、<macros> セクションは、レプリケーテッドテーブルのパラメータ置換を定義するために使用されます。これらは system.macros に記載され、クエリ内で {shard} や {replica} などの置換を使用できます。

<macros>
    <shard>01</shard>
    <replica>01</replica>
</macros>

注記

これらはクラスタの構成に応じて個別に定義する必要があります。

ユーザー設定

次に、fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d に配置されている各空の設定ファイル users.xml を以下の内容で変更します:

<?xml version="1.0"?>
<clickhouse replace="true">
    <profiles>
        <default>
            <max_memory_usage>10000000000</max_memory_usage>
            <use_uncompressed_cache>0</use_uncompressed_cache>
            <load_balancing>in_order</load_balancing>
            <log_queries>1</log_queries>
        </default>
    </profiles>
    <users>
        <default>
            <access_management>1</access_management>
            <profile>default</profile>
            <networks>
                <ip>::/0</ip>
            </networks>
            <quota>default</quota>
            <access_management>1</access_management>
            <named_collection_control>1</named_collection_control>
            <show_named_collections>1</show_named_collections>
            <show_named_collections_secrets>1</show_named_collections_secrets>
        </default>
    </users>
    <quotas>
        <default>
            <interval>
                <duration>3600</duration>
                <queries>0</queries>
                <errors>0</errors>
                <result_rows>0</result_rows>
                <read_rows>0</read_rows>
                <execution_time>0</execution_time>
            </interval>
        </default>
    </quotas>
</clickhouse>

目次	ファイル
`fs/volumes/clickhouse-01/etc/clickhouse-server/users.d`	`users.xml`
`fs/volumes/clickhouse-02/etc/clickhouse-server/users.d`	`users.xml`

この例では、簡略化のためデフォルトユーザーをパスワードなしで設定しています。実際の運用環境では、この設定は推奨されません。

注記

この例では、クラスター内のすべてのノードでusers.xmlファイルが同一です。

ClickHouse Keeperの設定

Keeperのセットアップ

レプリケーションを機能させるためには、ClickHouse Keeper クラスターをセットアップして構成する必要があります。ClickHouse Keeper はデータレプリケーションのためのコーディネーションシステムを提供し、 ZooKeeper の代替として動作しますが、ZooKeeper を使用することも可能です。ただし ClickHouse Keeper は、より強い保証と高い信頼性を提供し、ZooKeeper よりも少ないリソースで動作するため推奨されます。高可用性とクォーラム維持のために、少なくとも 3 つの ClickHouse Keeper ノードを実行することを推奨します。

注記

ClickHouse Keeper はクラスター内の任意のノード上で ClickHouse と一緒に実行できますが、スケーリングおよびデータベースクラスターとは独立した ClickHouse Keeper クラスターの管理を可能にするため、専用ノード上で実行することを推奨します。

各 ClickHouse Keeper ノード用の keeper_config.xml ファイルを、サンプルディレクトリのルートから次のコマンドを使用して作成します:

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 に作成された空の設定ファイルを編集します。
以下のハイライトされた行を、各ノードに固有の設定となるように変更してください。

<clickhouse replace="true">
    <logger>
        <level>information</level>
        <log>/var/log/clickhouse-keeper/clickhouse-keeper.log</log>
        <errorlog>/var/log/clickhouse-keeper/clickhouse-keeper.err.log</errorlog>
        <size>1000M</size>
        <count>3</count>
    </logger>
    <listen_host>0.0.0.0</listen_host>
    <keeper_server>
        <tcp_port>9181</tcp_port>
        <!--highlight-next-line-->
        <server_id>1</server_id>
        <log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
        <snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>
        <coordination_settings>
            <operation_timeout_ms>10000</operation_timeout_ms>
            <session_timeout_ms>30000</session_timeout_ms>
            <raft_logs_level>information</raft_logs_level>
        </coordination_settings>
        <raft_configuration>
            <server>
                <id>1</id>
                <hostname>clickhouse-keeper-01</hostname>
                <port>9234</port>
            </server>
            <server>
                <id>2</id>
                <hostname>clickhouse-keeper-02</hostname>
                <port>9234</port>
            </server>
            <server>
                <id>3</id>
                <hostname>clickhouse-keeper-03</hostname>
                <port>9234</port>
            </server>
        </raft_configuration>
    </keeper_server>
</clickhouse>

ディレクトリ	ファイル
`fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper`	`keeper_config.xml`
`fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper`	`keeper_config.xml`
`fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper`	`keeper_config.xml`

各設定ファイルには、以下のような固有の設定が含まれています（下記参照）。使用する server_id は、そのクラスタ内で該当する ClickHouse Keeper ノードごとに一意であり、 <raft_configuration> セクションで定義されているサーバーの <id> と一致している必要があります。 tcp_port は ClickHouse Keeper の クライアント が使用するポートです。

<tcp_port>9181</tcp_port>
<server_id>{id}</server_id>

次のセクションでは、Raft 合意アルゴリズムのクォーラムに参加するサーバーを構成します。

<raft_configuration>
    <server>
        <id>1</id>
        <hostname>clickhouse-keeper-01</hostname>
        <!-- ClickHouse Keeperノード間通信用のTCPポート -->
        <!--highlight-next-line-->
        <port>9234</port>
    </server>
    <server>
        <id>2</id>
        <hostname>clickhouse-keeper-02</hostname>
        <port>9234</port>
    </server>
    <server>
        <id>3</id>
        <hostname>clickhouse-keeper-03</hostname>
        <port>9234</port>
    </server>
</raft_configuration>

ClickHouse Cloud で管理を簡素化

ClickHouse Cloud は、シャードおよびレプリカの管理に伴う運用上の負担を取り除きます。プラットフォームが高可用性の確保、レプリケーション、およびスケーリングに関する判断を自動的に行います。コンピュートリソースとストレージは分離されており、需要に応じて自動的にスケールするため、手動での設定や継続的なメンテナンスは不要です。

詳細を見る

セットアップのテスト

マシン上でDockerが実行されていることを確認してください。 cluster_2S_1Rディレクトリのルートからdocker-compose upコマンドを使用してクラスタを起動します:

docker-compose up -d

dockerがClickHouseとKeeperのイメージをプルし、その後コンテナを起動する様子が確認できます:

[+] 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 のいずれかに接続し、以下のクエリを実行します。最初のノードへの接続コマンドは次のとおりです:

# 任意のノードに接続
docker exec -it clickhouse-01 clickhouse-client

成功すると、ClickHouseクライアントのプロンプトが表示されます：

cluster_2S_1R node 1 :)

以下のクエリを実行して、各ホストに定義されているクラスタトポロジを確認します：

SELECT 
    cluster,
    shard_num,
    replica_num,
    host_name,
    port
FROM system.clusters;

┌─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クラスタのステータスを確認します：

SELECT *
FROM system.zookeeper
WHERE path IN ('/', '/clickhouse')

┌─name───────┬─value─┬─path────────┐
1. │ task_queue │       │ /clickhouse │
2. │ sessions   │       │ /clickhouse │
3. │ clickhouse │       │ /           │
4. │ keeper     │       │ /           │
   └────────────┴───────┴─────────────┘

mntr コマンドは、ClickHouse Keeper が稼働していることを確認し、 3 つの Keeper ノード間の関係に関する状態情報を取得するためにも一般的に使用されます。この例で使用している構成では、3 つのノードが協調して動作しています。ノード間でリーダーを選出し、残りのノードはフォロワーになります。

mntr コマンドは、パフォーマンスに関連する情報と、特定のノードがフォロワーかリーダーかを示します。

ヒント

Keeper に mntr コマンドを送信するには、netcat をインストールする必要がある場合があります。ダウンロード情報については nmap.org のページを参照してください。

各 Keeper ノードのステータスを確認するために、clickhouse-keeper-01、clickhouse-keeper-02、 clickhouse-keeper-03 上のシェルから以下のコマンドを実行します。 clickhouse-keeper-01 用のコマンドは次のとおりです。

docker exec -it clickhouse-keeper-01  /bin/sh -c 'echo mntr | nc 127.0.0.1 9181'

以下は、フォロワーノードからの応答例です。

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
# highlight-next-line
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

以下は、リーダーノードからの応答例です。

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
# highlight-next-line
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
# highlight-start
zk_followers    2
zk_synced_followers     2
# highlight-end

これで、1つのシャードと2つのレプリカを持つClickHouseクラスタのセットアップが完了しました。次のステップでは、クラスタにテーブルを作成します。

データベースを作成する

クラスタが正しくセットアップされ、実行されていることを確認したので、UK property pricesサンプルデータセットチュートリアルで使用されているものと同じテーブルを再作成します。このデータセットは、1995年以降にイングランドとウェールズで取引された不動産物件の価格データ約3,000万行で構成されています。

各ホストのクライアントに接続するには、以下の各コマンドを別々のターミナルタブまたはウィンドウから実行します:

docker exec -it clickhouse-01 clickhouse-client
docker exec -it clickhouse-02 clickhouse-client

各ホストのclickhouse-clientから以下のクエリを実行して、デフォルトのデータベース以外にデータベースが作成されていないことを確認してください:

SHOW DATABASES;

┌─name───────────────┐
1. │ INFORMATION_SCHEMA │
2. │ default            │
3. │ information_schema │
4. │ system             │
   └────────────────────┘

clickhouse-01 クライアントから、ON CLUSTER 句を使用して以下の分散型 DDL クエリを実行し、uk という名前の新しいデータベースを作成します：

CREATE DATABASE IF NOT EXISTS uk 
-- highlight-next-line
ON CLUSTER cluster_2S_1R;

各ホストのクライアントから先ほどと同じクエリを再度実行し、clickhouse-01でのみクエリを実行したにもかかわらず、クラスタ全体でデータベースが作成されていることを確認できます。

SHOW DATABASES;

┌─name───────────────┐
1. │ INFORMATION_SCHEMA │
2. │ default            │
3. │ information_schema │
4. │ system             │
#highlight-next-line
5. │ uk                 │
   └────────────────────┘

クラスタ上にテーブルを作成する

データベースが作成されたので、次にテーブルを作成します。任意のホストクライアントから以下のクエリを実行してください:

CREATE TABLE IF NOT EXISTS uk.uk_price_paid_local
--highlight-next-line
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);

これはUK property pricesサンプルデータセットチュートリアルの元のCREATE文で使用されたクエリと同一です。ただし、ON CLUSTER句は除きます。

ON CLUSTER句は、CREATE、DROP、ALTER、RENAMEなどのDDL(Data Definition Language)クエリを分散実行するために設計されており、これらのスキーマ変更をクラスタ内のすべてのノードに適用します。

各ホストのクライアントから以下のクエリを実行し、クラスタ全体でテーブルが作成されていることを確認してください:

SHOW TABLES IN uk;

┌─name────────────────┐
1. │ uk_price_paid_local │
   └─────────────────────┘

英国の不動産取引価格データを挿入する前に、各ホストから通常のテーブルにデータを挿入した際の動作を確認するため、簡単な実験を実施します。

いずれかのホストから次のクエリでテストデータベースとテーブルを作成します：

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 クエリを実行します:

INSERT INTO test.test_table (id, name) VALUES (1, 'Clicky McClickface');

clickhouse-02 に切り替えて、以下の INSERT クエリを実行します:

INSERT INTO test.test_table (id, name) VALUES (1, 'Alexey Milovidov');

次に、clickhouse-01 または clickhouse-02 から以下のクエリを実行してください:

-- clickhouse-01 から
SELECT * FROM test.test_table;
--   ┌─id─┬─name───────────────┐
-- 1.│  1 │ Clicky McClickface │
--   └────┴────────────────────┘

-- clickhouse-02 から
SELECT * FROM test.test_table;
--   ┌─id─┬─name───────────────┐
-- 1.│  1 │ Alexey Milovidov   │
--   └────┴────────────────────┘

ReplicatedMergeTreeテーブルとは異なり、その特定のホストのテーブルに挿入された行のみが返され、両方の行が返されることはありません。

2つのシャードにまたがるデータを読み取るには、全シャードに対するクエリを処理できるインターフェースが必要です。このインターフェースは、SELECTクエリ実行時に両シャードのデータを結合し、INSERTクエリ実行時には両シャードへデータを挿入します。

ClickHouseでは、このインターフェースは分散テーブルと呼ばれ、Distributedテーブルエンジンを使用して作成します。その仕組みを見ていきましょう。

分散テーブルの作成

以下のクエリを使用して分散テーブルを作成します:

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つの行がすべて返されます:

SELECT * FROM test.test_table_dist;

┌─id─┬─name───────────────┐
1. │  1 │ Alexey Milovidov   │
2. │  1 │ Clicky McClickface │
   └────┴────────────────────┘

UK不動産価格データについても同様に実行します。任意のホストクライアントから、以下のクエリを実行して、先ほどON CLUSTERで作成した既存のテーブルを使用した分散テーブルを作成してください：

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());

分散テーブルへのデータ挿入

いずれかのホストに接続し、データを挿入します：

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;

データが挿入されたら、分散テーブルを使用して行数を確認できます:

SELECT count(*)
FROM uk.uk_price_paid_distributed

┌──count()─┐
1. │ 30212555 │ -- 3021万
   └──────────┘

いずれかのホストで以下のクエリを実行すると、データがシャード間でほぼ均等に分散されていることが確認できます（挿入先のシャードの選択は rand() で設定されているため、結果が異なる可能性があります）:

-- clickhouse-01 より
SELECT count(*)
FROM uk.uk_price_paid_local
--    ┌──count()─┐
-- 1. │ 15107353 │ -- 15.11 million
--    └──────────┘

-- clickhouse-02 より
SELECT count(*)
FROM uk.uk_price_paid_local
--    ┌──count()─┐
-- 1. │ 15105202 │ -- 15.11 million
--    └──────────┘

ホストの1つに障害が発生した場合、何が起こるでしょうか。clickhouse-01をシャットダウンして、これをシミュレートしてみましょう:

docker stop clickhouse-01

以下を実行してホストがダウンしていることを確認します：

docker-compose ps

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 から、先ほど分散テーブルに対して実行したのと同じ select クエリを実行します：

SELECT count(*)
FROM uk.uk_price_paid_distributed

サーバーから例外を受信しました (version 25.5.2):
Code: 279. DB::Exception: Received from localhost:9000. DB::Exception: すべての接続試行が失敗しました。Log:

Code: 32. DB::Exception: ファイル終端後の読み取り試行。(ATTEMPT_TO_READ_AFTER_EOF) (version 25.5.2.47 (official build))
Code: 209. DB::NetException: Timeout: 接続タイムアウト: 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))
#highlight-next-line
Code: 198. DB::NetException: ホストのアドレスが見つかりません: 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))

: Remote 実行中。(ALL_CONNECTION_TRIES_FAILED)

残念ながら、このクラスタには耐障害性がありません。ホストの1つに障害が発生すると、クラスタは異常状態と見なされ、クエリは失敗します。これは、前の例で見たレプリケーテッドテーブルとは対照的です。レプリケーテッドテーブルでは、ホストの1つに障害が発生してもデータを挿入できました。

結論

このクラスタトポロジーの利点は、データが複数のホストに分散され、ノードあたりのストレージ使用量が半分になる点です。さらに重要な点として、クエリは両方のシャードにまたがって処理されるため、メモリ使用効率が高くなり、ホストあたりの I/O が削減されます。

このクラスタトポロジーの主な欠点は、もちろん、ホストの 1 つを失うとクエリを処理できなくなることです。

次の例では、スケーラビリティとフォールトトレランスの両方を提供する、2 つのシャードと 2 つのレプリカを持つクラスタのセットアップ方法を見ていきます。

前提条件​

ディレクトリ構造とテスト環境のセットアップ​

ClickHouseノードの設定​

サーバーのセットアップ​

ネットワーキングとロギング​

クラスター設定​

Keeper の設定​

マクロの設定​

ユーザー設定​

ClickHouse Keeperの設定​

Keeperのセットアップ​

セットアップのテスト​

データベースを作成する​

クラスタ上にテーブルを作成する​

分散テーブルの作成​

分散テーブルへのデータ挿入​

結論​