Google Cloud Storage と ClickHouse を連携する

Google Cloud Storage (GCS) バックエンドの MergeTree

Google Cloud 上で ClickHouse Cloud を使用している場合、このページは該当しません。サービスはすでに Google Cloud Storage を使用しているためです。GCS からデータを SELECT または INSERT したい場合は、gcs テーブル関数 を参照してください。

ClickHouse では、ストレージとコンピュートを分離したい場合、GCS が魅力的なストレージソリューションになると考えています。これを実現できるよう、MergeTree エンジンのストレージとして GCS を使用する機能をサポートしています。これにより、GCS のスケーラビリティとコスト面での利点に加え、MergeTree エンジンの insert とクエリパフォーマンスを活用できます。

​

GCS をバックエンドの MergeTree

​

ディスクの作成

GCS bucket をディスクとして利用するには、まず conf.d 配下のファイルで ClickHouse の設定内に宣言する必要があります。GCS ディスクの宣言例を以下に示します。この設定には、GCS の「ディスク」、cache、および GCS ディスク上に table を作成する際に DDL queries で指定するポリシーを設定するための複数のセクションが含まれています。各セクションについては、以下で説明します。

​

ストレージ構成 > disks > gcs

構成のこの部分はハイライトされたセクションに示されており、次の項目を指定します。

• S3 API を使用するため、ディスクの type は s3 です。
• GCS が提供するエンドポイント
• サービスアカウントの HMACキーとシークレット
• ローカルディスク上のメタデータパス

<clickhouse>
    <storage_configuration>
        <disks>
            <gcs>
                <support_batch_delete>true</support_batch_delete>
                <type>s3</type>
                <endpoint>https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/</endpoint>
                <access_key_id>SERVICE ACCOUNT HMAC KEY</access_key_id>
                <secret_access_key>SERVICE ACCOUNT HMAC SECRET</secret_access_key>
                <metadata_path>/var/lib/clickhouse/disks/gcs/</metadata_path>
            </gcs>
        </disks>
        <policies>
            <gcs_main>
                <volumes>
                    <main>
                        <disk>gcs</disk>
                    </main>
                </volumes>
            </gcs_main>
        </policies>
    </storage_configuration>
</clickhouse>

​

ストレージ構成 > disks > cache

以下で示す設定例では、ディスク gcs に 10Gi のメモリ cache を有効化しています。

<clickhouse>
    <storage_configuration>
        <disks>
            <gcs>
                <support_batch_delete>true</support_batch_delete>
                <type>s3</type>
                <endpoint>https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/</endpoint>
                <access_key_id>SERVICE ACCOUNT HMAC KEY</access_key_id>
                <secret_access_key>SERVICE ACCOUNT HMAC SECRET</secret_access_key>
                <metadata_path>/var/lib/clickhouse/disks/gcs/</metadata_path>
            </gcs>
            <gcs_cache>
                <type>cache</type>
                <disk>gcs</disk>
                <path>/var/lib/clickhouse/disks/gcs_cache/</path>
                <max_size>10Gi</max_size>
            </gcs_cache>
        </disks>
        <policies>
            <gcs_main>
                <volumes>
                    <main>
                        <disk>gcs_cache</disk>
                    </main>
                </volumes>
            </gcs_main>
        </policies>
    </storage_configuration>
</clickhouse>

​

ストレージ構成 > policies > gcs_main

ストレージ構成ポリシーでは、データの保存先を選択できます。以下で示すポリシーでは、gcs_main を指定することで、データをディスク gcs に保存できます。たとえば、CREATE TABLE ... SETTINGS storage_policy='gcs_main' のように指定します。

<clickhouse>
    <storage_configuration>
        <disks>
            <gcs>
                <support_batch_delete>true</support_batch_delete>
                <type>s3</type>
                <endpoint>https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/</endpoint>
                <access_key_id>SERVICE ACCOUNT HMAC KEY</access_key_id>
                <secret_access_key>SERVICE ACCOUNT HMAC SECRET</secret_access_key>
                <metadata_path>/var/lib/clickhouse/disks/gcs/</metadata_path>
            </gcs>
        </disks>
        <policies>
            <gcs_main>
                <volumes>
                    <main>
                        <disk>gcs</disk>
                    </main>
                </volumes>
            </gcs_main>
        </policies>
    </storage_configuration>
