remote_servers) d’un cluster sans créer de table Distributed. Une seule réplique de chaque shard est interrogée.
Fonction clusterAllReplicas — identique à cluster, mais toutes les répliques sont interrogées. Chaque réplique d’un cluster est utilisée comme un shard/une connexion distincte.
Tous les clusters disponibles sont répertoriés dans la table system.clusters.
Syntaxe
Arguments
| Arguments | Type |
|---|---|
cluster_name | Nom d’un cluster utilisé pour construire un ensemble d’adresses et de paramètres de connexion pour des serveurs distants et locaux ; default s’il n’est pas spécifié. |
db.table ou db, table | Nom d’une base de données et d’une table. |
sharding_key | Une clé de sharding. Facultatif. Doit être spécifiée si le cluster comporte plus d’un shard. |
Valeur renvoyée
Utilisation des macros
cluster_name peut contenir des macros — des substitutions entre {}. La valeur de substitution est tirée de la section macros du fichier de configuration du serveur.
Exemple :
Utilisation et recommandations
cluster et clusterAllReplicas est moins efficace que la création d’une table Distributed, car dans ce cas, la connexion au serveur est rétablie pour chaque requête. Lors du traitement d’un grand nombre de requêtes, créez toujours la table Distributed à l’avance et n’utilisez pas les fonctions de table cluster et clusterAllReplicas.
Les fonctions de table cluster et clusterAllReplicas peuvent être utiles dans les cas suivants :
- Accès à un cluster spécifique pour la comparaison de données, le débogage et les tests.
- Requêtes vers différents clusters et répliques ClickHouse à des fins d’analyse.
- Requêtes distribuées peu fréquentes effectuées manuellement.
host, port, user, password, compression, secure sont repris de la section de configuration <remote_servers>. Voir les détails dans moteur Distributed.