Intégrer Google Cloud Storage à ClickHouse

MergeTree reposant sur Google Cloud Storage (GCS)

Si vous utilisez ClickHouse Cloud sur Google Cloud, cette page ne vous concerne pas, car vos services utilisent déjà Google Cloud Storage. Si vous cherchez à SELECT ou INSERT des données depuis GCS, veuillez consulter la fonction de table gcs.

ClickHouse considère que GCS est une solution de stockage intéressante si vous souhaitez dissocier le stockage et la puissance de calcul. Pour cela, la prise en charge de GCS comme couche de stockage pour le moteur MergeTree est disponible. Vous pouvez ainsi bénéficier de la scalabilité et des avantages en termes de coût de GCS, tout en conservant les performances d’insertion et de requête du moteur MergeTree.

​

MergeTree avec stockage sur GCS

​

Création d’un disque

Pour utiliser un bucket GCS comme disque, il faut d’abord le déclarer dans la configuration de ClickHouse, dans un fichier situé sous conf.d. Un exemple de déclaration d’un disque GCS est présenté ci-dessous. Cette configuration comprend plusieurs sections permettant de configurer le « disque » GCS, le cache et la policy spécifiée dans les requêtes DDL lorsque des tables doivent être créées sur le disque GCS. Chacun de ces éléments est décrit ci-dessous.

​

configuration du stockage > disks > gcs

Cette partie de la configuration est présentée dans la section mise en évidence et indique :

• Le type du disque est s3, car l’API S3 est utilisée.
• L’endpoint fourni par GCS
• La clé HMAC et le secret du compte de service
• Le chemin des métadonnées sur le disque local

<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>

​

Configuration du stockage > disks > cache

L’exemple de configuration ci-dessous active un cache mémoire de 10 Gi pour le disque gcs.

<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>

​

Configuration du stockage > politiques > gcs_main

Les politiques de stockage permettent de choisir où les données sont stockées. La politique mise en évidence ci-dessous permet de stocker les données sur le disque gcs en spécifiant la politique gcs_main. Par exemple, 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>

La liste complète des paramètres applicables à cette déclaration de disque est disponible ici.

​

Création d’une table

Si votre disque est configuré pour utiliser un bucket avec un accès en écriture, vous devriez pouvoir créer une table comme dans l’exemple ci-dessous. Par souci de concision, nous utilisons un sous-ensemble des colonnes des taxis de New York et envoyons les données directement vers la table adossée à 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;

Selon la configuration matérielle, cette dernière insertion de 1m lignes peut prendre quelques minutes. Vous pouvez en suivre la progression dans la table system.processes. N’hésitez pas à ajuster le nombre de lignes jusqu’à 10m et à essayer quelques exemples de requêtes.

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

​

Gestion de la réplication

La réplication avec des disques GCS peut être mise en œuvre à l’aide du moteur de table ReplicatedMergeTree. Consultez le guide répliquer un shard unique sur deux régions GCP à l’aide de GCS pour en savoir plus.

​

En savoir plus

L’Cloud Storage XML API est compatible avec certains outils et certaines bibliothèques qui fonctionnent avec des services tels qu’Amazon Simple Storage Service (Amazon S3).

Pour en savoir plus sur l’ajustement des threads, consultez Optimizing for Performance.

​

Utiliser Google Cloud Storage (GCS)

Le stockage objet est utilisé par défaut dans ClickHouse Cloud. Vous n’avez pas besoin de suivre cette procédure si vous utilisez ClickHouse Cloud.

​

Planifier le déploiement

Ce tutoriel décrit un déploiement ClickHouse répliqué exécuté dans Google Cloud et utilisant Google Cloud Storage (GCS) comme « type » de disque de stockage ClickHouse.

Dans ce tutoriel, vous déploierez des nœuds du serveur ClickHouse sur des VM Google Cloud Engine, chacun avec un bucket GCS associé pour le stockage. La réplication est coordonnée par un ensemble de nœuds ClickHouse Keeper, eux aussi déployés sous forme de VM.

Exemples d’exigences pour assurer la haute disponibilité :

• Deux nœuds du serveur ClickHouse, dans deux régions GCP
• Deux buckets GCS, déployés dans les mêmes régions que les deux nœuds du serveur ClickHouse
• Trois nœuds ClickHouse Keeper, dont deux sont déployés dans les mêmes régions que les nœuds du serveur ClickHouse. Le troisième peut se trouver dans la même région que l’un des deux premiers nœuds Keeper, mais dans une zone de disponibilité différente.