</clickhouse>

このディスク宣言に関連する設定の一覧は、こちらをご覧ください。

​

テーブルの作成

書き込み権限のあるバケットを使用するようにディスクを設定していることを前提とすると、以下の例のようなテーブルを作成できます。簡潔にするため、ここでは NYC タクシーのカラムの一部だけを使用し、データを GCS をバックエンドとするテーブルに直接書き込みます。

CREATE TABLE trips_gcs
(
   `trip_id` UInt32,
   `pickup_date` Date,
   `pickup_datetime` DateTime,
   `dropoff_datetime` DateTime,
   `pickup_longitude` Float64,
   `pickup_latitude` Float64,
   `dropoff_longitude` Float64,
   `dropoff_latitude` Float64,
   `passenger_count` UInt8,
   `trip_distance` Float64,
   `tip_amount` Float32,
   `total_amount` Float32,
   `payment_type` Enum8('UNK' = 0, 'CSH' = 1, 'CRE' = 2, 'NOC' = 3, 'DIS' = 4)
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(pickup_date)
ORDER BY pickup_datetime
SETTINGS storage_policy='gcs_main'

INSERT INTO trips_gcs SELECT trip_id, pickup_date, pickup_datetime, dropoff_datetime, pickup_longitude, pickup_latitude, dropoff_longitude, dropoff_latitude, passenger_count, trip_distance, tip_amount, total_amount, payment_type FROM s3('https://ch-nyc-taxi.s3.eu-west-3.amazonaws.com/tsv/trips_{0..9}.tsv.gz', 'TabSeparatedWithNames') LIMIT 1000000;

ハードウェアによっては、後者の100万行の insert の実行に数分かかる場合があります。進捗状況は system.processes テーブルで確認できます。行数は上限の1000万まで適宜調整し、いくつかのサンプルクエリを試してみてください。

SELECT passenger_count, avg(tip_amount) AS avg_tip, avg(total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;

​

レプリケーションへの対応

GCS ディスクを使用したレプリケーションは、ReplicatedMergeTree テーブルエンジンを使用して実現できます。詳細については、GCS を使用して 2 つの GCP リージョンにまたがって単一の分片をレプリケートする ガイドを参照してください。

​

さらに詳しく

Cloud ストレージ XML API は、Amazon Simple Storage Service (Amazon S3) などのサービスで動作する一部のツールやライブラリとの互換性があります。

スレッドの調整について詳しくは、パフォーマンスの最適化 を参照してください。

​

Google Cloud Storage (GCS) を使用する

ClickHouse Cloud ではデフォルトでオブジェクトストレージが使用されるため、ClickHouse Cloud を使用している場合はこの手順に従う必要はありません。

​

デプロイメントを計画する

このチュートリアルでは、Google Cloud 上で稼働し、ClickHouse のストレージディスクの「type」として Google Cloud Storage (GCS) を使用する、レプリケーション構成の ClickHouse デプロイメントについて説明します。

このチュートリアルでは、Google Cloud Engine VM に ClickHouse サーバー ノードをデプロイし、各ノードに対応する GCS バケットをストレージとして関連付けます。レプリケーションは、同じく VM としてデプロイされた一連の ClickHouse Keeper ノードによって調整されます。

高可用性の要件例:

• 2 つの GCP リージョンに 2 つの ClickHouse サーバー ノード
• 2 つの GCS バケット。2 つの ClickHouse サーバー ノードと同じリージョンにデプロイ
• 3 つの ClickHouse Keeper ノード。このうち 2 つは ClickHouse サーバー ノードと同じリージョンにデプロイします。3 つ目は最初の 2 つの Keeper ノードのいずれかと同じリージョンでもかまいませんが、可用性ゾーンは別にする必要があります。

ClickHouse Keeper が機能するには 2 ノード必要なため、高可用性を確保するには 3 ノード必要です。

​

仮想マシンを準備する

3 つのリージョンに 5 台の VM をデプロイします。

Region	ClickHouse Server	Bucket	ClickHouse Keeper
1	chnode1	bucket_regionname	keepernode1
2	chnode2	bucket_regionname	keepernode2
3 *			keepernode3

* これは、1 または 2 と同じリージョン内の別のアベイラビリティゾーンにすることも可能です。

​

ClickHouseをデプロイ

2台のホストにClickHouseをデプロイします。サンプル構成では、これらのホストの名前は chnode1、chnode2 です。

chnode1 は1つ目の GCP リージョンに、chnode2 は2つ目のリージョンに配置します。このガイドでは、Compute Engine の VM と GCS バケットの両方に us-east1 と us-east4 を使用します。

clickhouse server は設定が完了するまで起動しないでください。インストールだけを行ってください。

ClickHouse サーバーノードでデプロイ手順を実行する際は、インストール手順を参照してください。

​

ClickHouse Keeper をデプロイする

3 台のホストに ClickHouse Keeper をデプロイします。サンプル構成では、これらのホストは keepernode1、keepernode2、keepernode3 という名前です。keepernode1 は chnode1 と同じリージョンに、keepernode2 は chnode2 と同じリージョンにデプロイできます。keepernode3 はどちらのリージョンにもデプロイできますが、そのリージョン内の ClickHouse ノードとは異なるアベイラビリティゾーンに配置する必要があります。

ClickHouse Keeper ノードでデプロイ手順を実施する際は、インストール手順を参照してください。

​

2 つのバケットを作成する

高可用性のため、2 台の ClickHouseサーバーは異なるリージョンに配置します。各サーバーには、同じリージョン内に GCS バケットが 1 つ必要です。

Cloud Storage > Buckets で CREATE BUCKET を選択します。このチュートリアルでは、us-east1 と us-east4 にそれぞれ 1 つずつ、合計 2 つのバケットを作成します。バケットは単一リージョン、Standard ストレージクラス、非公開に設定します。求められたら、公開アクセス防止を有効にしてください。フォルダは作成しないでください。ClickHouse がストレージに書き込むときに作成されます。

バケットと HMAC キーの作成手順を順を追って確認したい場合は、Create GCS buckets and an HMAC key を展開して、その手順に従ってください。

GCS バケットと HMAC キーを作成する

​

ch_bucket_us_east1

​

ch_bucket_us_east4

​

アクセスキーを生成する

​

サービス アカウントの HMAC キーとシークレットを作成する

Cloud Storage > Settings > Interoperability を開き、既存の Access key を選択するか、CREATE A KEY FOR A SERVICE ACCOUNT を選択します。このガイドでは、新しいサービス アカウント用に新しいキーを作成する手順を説明します。

​

新しいサービス アカウントを追加する

既存のサービス アカウントがないプロジェクトの場合は、CREATE NEW ACCOUNT を選択します。

サービス アカウントの作成は 3 つの手順で行います。最初の手順では、アカウントにわかりやすい名前、ID、説明を設定します。

Interoperability の設定ダイアログでは、IAM role Storage Object Admin を使用することを推奨します。2 番目の手順でこのロールを選択してください。

3 番目の手順は任意であり、このガイドでは使用しません。ポリシーに応じて、ユーザーにこれらの権限を付与できます。

サービス アカウントの HMAC キーが表示されます。この情報は ClickHouse の設定で使用するため、保存しておいてください。

​

ClickHouse Keeper を設定する

すべての ClickHouse Keeper ノードは、server_id の行 (以下で最初にハイライトされている行) を除き、同じ設定ファイルを使用します。ファイル内のホスト名を使用環境の ClickHouse Keeper サーバーのものに置き換え、各サーバーで server_id が raft_configuration 内の対応する server エントリに一致するよう設定してください。この例では server_id が 3 に設定されているため、raft_configuration 内の対応する行をハイライトしています。

• ファイル内のホスト名を実際のものに置き換え、それらが ClickHouse サーバー ノードおよび Keeper ノードから名前解決できることを確認してください
• ファイルを所定の場所にコピーしてください (各 Keeper サーバーでは /etc/clickhouse-keeper/keeper_config.xml)
• 各マシンで、raft_configuration 内のエントリ番号に基づいて server_id を編集してください

/etc/clickhouse-keeper/keeper_config.xml

<clickhouse>
    <logger>
        <level>trace</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>
        <server_id>3</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>warning</raft_logs_level>
        </coordination_settings>

        <raft_configuration>
            <server>
                <id>1</id>
                <hostname>keepernode1.us-east1-b.c.clickhousegcs-374921.internal</hostname>
                <port>9234</port>
            </server>
            <server>
                <id>2</id>
                <hostname>keepernode2.us-east4-c.c.clickhousegcs-374921.internal</hostname>
                <port>9234</port>
            </server>
            <server>
                <id>3</id>
                <hostname>keepernode3.us-east5-a.c.clickhousegcs-374921.internal</hostname>
                <port>9234</port>
            </server>
        </raft_configuration>
    </keeper_server>
</clickhouse>

​

ClickHouse server の設定

ベストプラクティス

このガイドの一部の手順では、設定ファイルを /etc/clickhouse-server/config.d/ に配置する必要があります。これは、Linux システムで設定の上書きファイルを配置する既定の場所です。これらのファイルをこのディレクトリに配置すると、ClickHouse はその内容をデフォルト設定にマージします。これらのファイルを config.d ディレクトリに配置しておけば、アップグレード時に設定が失われるのを防げます。

​

ネットワーク

デフォルトでは、ClickHouse はループバックインターフェイスで待ち受けます。レプリケーション構成では、マシン間のネットワーク接続が必要です。すべてのインターフェイスで待ち受けるようにします。

/etc/clickhouse-server/config.d/network.xml

<clickhouse>
    <listen_host>0.0.0.0</listen_host>
</clickhouse>

​

リモート ClickHouse Keeper サーバー

レプリケーションは ClickHouse Keeper によって管理されます。この設定ファイルでは、ホスト名とポート番号で ClickHouse Keeper ノードを指定します。

• ホスト名を使用する Keeper ホストに合わせて編集します

/etc/clickhouse-server/config.d/use-keeper.xml

<clickhouse>
    <zookeeper>
        <node index="1">
            <host>keepernode1.us-east1-b.c.clickhousegcs-374921.internal</host>
            <port>9181</port>
        </node>
        <node index="2">
            <host>keepernode2.us-east4-c.c.clickhousegcs-374921.internal</host>
            <port>9181</port>
        </node>
        <node index="3">
            <host>keepernode3.us-east5-a.c.clickhousegcs-374921.internal</host>
            <port>9181</port>
        </node>
    </zookeeper>
</clickhouse>

​

リモート ClickHouse サーバー

このファイルでは、クラスター内の各 ClickHouse サーバーのホスト名とポートを設定します。デフォルトの設定ファイルにはサンプルのクラスター定義が含まれているため、完全に設定されたクラスターだけを表示するには、remote_servers エントリに replace="true" タグを追加します。これにより、この設定をデフォルト設定とマージした際、remote_servers セクションに追記するのではなく、そのセクション全体を置き換えるようになります。

• ホスト名に合わせてファイルを編集し、それらが ClickHouse サーバーノードから名前解決できることを確認してください

/etc/clickhouse-server/config.d/remote-servers.xml

<clickhouse>
    <remote_servers replace="true">
        <cluster_1S_2R>
            <shard>
                <replica>
                    <host>chnode1.us-east1-b.c.clickhousegcs-374921.internal</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>chnode2.us-east4-c.c.clickhousegcs-374921.internal</host>
                    <port>9000</port>
                </replica>
            </shard>
        </cluster_1S_2R>
    </remote_servers>
</clickhouse>

​

レプリカの識別

このファイルでは、ClickHouse Keeper の path に関連する設定を行います。具体的には、データがどのレプリカに属しているかを識別するためのマクロを設定します。片方のサーバーではレプリカを replica_1、もう片方のサーバーでは replica_2 と指定する必要があります。名前は変更可能です。たとえば、一方のレプリカを South Carolina に、もう一方を Northern Virginia に保存する場合、値は carolina と virginia にできます。ただし、各マシンで異なる名前を指定してください。

/etc/clickhouse-server/config.d/macros.xml

<clickhouse>
    <distributed_ddl>
            <path>/clickhouse/task_queue/ddl</path>
    </distributed_ddl>
    <macros>
        <cluster>cluster_1S_2R</cluster>
        <shard>1</shard>
        <replica>replica_1</replica>
    </macros>
</clickhouse>

​

GCS のストレージ

ClickHouse のストレージ構成には disks と policies が含まれます。以下で構成するディスクは gcs という名前で、type は s3 です。type が s3 なのは、ClickHouse が GCS バケットを AWS S3 バケットのように扱ってアクセスするためです。この構成は 2 つ必要で、それぞれの ClickHouse サーバー ノードに 1 つずつ配置します。

以下の構成では、次の置換を行ってください。

これらの置換は、2 つの ClickHouse サーバー ノードで異なります。

• REPLICA 1 BUCKET は、server と同じリージョンにあるバケット名に設定してください
• REPLICA 1 FOLDER は、一方の server では replica_1 に、もう一方では replica_2 に変更してください

次の置換は 2 つのノードで共通です。

• access_key_id は、先ほど生成した HMAC Key に設定してください
• secret_access_key は、先ほど生成した HMAC Secret に設定してください

/etc/clickhouse-server/config.d/storage.xml

<clickhouse>
    <storage_configuration>
        <disks>
            <gcs>
                <support_batch_delete>true</support_batch_delete>
                <type>s3</type>
                <endpoint>https://storage.googleapis.com/REPLICA 1 BUCKET/REPLICA 1 FOLDER/</endpoint>
                <access_key_id>SERVICE ACCOUNT HMAC KEY</access_key_id>
                <secret_access_key>SERVICE ACCOUNT HMAC SECRET</secret_access_key>
                <metadata_path>/var/lib/clickhouse/disks/gcs/</metadata_path>
            </gcs>
            <cache>
                <type>cache</type>
                <disk>gcs</disk>
                <path>/var/lib/clickhouse/disks/gcs_cache/</path>
                <max_size>10Gi</max_size>
            </cache>
        </disks>
        <policies>
            <gcs_main>
                <volumes>
                    <main>
                        <disk>gcs</disk>
                    </main>
                </volumes>
            </gcs_main>
        </policies>
    </storage_configuration>
</clickhouse>

​

ClickHouse Keeper を起動する

ご利用のオペレーティングシステムに応じたコマンドを使用してください。たとえば次のとおりです。

sudo systemctl enable clickhouse-keeper
sudo systemctl start clickhouse-keeper
sudo systemctl status clickhouse-keeper

​

ClickHouse Keeper のステータスを確認する

netcat を使って ClickHouse Keeper にコマンドを送信します。たとえば、mntr は ClickHouse Keeper クラスターの状態を返します。各 Keeper ノードでこのコマンドを実行すると、1 つが leader、残り 2 つが followers であることを確認できます。

echo mntr | nc localhost 9181

zk_version      v22.7.2.15-stable-f843089624e8dd3ff7927b8a125cf3a7a769c069
zk_avg_latency  0
zk_max_latency  11
zk_min_latency  0
zk_packets_received     1783
zk_packets_sent 1783
zk_num_alive_connections        2
zk_outstanding_requests 0
zk_server_state leader
zk_znode_count  135
zk_watch_count  8
zk_ephemerals_count     3
zk_approximate_data_size        42533
zk_key_arena_size       28672
zk_latest_snapshot_size 0
zk_open_file_descriptor_count   182
zk_max_file_descriptor_count    18446744073709551615
zk_followers    2
zk_synced_followers     2

​

ClickHouseサーバーを起動する

chnode1 と chnode で次を実行します:

sudo service clickhouse-server start

sudo service clickhouse-server status

​

確認

​

ディスク設定を確認する

system.disks には、各ディスクのレコードが含まれているはずです。

• default
• gcs
• cache

SELECT *
FROM system.disks
FORMAT Vertical

Row 1:
──────
name:             cache
path:             /var/lib/clickhouse/disks/gcs/
free_space:       18446744073709551615
total_space:      18446744073709551615
unreserved_space: 18446744073709551615
keep_free_space:  0
type:             s3
is_encrypted:     0
is_read_only:     0
is_write_once:    0
is_remote:        1
is_broken:        0
cache_path:       /var/lib/clickhouse/disks/gcs_cache/

Row 2:
──────
name:             default
path:             /var/lib/clickhouse/
free_space:       6555529216
total_space:      10331889664
unreserved_space: 6555529216
keep_free_space:  0
type:             local
is_encrypted:     0
is_read_only:     0
is_write_once:    0
is_remote:        0
is_broken:        0
cache_path:

Row 3:
──────
name:             gcs
path:             /var/lib/clickhouse/disks/gcs/
free_space:       18446744073709551615
total_space:      18446744073709551615
unreserved_space: 18446744073709551615
keep_free_space:  0
type:             s3
is_encrypted:     0
is_read_only:     0
is_write_once:    0
is_remote:        1
is_broken:        0
cache_path:

3 rows in set. Elapsed: 0.002 sec.

​

クラスターで作成したテーブルが両方のノードに作成されていることを確認する

create table trips on cluster 'cluster_1S_2R' (
 `trip_id` UInt32,
 `pickup_date` Date,
 `pickup_datetime` DateTime,
 `dropoff_datetime` DateTime,
 `pickup_longitude` Float64,
 `pickup_latitude` Float64,
 `dropoff_longitude` Float64,
 `dropoff_latitude` Float64,
 `passenger_count` UInt8,
 `trip_distance` Float64,
 `tip_amount` Float32,
 `total_amount` Float32,
 `payment_type` Enum8('UNK' = 0, 'CSH' = 1, 'CRE' = 2, 'NOC' = 3, 'DIS' = 4))
ENGINE = ReplicatedMergeTree
PARTITION BY toYYYYMM(pickup_date)
ORDER BY pickup_datetime
SETTINGS storage_policy='gcs_main'

┌─host───────────────────────────────────────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐
│ chnode2.us-east4-c.c.gcsqa-375100.internal │ 9000 │      0 │       │                   1 │                1 │
└────────────────────────────────────────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘
┌─host───────────────────────────────────────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐
│ chnode1.us-east1-b.c.gcsqa-375100.internal │ 9000 │      0 │       │                   0 │                0 │
└────────────────────────────────────────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘

2 rows in set. Elapsed: 0.641 sec.

​

データを挿入できることを確認する

INSERT INTO trips SELECT
    trip_id,
    pickup_date,
    pickup_datetime,
    dropoff_datetime,
    pickup_longitude,
    pickup_latitude,
    dropoff_longitude,
    dropoff_latitude,
    passenger_count,
    trip_distance,
    tip_amount,
    total_amount,
    payment_type
FROM s3('https://ch-nyc-taxi.s3.eu-west-3.amazonaws.com/tsv/trips_{0..9}.tsv.gz', 'TabSeparatedWithNames')
LIMIT 1000000

​

テーブルでストレージポリシー gcs_main が使用されていることを確認します。

SELECT
    engine,
    data_paths,
    metadata_path,
    storage_policy,
    formatReadableSize(total_bytes)
FROM system.tables
WHERE name = 'trips'
FORMAT Vertical

Row 1:
──────
engine:                          ReplicatedMergeTree
data_paths:                      ['/var/lib/clickhouse/disks/gcs/store/631/6315b109-d639-4214-a1e7-afbd98f39727/']
metadata_path:                   /var/lib/clickhouse/store/e0f/e0f3e248-7996-44d4-853e-0384e153b740/trips.sql
storage_policy:                  gcs_main
formatReadableSize(total_bytes): 36.42 MiB

1 row in set. Elapsed: 0.002 sec.

​

Google Cloud Console で確認する

バケットを見ると、各バケットに storage.xml の設定ファイルで使用した名前のフォルダが作成されていることがわかります。フォルダを展開すると、データのパーティションを表す多数のファイルが表示されます。

​

レプリカ1用のバケット

​

レプリカ2用のバケット