Expliquer les arbres Merkle à utiliser dans une cohérence éventuelle
Merkle Trees sont utilisés comme mécanisme anti-entropie dans plusieurs magasins de clés/valeurs distribués et répliqués:
Il ne fait aucun doute qu'un mécanisme anti-entropie est une bonne chose - des défaillances transitoires se produisent juste en production. Je ne suis juste pas sûr de comprendre pourquoi Merkle Les arbres sont l'approche populaire.
L'envoi d'un arbre Merkle complet à un homologue implique d'envoyer l'espace clé local à cet homologue, ainsi que les hachages de chaque valeur de clé, stockés dans les niveaux les plus bas de l'arborescence.
Pour différencier un arbre Merkle envoyé par un pair, vous devez avoir votre propre arbre Merkle.
Étant donné que les deux homologues doivent déjà disposer d'un espace de hachage clé/valeur trié, pourquoi ne pas effectuer une fusion linéaire pour détecter les écarts?
Je ne suis tout simplement pas convaincu que la structure arborescente permet de réaliser des économies lorsque vous tenez compte des coûts d'entretien, et le fait que des passages linéaires sur les feuilles de l'arbre soient déjà effectués juste pour sérialiser la représentation sur le fil .
Pour mettre cela à la terre, une alternative à l'homme de paille pourrait être que les nœuds échangent des tableaux de condensés de hachage, qui sont mis à jour progressivement et regroupés par la position de l'anneau modulo.
Qu'est-ce que je rate?
Les arborescences Merkle limitent la quantité de données transférées lors de la synchronisation. Les hypothèses générales sont les suivantes:
- Les E/S réseau coûtent plus cher que les E/S locales + calculent les hachages.
- Le transfert de l'intégralité de l'espace clé trié est plus coûteux que de limiter progressivement la comparaison sur plusieurs étapes.
- Les espaces clés présentent moins de divergences que de similitudes.
Un échange Merkle Tree ressemblerait à ceci:
- Commencez par la racine de l'arbre (une liste d'une valeur de hachage).
- L'Origin envoie la liste des hachages au niveau actuel.
- La destination diffère la liste des hachages des siennes et demande ensuite des sous-arborescences différentes. S'il n'y a aucune différence, la demande peut se terminer.
- Répétez les étapes 2 et 3 jusqu'à ce que les nœuds foliaires soient atteints.
- L'Origin envoie les valeurs des clés dans l'ensemble résultant.
Dans le cas typique, la complexité de la synchronisation des espaces clés sera log (N). Oui, à l'extrême, où il n'y a pas de clés en commun, l'opération sera équivalente à l'envoi de la liste triée complète des hachages, O (N). On pourrait amortir les frais de construction des arbres Merkle en les construisant dynamiquement à mesure que les écritures arrivent et en conservant le formulaire sérialisé sur le disque.
Je ne peux pas parler de la façon dont Dynamo ou Cassandra utilisent les arbres Merkle, mais Riak a cessé de les utiliser pour la synchronisation intra-cluster (le transfert et la réparation en lecture suggérés sont suffisants dans la plupart des cas). Nous avons des plans pour les ajouter plus tard après que certains éléments architecturaux internes ont été modifiés.
Pour plus d'informations sur Riak, nous vous encourageons à rejoindre la liste de diffusion: http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com