ClickHouse Keeper nécessite deux nœuds pour fonctionner, d’où la nécessité d’en prévoir trois pour assurer la haute disponibilité.

​

Préparer des machines virtuelles

Déployez cinq VM dans trois régions :

Région	ClickHouse Server	Bucket	ClickHouse Keeper
1	chnode1	bucket_regionname	keepernode1
2	chnode2	bucket_regionname	keepernode2
3 *			keepernode3

* Il peut s’agir d’une autre zone de disponibilité dans la même région que 1 ou 2.

​

Déployer ClickHouse

Déployez ClickHouse sur deux hôtes, appelés chnode1 et chnode2 dans les exemples de configuration.

Placez chnode1 dans une région GCP et chnode2 dans une autre. Dans ce guide, us-east1 et us-east4 sont utilisés pour les VM Compute Engine ainsi que pour les buckets GCS.

Ne démarrez pas clickhouse server tant qu’il n’est pas configuré. Contentez-vous de l’installer.

Consultez les instructions d’installation lorsque vous effectuez les étapes de déploiement sur les nœuds serveur ClickHouse.

​

Déployer ClickHouse Keeper

Déployez ClickHouse Keeper sur trois hôtes ; dans les configurations d’exemple, ils sont nommés keepernode1, keepernode2 et keepernode3. keepernode1 peut être déployé dans la même région que chnode1, keepernode2 avec chnode2, et keepernode3 dans l’une ou l’autre région, mais dans une zone de disponibilité différente de celle du nœud ClickHouse de cette région.

Consultez les instructions d’installation lorsque vous effectuez les étapes de déploiement sur les nœuds ClickHouse Keeper.

​

Créer deux buckets

Les deux serveurs ClickHouse seront situés dans des régions différentes pour assurer la haute disponibilité. Chacun disposera d’un bucket GCS dans la même région.

Dans Cloud Storage > Buckets, choisissez CREATE BUCKET. Pour ce tutoriel, deux buckets sont créés, un dans us-east1 et un dans us-east4. Les buckets sont monorégionaux, de classe de stockage standard et non publics. Lorsque cela vous est demandé, activez la prévention de l’accès public. Ne créez pas de dossiers ; ils seront créés lorsque ClickHouse écrira dans le stockage.

Si vous avez besoin d’instructions pas à pas pour créer des buckets et une clé HMAC, développez Create GCS buckets and an HMAC key et suivez les instructions :

Créer des buckets GCS et une clé HMAC

​

ch_bucket_us_east1

​

ch_bucket_us_east4

​

Générer une clé d’accès

​

Créer une clé HMAC et un secret pour un compte de service

Ouvrez Cloud Storage > Settings > Interoperability et choisissez soit une Access key existante, soit CREATE A KEY FOR A SERVICE ACCOUNT. Ce guide décrit la procédure de création d’une nouvelle clé pour un nouveau compte de service.

​

Ajouter un nouveau compte de service

S’il s’agit d’un projet sans compte de service existant, cliquez sur CREATE NEW ACCOUNT.

La création du compte de service se fait en trois étapes. Lors de la première, donnez au compte un nom, un ID et une description explicites.

Dans la boîte de dialogue des paramètres Interoperability, le rôle IAM Storage Object Admin est recommandé ; sélectionnez-le à la deuxième étape.

La troisième étape est facultative et n’est pas utilisée dans ce guide. Vous pouvez autoriser des utilisateurs à disposer de ces privilèges selon vos politiques.

La clé HMAC du compte de service s’affichera. Enregistrez ces informations, car elles seront utilisées dans la configuration de ClickHouse.

​

Configurer ClickHouse Keeper

Tous les nœuds ClickHouse Keeper utilisent le même fichier de configuration, à l’exception de la ligne server_id (première ligne mise en évidence ci-dessous). Modifiez le fichier en y indiquant les noms d’hôte de vos serveurs ClickHouse Keeper, puis, sur chacun des serveurs, définissez server_id de façon à ce qu’il corresponde à l’entrée server appropriée dans raft_configuration. Comme, dans cet exemple, server_id est défini sur 3, nous avons mis en évidence les lignes correspondantes dans raft_configuration.

• Modifiez le fichier avec vos noms d’hôte et assurez-vous qu’ils sont résolus depuis les nœuds de serveur ClickHouse et les nœuds Keeper
• Copiez le fichier à l’emplacement approprié (/etc/clickhouse-keeper/keeper_config.xml sur chacun des serveurs Keeper)
• Modifiez server_id sur chaque machine en fonction de son numéro d’entrée dans raft_configuration

/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>

​

