Les moteurs de base de données Remote et RemoteSecure fournissent un accès en temps réel aux tables d’une base de données située sur un serveur ClickHouse distant via le protocole TCP natif. Ils constituent les équivalents ClickHouse-à-ClickHouse des moteurs de base de données MySQL et PostgreSQL.
La liste des tables et leur structure sont récupérées à la demande depuis le serveur distant (via SHOW TABLES et DESCRIBE TABLE en interne), de sorte que la base de données reflète toujours l’état actuel du serveur distant. Chaque table est exposée comme un stockage Distributed sur un cluster ad hoc créé à partir des adresses fournies, qui transmet les requêtes SELECT et INSERT au serveur distant.
Cela est utile pour fédérer plusieurs clusters ClickHouse ou pour connecter un cluster ClickHouse plus important à clickhouse-local ou à un cluster plus petit.
Création d’une base de données
Remote se connecte via le port TCP non chiffré (tcp_port, 9000 par défaut) lorsque le port est omis.RemoteSecure se connecte via une connexion TLS sécurisée, en utilisant le port TCP sécurisé (tcp_port_secure, 9440 par défaut) lorsque le port est omis.
addresses_expr — Une adresse de serveur distant ou une expression générant plusieurs adresses, sous la forme host ou host:port. L’expression d’adresse prend en charge les mêmes motifs de globbing que la fonction de table remote (par exemple, {a,b,c}, {N..M} et {a|b} pour développer plusieurs segments et répliques). Lorsque le port est omis, Remote utilise le port TCP non chiffré (tcp_port, 9000 par défaut) et RemoteSecure utilise le port TCP sécurisé (tcp_port_secure, 9440 par défaut).database — Le nom de la base de données sur le serveur distant.user — Le nom de l’utilisateur distant. Facultatif, par défaut : default.password — Le mot de passe de l’utilisateur distant. Facultatif, par défaut : vide.
Les adresses et les identifiants sont stockés dans la définition de la base de données, de sorte que le mot de passe est masqué dans SHOW CREATE DATABASE. Comme avec la fonction de table remote, une adresse pointant vers le serveur courant est traitée comme un segment local : SELECT et INSERT sont exécutés directement sous l’utilisateur courant — qui doit donc disposer des privilèges correspondants sur la base de données sous-jacente et ses tables — et les identifiants stockés ne sont utilisés que pour les serveurs réellement distants. Si la réplique locale d’un segment ne possède pas la base de données ou une table, la recherche bascule vers les répliques distantes du segment, comme le fait une table Distributed. Dans ce cas, SHOW CREATE TABLE affiche les adresses de repli effectives (les répliques locales étant retirées de leurs segments) au lieu de celles configurées, de sorte que la définition de table Remote(...) générée reconstruit l’objet qui traite réellement les requêtes.
Lorsque l’expression d’adresse décrit plusieurs segments, chaque table proxy lit les données de tous ces segments, mais les métadonnées — la liste des tables et leur structure — proviennent d’un segment arbitraire (un segment local est privilégié), comme avec la fonction de table remote, afin qu’une énumération ne nécessite qu’une seule requête plutôt qu’une requête par segment. Les segments d’un cluster doivent donc proposer le même ensemble de tables ; une table présente sur certains segments seulement est exposée via un proxy dont les requêtes échouent alors sur les segments qui ne la possèdent pas. Un INSERT dans une table d’une base de données à plusieurs segments envoie chaque ligne vers un segment aléatoire (les tables proxy Distributed comportent une clé de sharding rand() implicite) ; pour fixer le segment d’une requête, définissez insert_shard_id. La clé implicite ne distribue que les lignes insérées : en lecture, la table se comporte comme une table Distributed sans clé de sharding (en particulier, optimize_skip_unused_shards et force_optimize_skip_unused_shards ne la considèrent pas comme une clé d’élagage des segments). SHOW CREATE TABLE inclut cette clé dans la définition de table Remote(...) générée, de sorte qu’une table recréée à partir de celle-ci accepte également les requêtes INSERT sur plusieurs segments.
Les collections nommées sont également prises en charge :
- Le moteur constitue une vue en lecture directe du serveur distant : les instructions DDL
CREATE TABLE, DROP TABLE, ALTER et similaires appliquées à la base de données Remote ne sont pas prises en charge. Gérez directement le schéma sur le serveur distant.
- Les droits d’accès sont appliqués sur le serveur distant pour l’utilisateur distant configuré et, localement, par les privilèges habituels sur la base de données et ses tables.
- Une table d’un segment local que l’utilisateur n’est pas autorisé à voir est signalée comme absente plutôt que comme interdite. Une base de données
Remote ne peut donc pas être utilisée pour sonder les noms des tables d’une base de données locale sur laquelle l’utilisateur ne dispose d’aucun privilège. Cela s’applique à l’énumération (SHOW TABLES, EXISTS TABLE) comme à la résolution (DESCRIBE TABLE, SHOW CREATE TABLE, SELECT), et une telle table n’est pas non plus accessible via les répliques distantes de son segment : le basculement décrit ci-dessus ne se produit que lorsque la réplique locale ne possède réellement pas la table.
- L’énumération des tables d’une base de données présente sur la réplique locale d’un segment inclut également les tables présentes uniquement sur les répliques distantes de ce segment, afin que
SHOW TABLES et system.tables concordent avec EXISTS TABLE, DESCRIBE TABLE et SELECT, qui basculent vers ces répliques. Lorsqu’aucune réplique distante ne répond, la liste de la réplique locale est renvoyée telle quelle, car elle constitue déjà la réponse d’une réplique disponible.
- Si le serveur distant est indisponible, l’énumération de ses tables (
SHOW TABLES, system.tables) renvoie l’erreur de connexion plutôt qu’une liste vide, tout comme EXISTS TABLE et SELECT sur la même base de données. Notez qu’un SELECT sur system.tables couvrant toutes les bases de données échoue également lorsqu’une telle base de données est inaccessible.
- Une base de données
Remote peut pointer vers une autre base de données Remote sur le même serveur. L’énumération et la description des tables d’une telle chaîne ne nécessitent aucun privilège sur la base de données intermédiaire : elle ne contient ni données ni métadonnées propres, et chaque saut vérifie déjà les droits de l’appelant sur les objets qu’il relaie à son tour. En revanche, la lecture et l’écriture des données nécessitent SELECT / INSERT à chaque saut de la chaîne, car la requête est réellement exécutée sur la table de la base de données intermédiaire, exactement comme pour une table Distributed reposant sur une autre table Distributed. La règle de visibilité décrite ci-dessus s’applique à toute la chaîne : une table que la base de données intermédiaire masque à l’appelant n’est pas non plus accessible via les répliques distantes de la base de données externe. Si la base de données intermédiaire de la réplique locale ne peut pas atteindre sa propre cible, la réplique locale du segment externe ne peut pas répondre du tout — exactement comme si la réplique elle-même était hors service — et la base de données externe bascule vers les répliques distantes du segment.
Créez une base de données Remote qui pointe vers la base de données system d’un serveur distant, puis lisez son contenu :
Dernière modification le 14 août 2026
