Cette rubrique ne s’applique pas à ClickHouse Cloud, où les Parallel Replicas fonctionnent comme plusieurs shards dans les clusters ClickHouse shared-nothing traditionnels, et où le stockage objet remplace les répliques, garantissant une haute disponibilité et une tolérance aux pannes.
Que sont les shards de table dans ClickHouse ?
Dans ce cas, les données peuvent être réparties sur plusieurs serveurs ClickHouse sous forme de shards de table :
Chaque shard contient un sous-ensemble des données et fonctionne comme une table ClickHouse classique, interrogeable indépendamment. Toutefois, les requêtes ne traiteront que ce sous-ensemble, ce qui peut être un cas d’usage valable selon la distribution des données. En général, une table distribuée (souvent une par serveur) fournit une vue unifiée de l’ensemble du jeu de données. Elle ne stocke pas elle-même les données, mais transmet les requêtes SELECT à tous les shards, assemble les résultats et achemine les INSERTS afin de répartir les données uniformément.
Création d’une table distribuée
ON CLUSTER transforme l’instruction DDL en instruction DDL distribuée, demandant à ClickHouse de créer la table sur tous les serveurs répertoriés dans la définition du cluster test_cluster. Le DDL distribué nécessite un composant Keeper supplémentaire dans l’architecture du cluster.
Pour les paramètres du moteur Distributed, nous spécifions le nom du cluster (test_cluster), le nom de la base de données (uk) de la table cible shardée, le nom de cette table cible shardée (uk_price_paid_simple) et la clé de sharding pour le routage des INSERT. Dans cet exemple, nous utilisons la fonction rand pour répartir aléatoirement les lignes entre les shards. Cependant, n’importe quelle expression, même complexe, peut être utilisée comme clé de sharding, selon le cas d’usage. La section suivante illustre le fonctionnement du routage des INSERT.
Routage des INSERT
① Un INSERT (avec une seule ligne) ciblant la table distribuée est envoyé à un serveur ClickHouse qui héberge la table, soit directement, soit via un répartiteur de charge. ② Pour chaque ligne de l’INSERT (une seule dans notre exemple), ClickHouse évalue la clé de sharding (ici, rand()), prend le résultat modulo le nombre de serveurs de shard, et utilise cette valeur comme ID du serveur cible (les ID commencent à 0 et sont incrémentés de 1). La ligne est ensuite transmise puis ③ insérée dans le shard de table du serveur correspondant. La section suivante explique comment fonctionne le transfert des SELECT.
Routage des requêtes SELECT
① Une requête d’agrégation SELECT visant la table distribuée est envoyée au serveur ClickHouse correspondant, soit directement, soit via un répartiteur de charge. ② La table distribuée transmet la requête à tous les serveurs hébergeant les shards de la table cible, où chaque serveur ClickHouse calcule son résultat d’agrégation local en parallèle. Ensuite, le serveur ClickHouse hébergeant la table distribuée initialement visée ③ collecte tous les résultats locaux, ④ les fusionne pour produire le résultat global final, et ⑤ le renvoie à l’émetteur de la requête.
Que sont les répliques de table dans ClickHouse ?
Shard-1 et Shard-2 introduits précédemment disposent chacun de trois répliques. Une requête est envoyée à ce cluster :
Le traitement des requêtes fonctionne de manière similaire aux configurations sans répliques, une seule réplique de chaque shard exécutant la requête.
Les répliques assurent non seulement l’intégrité des données et le failover, mais elles améliorent également le débit du traitement des requêtes en permettant à plusieurs requêtes de s’exécuter en parallèle sur différentes répliques.① Une requête ciblant la table distribuée est envoyée au serveur ClickHouse correspondant, soit directement, soit via un répartiteur de charge. ② La table distribuée transmet la requête à une réplique de chaque shard, où chaque serveur ClickHouse hébergeant la réplique sélectionnée calcule son résultat local de requête en parallèle. La suite fonctionne de la même manière que dans les configurations sans répliques et n’est pas représentée dans le schéma ci-dessus. Le serveur ClickHouse hébergeant la table distribuée initialement ciblée collecte tous les résultats locaux, les fusionne en un résultat global final, puis le renvoie à l’émetteur de la requête. Notez que ClickHouse permet de configurer la stratégie de transfert des requêtes pour ②. Par défaut — contrairement au schéma ci-dessus — la table distribuée privilégie une réplique locale si elle est disponible, mais d’autres stratégies d’équilibrage de charge peuvent être utilisées.