remote, remoteSecure

La fonction de table remote permet d’accéder à des serveurs distants à la volée, c’est-à-dire sans créer de table Distributed. La fonction de table remoteSecure est similaire à remote, mais via une connexion sécurisée.

Les deux fonctions peuvent être utilisées dans des requêtes SELECT et INSERT lorsque la cible est une db/table ordinaire. Lorsque la cible est elle-même une fonction de table (par exemple remote('127.0.0.1', numbers(10))), la table est en lecture seule : il n’existe pas de table distante dans laquelle insérer des données, donc INSERT est rejeté avec une exception NOT_IMPLEMENTED.

remote(addresses_expr, [db, table, user [, password], sharding_key][, SETTINGS name = value, ...])
remote(addresses_expr, [db.table, user [, password], sharding_key][, SETTINGS name = value, ...])
remote(named_collection[, option=value [,..]][, SETTINGS name = value, ...])
remoteSecure(addresses_expr, [db, table, user [, password], sharding_key][, SETTINGS name = value, ...])
remoteSecure(addresses_expr, [db.table, user [, password], sharding_key][, SETTINGS name = value, ...])
remoteSecure(named_collection[, option=value [,..]][, SETTINGS name = value, ...])

Les arguments peuvent également être transmis à l’aide de collections nommées.

Une table située sur un serveur distant.

Comme les fonctions de table remote et remoteSecure rétablissent la connexion à chaque requête, il est recommandé d'utiliser plutôt une table Distributed. De plus, si des noms d'hôte sont définis, ils sont résolus et les erreurs ne sont pas prises en compte lors de l'utilisation de différentes répliques. Pour traiter un grand nombre de requêtes, créez toujours la table Distributed à l'avance et n'utilisez pas la fonction de table remote.

La fonction de table remote peut être utile dans les cas suivants :

• Migration ponctuelle de données d'un système à un autre
• Accès à un serveur spécifique pour comparer des données, effectuer du débogage et réaliser des tests, c.-à-d. pour des connexions ad hoc.
• Requêtes entre différents clusters ClickHouse à des fins de recherche.
• Requêtes distribuées peu fréquentes, effectuées manuellement.
• Requêtes distribuées pour lesquelles l'ensemble des serveurs est redéfini à chaque fois.

Les mêmes paramètres peuvent être utilisés avec les moteurs de table Remote et RemoteSecure pour créer une table persistante au lieu d'une table ad hoc, voir moteurs Remote et RemoteSecure. La seule différence est la clause SETTINGS : les moteurs l'acceptent après la définition du moteur, ENGINE = Remote(...) SETTINGS skip_unavailable_shards = 1, et non parmi les arguments.

example01-01-1
example01-01-1:9440
example01-01-1:9000
localhost
127.0.0.1
[::]:9440
[::]:9000
[2a02:6b8:0:1111::11]:9000

Plusieurs adresses peuvent être séparées par des virgules. Dans ce cas, ClickHouse utilisera le traitement distribué et enverra la requête à toutes les adresses spécifiées (comme pour des shards contenant des données différentes). Exemple :

example01-01-1,example01-02-1

SELECT * FROM remote('127.0.0.1', db.remote_engine_table) LIMIT 3;

Ou avec les collections nommées :

CREATE NAMED COLLECTION creds AS
        host = '127.0.0.1',
        database = 'db';
SELECT * FROM remote(creds, table='remote_engine_table') LIMIT 3;

CREATE TABLE remote_table (name String, value UInt32) ENGINE=Memory;
INSERT INTO FUNCTION remote('127.0.0.1', currentDatabase(), 'remote_table') VALUES ('test', 42);
SELECT * FROM remote_table;

Cet exemple utilise une table issue d’un jeu de données d’exemple. La base de données est imdb et la table est actors.

• Vérifiez le nom de la base de données source et celui de la table (imdb.actors)

  show databases

  show tables in imdb

• Récupérez l'instruction CREATE TABLE à partir de la source :

  SELECT create_table_query
  FROM system.tables
  WHERE database = 'imdb' AND table = 'actors'

Réponse

  CREATE TABLE imdb.actors (`id` UInt32,
                            `first_name` String,
                            `last_name` String,
                            `gender` FixedString(1))
                  ENGINE = MergeTree
                  ORDER BY (id, first_name, last_name, gender);

• Créez la base de données de destination :

  CREATE DATABASE imdb

• À partir de l’instruction CREATE TABLE de la source, créez la table de destination :

  CREATE TABLE imdb.actors (`id` UInt32,
                            `first_name` String,
                            `last_name` String,
                            `gender` FixedString(1))
                  ENGINE = MergeTree
                  ORDER BY (id, first_name, last_name, gender);

Insérez des données dans la nouvelle base de données et la nouvelle table créées sur le système distant. Vous aurez besoin de l’hôte, du port, du nom d’utilisateur, du mot de passe, de la base de données de destination et de la table de destination.

INSERT INTO FUNCTION
remoteSecure('remote.clickhouse.cloud:9440', 'imdb.actors', 'USER', 'PASSWORD')
SELECT * from imdb.actors

Les motifs entre { } sont utilisés pour générer un ensemble de shards et pour spécifier des répliques. S'il y a plusieurs paires de { }, le produit cartésien des ensembles correspondants est généré.

Les types de motifs suivants sont pris en charge.

• {a,b,c} - Représente l'une des chaînes alternatives a, b ou c. Le motif est remplacé par a dans l'adresse du premier shard, puis par b dans l'adresse du deuxième shard, et ainsi de suite. Par exemple, example0{1,2}-1 génère les adresses example01-1 et example02-1.
• {N..M} - Une plage de nombres. Ce motif génère des adresses de shards avec des indices incrémentés de N à M (inclus). Par exemple, example0{1..2}-1 génère example01-1 et example02-1.
• {0n..0m} - Une plage de nombres avec des zéros en tête. Ce motif conserve les zéros en tête dans les indices. Par exemple, example{01..03}-1 génère example01-1, example02-1 et example03-1.
• {a|b} - Un nombre quelconque de variantes séparées par |. Le motif spécifie des répliques. Par exemple, example01-{1|2} génère les répliques example01-1 et example01-2.

La query sera envoyée à la première réplique disponible. Cependant, pour remote, les répliques sont parcourues dans l'ordre actuellement défini par le paramètre load_balancing. Le nombre d'adresses générées est limité par le paramètre table_function_remote_max_addresses.