Moteur de table SharedMergeTree

Description du moteur de table SharedMergeTree

La famille de moteurs de table SharedMergeTree est un remplacement cloud-native des moteurs ReplicatedMergeTree, optimisé pour fonctionner sur un stockage partagé (par ex. Amazon S3, Google Cloud Storage, MinIO, Azure Blob Storage). Il existe un équivalent SharedMergeTree pour chaque type de moteur MergeTree spécifique, c’est-à-dire que SharedReplacingMergeTree remplace ReplicatedReplacingMergeTree.

La famille de moteurs de table SharedMergeTree est au cœur de ClickHouse Cloud. Pour l’utilisateur final, aucune modification n’est nécessaire pour commencer à utiliser la famille de moteurs SharedMergeTree à la place des moteurs basés sur ReplicatedMergeTree. Elle offre les avantages supplémentaires suivants :

• Débit d’insertion plus élevé
• Débit amélioré des fusions en arrière-plan
• Débit amélioré des mutations
• Opérations de scale-up et de scale-down plus rapides
• Cohérence forte allégée pour les requêtes SELECT

Une amélioration majeure apportée par SharedMergeTree est qu’il permet une séparation plus poussée du compute et du storage par rapport à ReplicatedMergeTree. Vous pouvez voir ci-dessous comment ReplicatedMergeTree sépare le compute et le storage :

Comme vous pouvez le voir, même si les données stockées dans ReplicatedMergeTree se trouvent dans un stockage objet, les métadonnées résident toujours sur chacun des clickhouse-servers. Cela signifie que pour chaque opération répliquée, les métadonnées doivent également être répliquées sur tous les réplicas.

Contrairement à ReplicatedMergeTree, SharedMergeTree n’exige pas que les réplicas communiquent entre eux. À la place, toute la communication passe par le stockage partagé et ClickHouse Keeper. SharedMergeTree implémente une réplication asynchrone sans leader et utilise ClickHouse Keeper pour la coordination et le stockage des métadonnées. Cela signifie que les métadonnées n’ont pas besoin d’être répliquées à mesure que votre service effectue un scale-up ou un scale-down. Il en résulte des opérations de réplication, de mutation, de fusion et de scale-up plus rapides. SharedMergeTree prend en charge des centaines de réplicas pour chaque table, ce qui permet une mise à l’échelle dynamique sans shards. Une approche d’exécution distribuée des requêtes est utilisée dans ClickHouse Cloud afin de mobiliser davantage de ressources de compute pour une requête.

​

Introspection

La plupart des tables système utilisées pour l’introspection de ReplicatedMergeTree existent aussi pour SharedMergeTree, à l’exception de system.replication_queue et system.replicated_fetches, puisqu’aucune réplication des données ni des métadonnées n’a lieu. SharedMergeTree propose toutefois des alternatives correspondantes pour ces deux tables.

system.virtual_parts

Cette table sert d’alternative à system.replication_queue pour SharedMergeTree. Elle stocke des informations sur l’ensemble le plus récent des parts actuelles, ainsi que sur les futures parts en cours de traitement, comme les fusions, les mutations et les partitions supprimées.

system.shared_merge_tree_fetches

Cette table est l’alternative à system.replicated_fetches pour SharedMergeTree. Elle contient des informations sur les opérations en cours qui chargent en mémoire les clés primaires et les checksums.

​

Activation de SharedMergeTree

SharedMergeTree est activé par défaut.

Pour les services compatibles avec le moteur de table SharedMergeTree, vous n’avez rien à activer manuellement. Vous pouvez créer des tables comme auparavant, et le moteur de table basé sur SharedMergeTree correspondant au moteur spécifié dans votre requête CREATE TABLE sera utilisé automatiquement.

CREATE TABLE my_table(
 key UInt64,
 value String
)
ENGINE = MergeTree
ORDER BY key

Cela créera la table my_table à l’aide du moteur de table SharedMergeTree.

Vous n’avez pas besoin de spécifier ENGINE=MergeTree, car default_table_engine=MergeTree dans ClickHouse Cloud. La requête suivante est identique à celle ci-dessus.

CREATE TABLE my_table(
 key UInt64,
 value String
)
ORDER BY key

Si vous utilisez Replacing, Collapsing, Aggregating, Summing, VersionedCollapsing ou des tables Graphite MergeTree, la conversion vers le moteur de table correspondant basé sur SharedMergeTree se fera automatiquement.

