- Le stockage objet Amazon S3.
- Azure Blob Storage.
- Non pris en charge : Hadoop Distributed File System (HDFS)
ClickHouse prend également en charge des moteurs de table externes, qui diffèrent de
l’option de stockage externe décrite sur cette page, car ils permettent de lire des données
stockées dans un format de fichier générique (comme Parquet). Cette page décrit
la configuration du stockage pour les tables de la famille
MergeTree ou de la famille Log.- pour utiliser des données stockées sur des disques
Amazon S3, utilisez le moteur de table S3. - pour utiliser des données stockées dans Azure Blob Storage, utilisez le moteur de table AzureBlobStorage.
- pour utiliser des données dans Hadoop Distributed File System (non pris en charge), utilisez le moteur de table HDFS.
Configurer le stockage externe
MergeTree et Log
peuvent stocker les données dans S3, AzureBlobStorage, HDFS (non pris en charge) en utilisant respectivement un disque de type s3,
azure_blob_storage, hdfs (non pris en charge).
La configuration du disque nécessite :
- Une section
type, égale à l’une des valeurss3,azure_blob_storage,hdfs(non pris en charge),local_blob_storage,web. - La configuration d’un type spécifique de stockage externe.
- Un
typeégal àobject_storage object_storage_type, égal à l’une des valeurss3,azure_blob_storage(ou simplementazureà partir de24.3),hdfs(non pris en charge),local_blob_storage(ou simplementlocalà partir de24.3),web.
Il est également possible de spécifier
metadata_type (sa valeur par défaut est local) ; il peut aussi être défini sur plain, web et, à partir de 24.4, plain_rewritable.
L’utilisation du type de métadonnées plain est décrite dans la section sur le stockage plain. Le type de métadonnées web ne peut être utilisé qu’avec le type de stockage objet web. Le type de métadonnées local stocke les fichiers de métadonnées localement (chaque fichier de métadonnées contient la correspondance avec les fichiers du stockage objet, ainsi que des méta-informations supplémentaires à leur sujet).
Par exemple :
24.1) :
MergeTree,
ajoutez la section suivante au fichier de configuration :
disk à la place de storage_policy. Dans ce cas, il n’est pas nécessaire
d’inclure la section storage_policy dans le fichier de configuration : une section disk
suffit.
refresh_parts_interval et table_disk
refresh_parts_interval active le rechargement périodique de la liste des data parts depuis le stockage sous-jacent (par ex. pour prendre en compte des parts écrites en externe). La distinction essentielle est la suivante : métadonnées partagées entre les répliques vs métadonnées locales à chaque réplique (par ex. S3 avec des métadonnées locales par réplique). Les nouvelles parts ne seront visibles par toutes les répliques que si les métadonnées sont partagées. Le simple recours au stockage objet n’implique pas des métadonnées partagées.
-
Le stockage objet (par ex.
disk = 's3') n’implique pas des métadonnées partagées. Lorsque les métadonnées sont stockées localement sur chaque réplique (par défaut), chaque réplique gère indépendamment ses pointeurs vers les blobs du stockage objet. Les modifications effectuées sur une réplique ne sont pas visibles sur les autres. Dans ce cas,refresh_parts_intervalne rend pas les nouvelles parts visibles d’une réplique à l’autre, car les métadonnées lues par chaque réplique sont locales. -
Le rechargement automatique des parts exige que les métadonnées du filesystem soient partagées (ou que la table utilise des métadonnées readonly propres à la table, afin que ce rechargement soit applicable). Définir
table_disk = trueavec un disque local à la table (par ex.SETTINGS disk = disk(type=object_storage, ...), table_disk = true) est un moyen d’obtenir la sémantique correcte : la table gère le cycle de vie des métadonnées et le stockage est traité comme readonly ; ainsi,refresh_parts_intervals’exécute et les parts ajoutées en externe peuvent être découvertes. -
Avec un disque défini globalement (par ex.
disk = 's3'dansstorage_configuration) et les métadonnées locales par défaut, chaque réplique possède son propre état de métadonnées. Même si les blobs se trouvent dans S3, le stockage n’est pas considéré comme partagé du point de vue derefresh_parts_interval, et les nouvelles parts créées en dehors de ClickHouse ou sur une autre réplique ne seront pas détectées.
table_disk = true, comme ci-dessus. Si vous vous appuyez uniquement sur refresh_parts_interval avec des métadonnées locales à chaque réplique, les parts ne seront pas rechargées comme prévu.
refresh_parts_interval n’est pas utilisé pour les tables ReplicatedMergeTree.
Les tables répliquées synchronisent déjà les parts via le mécanisme de réplication.
Ce paramètre s’applique uniquement aux tables MergeTree non répliquées dans lesquelles des parts sont écrites en externe et où un rechargement des métadonnées est nécessaire.Configuration dynamique
CREATE/ATTACH.
La requête d’exemple suivante s’appuie sur la configuration dynamique des disques
ci-dessus et montre comment utiliser un disque local pour mettre en cache les
données d’une table stockée à une URL.
type=web est imbriqué dans
le disque de type=cache.
L’exemple utilise
type=web, mais tout type de disque peut être configuré comme dynamique,
y compris un disque local. Les disques locaux exigent qu’un argument path soit défini dans le
paramètre de config du server custom_local_disks_base_directory, qui n’a pas de
valeur par défaut ; définissez donc également ce paramètre lorsque vous utilisez un disque local.web est issu du fichier de configuration du serveur :
Utiliser le stockage S3
Paramètres requis
Paramètres facultatifs
Google Cloud Storage (GCS) est également pris en charge via le type
s3. Voir GCS backed MergeTree.Utilisation du stockage simple
22.10, un nouveau type de disque s3_plain a été introduit. Il fournit un stockage en écriture unique.
Ses paramètres de configuration sont les mêmes que pour le type de disque s3.
Contrairement au type de disque s3, il stocke les données telles quelles. Autrement dit,
au lieu d’utiliser des noms de blob générés aléatoirement, il utilise des noms de fichiers classiques
(de la même manière que ClickHouse stocke les fichiers sur un disque local) et ne stocke
aucune métadonnée localement. Par exemple, ces métadonnées sont déduites des données sur s3.
Ce type de disque permet de conserver une version statique de la table, car il ne
permet pas d’exécuter de merges sur les données existantes et n’autorise pas l’insertion de nouvelles
données. Un cas d’utilisation de ce type de disque consiste à y créer des sauvegardes, ce qui peut être fait
via BACKUP TABLE data TO Disk('plain_disk_name', 'backup_name'). Ensuite,
vous pouvez exécuter RESTORE TABLE data AS data_restored FROM Disk('plain_disk_name', 'backup_name')
ou utiliser ATTACH TABLE data (...) ENGINE = MergeTree() SETTINGS disk = 'plain_disk_name'.
Configuration :
24.1, il est possible de configurer n’importe quel disque de stockage objet (s3, azure, hdfs (non pris en charge), local) à l’aide
du type de métadonnées plain.
Configuration :
Utilisation du stockage S3 Plain Rewritable
s3_plain_rewritable a été introduit dans 24.4.
Comme le type de disque s3_plain, il ne nécessite pas de stockage supplémentaire pour les
fichiers de métadonnées. À la place, les métadonnées sont stockées dans S3.
Contrairement au type de disque s3_plain, s3_plain_rewritable permet d’exécuter des merges
et prend en charge les opérations INSERT.
Les mutations et la réplication des tables ne sont pas prises en charge.
Un cas d’usage de ce type de disque concerne les tables MergeTree non répliquées. Bien que
le type de disque s3 convienne aux tables MergeTree non répliquées, vous pouvez opter pour
le type de disque s3_plain_rewritable si vous n’avez pas besoin de métadonnées locales
pour la table et acceptez un ensemble d’opérations limité. Cela peut
être utile, par exemple, pour les tables système.
Configuration :
24.5, il est possible de configurer n’importe quel disque de stockage objet
(s3, azure, local) avec le type de métadonnées plain_rewritable.
Utilisation d’Azure Blob Storage
MergeTree peuvent stocker des données dans Azure Blob Storage
à l’aide d’un disque de type azure_blob_storage.
Configuration :
Paramètres de connexion
Paramètres d’authentification (le disque tentera d’utiliser toutes les méthodes disponibles ainsi que Managed Identity Credential) :
Paramètres de limitation
Autres paramètres
Vous trouverez des exemples de configurations fonctionnelles dans le répertoire des tests d’intégration (voir p. ex. test_merge_tree_azure_blob_storage ou test_azure_blob_storage_zero_copy_replication).
La réplication zero-copy n’est pas prête pour la productionLa réplication zero-copy est désactivée par défaut dans ClickHouse version 22.8 et ultérieure. Cette fonctionnalité n’est pas recommandée pour une utilisation en production.
Utilisation du stockage HDFS (non pris en charge)
- le disque est de type
hdfs(non pris en charge) - les données sont hébergées à l’emplacement
hdfs://hdfs1:9000/clickhouse/
Utilisation du chiffrement des données
encrypted et choisir le disque sur lequel les données seront stockées. Un disque encrypted chiffre à la volée tous les fichiers qui y sont écrits et, lorsque vous lisez des fichiers depuis un disque encrypted, il les déchiffre automatiquement. Vous pouvez donc utiliser un disque encrypted comme un disque normal.
Exemple de configuration de disque :
store/all_1_1_0/data.bin sur disk1, ce fichier est en réalité écrit sur le disque physique au chemin /path1/store/all_1_1_0/data.bin.
Lors de l’écriture du même fichier sur disk2, il est en réalité écrit sur le disque physique au chemin /path1/path2/store/all_1_1_0/data.bin, en mode chiffré.
Paramètres requis
Paramètres facultatifs
Exemple de configuration du disque :
Utilisation du cache local
s3. Pour les versions >= 22.8, le cache est pris en charge pour tous les types de disque : S3, Azure, Local, Encrypted, etc.
Pour les versions >= 23.5, le cache n’est pris en charge que pour les types de disque distants : S3, Azure, HDFS (non pris en charge).
Le cache utilise la politique de cache LRU.
Exemple de configuration pour les versions supérieures ou égales à 22.8 :
Remarque : les valeurs de taille prennent en charge des unités commeki,Mi,Gi, etc. (par ex.10Gi).
Paramètres de requête/profil de File Cache
Tables système du cache du système de fichiers
Commandes du cache
SYSTEM CLEAR|DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER) — ON CLUSTER
<cache_name> n’est spécifié.
SHOW FILESYSTEM CACHES
22.8, la commande s’appelle SHOW CACHES)
Query
Response
DESCRIBE FILESYSTEM CACHE '<cache_name>'
SHOW FILESYSTEM CACHES. (Pour les versions inférieures
ou égales à 22.8, la commande s’appelle DESCRIBE CACHE)
Query
Response
Utilisation du stockage Web statique (lecture seule)
ATTACH TABLE (voir l’exemple ci-dessous). Le disque local
n’est en fait pas utilisé : chaque requête SELECT entraîne une requête http pour
récupérer les données nécessaires. Toute modification des données de la table entraîne une
exception, c.-à-d. que les types de requêtes suivants ne sont pas autorisés : CREATE TABLE,
ALTER TABLE, RENAME TABLE,
DETACH TABLE et TRUNCATE TABLE.
Le stockage Web peut être utilisé en lecture seule. Il peut par exemple servir à héberger
des données d’exemple ou à migrer des données. Il existe un outil clickhouse-static-files-uploader,
qui prépare un répertoire de données pour une table donnée (SELECT data_paths FROM system.tables WHERE name = 'table_name').
Pour chaque table dont vous avez besoin, vous obtenez un répertoire de fichiers. Ces fichiers peuvent être téléversés
vers, par exemple, un serveur web servant des fichiers statiques. Après cette préparation,
vous pouvez charger cette table sur n’importe quel serveur ClickHouse via DiskWeb.
Dans cet exemple de configuration :
- le disque est de type
web - les données sont hébergées à
http://nginx:80/test1/ - un cache sur le stockage local est utilisé
ATTACH TABLE, le UUID fourni correspond au nom du répertoire de données, et l’endpoint est l’URL du contenu brut de GitHub.
Paramètres requis
Paramètres facultatifs
Si une requête échoue avec une exception
DB:Exception Unreachable URL, vous pouvez essayer d’ajuster les paramètres suivants : http_connection_timeout, http_receive_timeout, keep_alive_timeout.
Pour obtenir les fichiers à téléverser, exécutez :
clickhouse static-files-disk-uploader --metadata-path <path> --output-dir <dir> (--metadata-path peut être trouvé dans la requête SELECT data_paths FROM system.tables WHERE name = 'table_name').
Lors du chargement des fichiers via endpoint, ils doivent être chargés dans le chemin <endpoint>/store/, mais la configuration ne doit contenir que endpoint.
Si l’URL n’est pas accessible lors du chargement du disque pendant le démarrage des tables par le serveur, toutes les erreurs sont interceptées. Si, dans ce cas, des erreurs se sont produites, les tables peuvent être rechargées (et redevenir visibles) via DETACH TABLE table_name -> ATTACH TABLE table_name. Si les métadonnées ont été chargées avec succès au démarrage du serveur, les tables sont alors disponibles immédiatement.
Utilisez le paramètre http_max_single_read_retries pour limiter le nombre maximal de tentatives pendant une seule lecture HTTP.
Réplication zero-copy (pas prête pour la production)
S3 et HDFS (non pris en charge). La réplication zero-copy signifie que, si les données sont stockées à distance sur plusieurs machines et doivent être synchronisées, seules les métadonnées sont répliquées (les chemins d’accès aux parties de données), et non les données elles-mêmes.
La réplication zero-copy n’est pas prête pour la productionLa réplication zero-copy est désactivée par défaut dans ClickHouse version 22.8 et ultérieure. Cette fonctionnalité n’est pas recommandée en production.