Configurer le serveur ClickHouse

bonne pratique

Certaines étapes de ce guide vous demanderont de placer un fichier de configuration dans /etc/clickhouse-server/config.d/. Il s’agit de l’emplacement par défaut, sur les systèmes Linux, des fichiers de surcharge de configuration. Lorsque vous placez ces fichiers dans ce répertoire, ClickHouse fusionne leur contenu avec la configuration par défaut. En plaçant ces fichiers dans le répertoire config.d, vous éviterez de perdre votre configuration lors d’une mise à niveau.

​

Réseau

Par défaut, ClickHouse écoute sur l’interface de bouclage ; dans une configuration répliquée, la communication réseau entre les machines est nécessaire. Écoutez sur toutes les interfaces :

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

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

​

Serveurs ClickHouse Keeper distants

La réplication est coordonnée par ClickHouse Keeper. Ce fichier de configuration identifie les nœuds ClickHouse Keeper par leur nom d’hôte et leur numéro de port.

• Modifiez les noms d’hôte pour qu’ils correspondent à ceux de vos hôtes 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>

​

Serveurs ClickHouse distants

Ce fichier configure le nom d’hôte et le port de chaque serveur ClickHouse du cluster. Le fichier de configuration par défaut contient des définitions de cluster d’exemple ; pour n’afficher que les clusters entièrement configurés, l’attribut replace="true" est ajouté à l’entrée remote_servers afin que, lorsque cette configuration est fusionnée avec la configuration par défaut, elle remplace la section remote_servers au lieu de s’y ajouter.

• Modifiez le fichier avec vos noms d’hôte et assurez-vous qu’ils peuvent être résolus depuis les nœuds serveur 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>

​

Identification des répliques

Ce fichier configure les paramètres liés au chemin ClickHouse Keeper. Plus précisément, les macros utilisées pour identifier à quelle réplique appartiennent les données. Sur un serveur, la réplique doit être spécifiée comme replica_1, et sur l’autre serveur comme replica_2. Les noms peuvent être modifiés ; en reprenant notre exemple où une réplique est stockée en Caroline du Sud et l’autre en Virginie du Nord, les valeurs pourraient être carolina et virginia ; assurez-vous simplement qu’ils sont différents sur chaque machine.

/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>

​

Stockage dans GCS

La configuration de stockage de ClickHouse inclut disks et policies. Le disque configuré ci-dessous est nommé gcs et est de type s3. Le type est s3, car ClickHouse accède au bucket GCS comme s’il s’agissait d’un bucket AWS S3. Deux copies de cette configuration seront nécessaires, une pour chacun des deux nœuds du serveur ClickHouse.

Ces substitutions doivent être effectuées dans la configuration ci-dessous.

Ces substitutions diffèrent entre les deux nœuds du serveur ClickHouse :

• REPLICA 1 BUCKET doit être défini sur le nom du bucket situé dans la même région que le serveur
• REPLICA 1 FOLDER doit être remplacé par replica_1 sur l’un des serveurs, et par replica_2 sur l’autre

Ces substitutions sont identiques sur les deux nœuds :

• access_key_id doit être défini sur la clé HMAC générée précédemment
• secret_access_key doit être défini sur le secret HMAC généré précédemment

/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>

​

Démarrer ClickHouse Keeper

Utilisez les commandes adaptées à votre système d’exploitation, par exemple :

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

​

Vérifier l’état de ClickHouse Keeper

Envoyez des commandes à ClickHouse Keeper avec netcat. Par exemple, mntr renvoie l’état du cluster ClickHouse Keeper. Si vous exécutez la commande sur chacun des nœuds Keeper, vous verrez que l’un est leader et que les deux autres sont des 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

​

Démarrer le serveur ClickHouse

Sur chnode1 et chnode, exécutez :

sudo service clickhouse-server start

sudo service clickhouse-server status

​

Vérification

​

Vérifier la configuration des disques

system.disks doit contenir une entrée pour chaque disque :

• 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.

​

Vérifiez que les tables créées sur le cluster le sont sur les deux nœuds

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.

​

Vérifiez que des données peuvent être insérées

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

​

Vérifiez que la politique de stockage gcs_main est utilisée pour la table.

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.

​

Vérifier dans la console Google Cloud

En examinant les buckets, vous verrez qu’un dossier a été créé dans chacun d’eux avec le nom utilisé dans le fichier de configuration storage.xml. Développez ces dossiers et vous verrez de nombreux fichiers, correspondant aux partitions de données.

​

Bucket de la réplique 1

​

Bucket de la réplique deux