CREATE TABLE myFirstReplacingMT
(
    `key` Int64,
    `someCol` String,
    `eventTime` DateTime
)
ENGINE = ReplacingMergeTree
ORDER BY key;

Pour une table donnée, vous pouvez vérifier quel moteur de table a été défini dans l’instruction CREATE TABLE à l’aide de SHOW CREATE TABLE :

SHOW CREATE TABLE myFirstReplacingMT;

CREATE TABLE default.myFirstReplacingMT
( `key` Int64, `someCol` String, `eventTime` DateTime )
ENGINE = SharedReplacingMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}')
ORDER BY key

​

Paramètres

Le comportement de certains paramètres change de manière significative :

• insert_quorum — toutes les insertions dans SharedMergeTree sont des insertions avec quorum (écrites dans le stockage partagé), ce paramètre n’est donc pas nécessaire lors de l’utilisation du moteur de table SharedMergeTree.
• insert_quorum_parallel — toutes les insertions dans SharedMergeTree sont des insertions avec quorum (écrites dans le stockage partagé), ce paramètre n’est donc pas nécessaire lors de l’utilisation du moteur de table SharedMergeTree.
• select_sequential_consistency — ne nécessite pas d’insertions avec quorum, mais entraînera une charge supplémentaire sur ClickHouse Keeper pour les requêtes SELECT

​

Cohérence

SharedMergeTree offre une meilleure cohérence légère que ReplicatedMergeTree. Lors d’une insertion dans SharedMergeTree, vous n’avez pas besoin de fournir de paramètres tels que insert_quorum ou insert_quorum_parallel. Les insertions sont des insertions avec quorum, ce qui signifie que les métadonnées sont stockées dans ClickHouse-Keeper et répliquées sur au moins un quorum de nœuds ClickHouse Keeper. Chaque réplique de votre cluster récupérera de manière asynchrone les nouvelles informations depuis ClickHouse-Keeper.

La plupart du temps, vous ne devriez pas utiliser select_sequential_consistency ni SYSTEM SYNC REPLICA LIGHTWEIGHT. La réplication asynchrone devrait couvrir la plupart des scénarios et présente une très faible latence. Dans les rares cas où vous devez absolument éviter des lectures obsolètes, suivez ces recommandations par ordre de préférence :

1. Si vous exécutez vos requêtes dans la même session ou sur le même nœud pour les lectures et les écritures, il n’est pas nécessaire d’utiliser select_sequential_consistency, car votre réplique disposera déjà des métadonnées les plus récentes.

2. Si vous écrivez sur une réplique et lisez depuis une autre, vous pouvez utiliser SYSTEM SYNC REPLICA LIGHTWEIGHT pour forcer la réplique à récupérer les métadonnées depuis ClickHouse-Keeper.

3. Utilisez select_sequential_consistency comme paramètre dans votre requête.

​

ALTER et visibilité des mutations

SharedMergeTree coordonne les modifications de métadonnées via ClickHouse Keeper. Les répliques récupèrent les métadonnées modifiées de manière asynchrone : une modification de métadonnées n’est donc pas forcément visible immédiatement sur toutes les répliques. Les lectures effectuées dans la même session sur le même nœud utilisent déjà les métadonnées à jour. Si une lecture doit s’exécuter sur une autre réplique juste après une modification de métadonnées, utilisez SYSTEM SYNC REPLICA LIGHTWEIGHT pour que cette réplique récupère les métadonnées depuis ClickHouse Keeper.

Les opérations ALTER qui génèrent des mutations déclenchent un traitement en arrière-plan qui crée de nouvelles parts dans le stockage partagé et coordonne leur visibilité via ClickHouse Keeper. Il ne s’agit pas d’un processus de réécriture ou de transfert de données propre à chaque réplique, comme c’est le cas avec ReplicatedMergeTree.

Dans ClickHouse Cloud, alter_sync vaut 0 par défaut : définissez-le lorsqu’un client doit attendre la fin d’opérations sur les métadonnées ou d’une réécriture MODIFY COLUMN qui ne se limite pas aux métadonnées. Pour les opérations UPDATE, DELETE et MATERIALIZE ..., utilisez mutations_sync pour contrôler l’attente, et suivez leur progression dans system.mutations.