Quel est le protocole de réplication de CouchDB ? Est-ce que c'est comme Git ?

Question

Existe-t-il une documentation technique décrivant le fonctionnement de la réplication entre deux Couches ?

Quel est l'aperçu de base de la réplication CouchDB ? Quelles sont les caractéristiques les plus remarquables de ce système ?

Answer 1

Malheureusement, il n'existe pas de documentation détaillée décrivant le protocole de réplication. Il n'y a que l'implémentation de référence intégrée à CouchDB, et la réécriture de Filipe Manana qui deviendra probablement la nouvelle implémentation dans le futur.

Toutefois, c'est l'idée générale :

Points clés

Si vous connaissez Git, alors vous savez comment fonctionne la réplication de Couch. La réplication est très similaire au push ou pulling avec les gestionnaires de sources distribuées comme Git.

La réplication de CouchDB ne possÃ?de pas son propre protocole. Un réplicateur se connecte simplement à deux bases de données en tant que client, puis lit dans l'une et écrit dans l'autre. La réplication "push" consiste à lire les données locales et à mettre à jour la base de données distante ; la réplication "pull" est l'inverse.

• Premier fait amusant : Le réplicateur est en fait une application Erlang indépendante, dans son propre processus. Il se connecte aux deux couches, puis lit les enregistrements de l'une et les écrit sur l'autre.
• Fait amusant 2 : CouchDB a aucun moyen de savoir qui est un client normal et qui est un réplicateur (sans parler de savoir si la réplication est de type push ou pull). Tout cela ressemble à des connexions de clients. Certaines d'entre elles lisent des enregistrements. Certaines d'entre elles écrivent des enregistrements.

Tout découle du modèle de données

L'algorithme de réplication est trivial, inintéressant. Un singe entraîné pourrait le concevoir. C'est simple parce que l'intelligence réside dans le modèle de données, qui possède ces caractéristiques utiles :

1. Chaque enregistrement dans CouchDB est complètement indépendant de tous les autres. Cela craint si vous voulez faire une JOIN ou une transaction, mais c'est génial si tu veux écrire un réplicateur. Il suffit de trouver comment répliquer un et ensuite répéter que pour chaque enregistrement.
2. Comme Git, les enregistrements ont un historique de révision en liste chaînée. L'ID de révision d'un enregistrement est la somme de contrôle de ses propres données. Les ID de révision suivants sont des sommes de contrôle de : la nouvelle donnée, plus l'ID de révision de la précédente.

3. En plus des données de l'application ( {"name": "Jason", "awesome": true} ), chaque enregistrement stocke la chronologie de l'évolution de tous les ID de révision précédents jusqu'à lui-même.

   • Exercice : Prenez un moment de réflexion tranquille. Considérez deux enregistrements différents, A et B. Si l'ID de révision de A apparaît dans la ligne de temps de B, alors B a définitivement évolué à partir de A. Maintenant, considérez les fusions en avance rapide de Git. Entendez-vous cela ? C'est le son de votre esprit qui est soufflé.

4. Git n'est pas vraiment une liste linéaire. Il y a des bifurcations, quand un parent a plusieurs enfants. C'est aussi le cas de CouchDB.

   • Exercice : Comparez deux enregistrements différents, A et B. L'identifiant de révision de A n'apparaît pas dans la ligne de temps de B ; cependant, un identifiant de révision, C, est dans la ligne de temps de A. les deux La ligne de temps de A et B. Ainsi, A n'a pas évolué à partir de B. B n'a pas évolué à partir de A. Mais plutôt, A et B ont un ancêtre commun C. Dans Git, c'est un "fork". Dans CouchDB, il s'agit d'un "conflit".

   • A Git, si les deux enfants continuent à développer leur ligne de temps indépendamment, c'est cool. Les fourchettes soutiennent totalement cela.

   • Dans CouchDB, si les deux enfants continuent à développer leur ligne de temps indépendamment, c'est également cool. Les conflits soutiennent totalement cela.

   • Fait amusant 3 : Les "conflits" CouchDB ne correspondent pas aux "conflits" Git. Un conflit Couch est un historique de révision divergent, ce que Git appelle un "fork". C'est pour cette raison que la communauté CouchDB prononce le mot "conflit" avec un silencieux n : "cofliqué".

5. Git dispose également de fusions, lorsqu'un enfant a plusieurs parents. CouchDB en quelque sorte a aussi cela.

   • Dans le modèle de données, il n'y a pas de fusion. Le client marque simplement une ligne temporelle comme étant supprimée et continue à travailler avec la seule ligne temporelle existante.
   • Dans l'application, cela ressemble à une fusion. Typiquement, le client fusionne les données de chaque ligne de temps d'une manière spécifique à l'application. Ensuite, il écrit la nouvelle données à la ligne de temps. Dans Git, cela revient à copier et coller les modifications de la branche A dans la branche B, puis à commiter dans la branche B et à supprimer la branche A. Le bouton données a été fusionné, mais il n'y avait pas de git merge .
   • Ces comportements sont différents car, dans Git, la chronologie est importante, alors que dans CouchDB, les données sont importantes et la chronologie est accessoire - elle est juste là pour supporter la réplication. C'est l'une des raisons pour lesquelles la révision intégrée à CouchDB est inappropriée pour stocker des données de révision comme celles d'une page wiki.

Notes finales

Au moins une phrase de ce compte-rendu (peut-être celle-ci) est une pure connerie.

Answer 2

Merci Jason pour cet excellent aperçu ! Jens Alfke, qui travaille sur TouchDB et sa réplication pour Couchbase, a décrit (de manière non officielle) l'algorithme de réplication de CouchDB lui-même si vous êtes intéressé par les détails techniques du fonctionnement d'un protocole de réplicateur CouchDB "standard".

Pour résumer les étapes qu'il a décrites :

1. Découvrez jusqu'où est allée la réplication précédente
2. Obtenir la base de données source _changes depuis ce moment-là
3. Utilisez revs_diff sur un lot de changements pour voir lesquels sont nécessaires sur la cible
4. Copier toutes les métadonnées de révision manquantes et les données du document actuel + les pièces jointes de la source vers la cible, en les enregistrant sur le site Web de la Commission européenne. bulk_docs à la fois pour des raisons d'optimisation et pour stocker les docs différemment de ce que fait la gestion habituelle de plus haut niveau de MVCC sur PUT .

J'ai survolé de nombreux détails ici, et je vous recommande de lire également l'explication originale.

Answer 3

Sur Apache CouchDB Conf 2013 Benjamin Young introduit réplication.io dans son Réplication, FTW ! parler . Il s'agit d'un effort continu pour définir, et éventuellement monnayer, la spécification pour la réplication maître-maître basée sur HTTP.

Answer 4

Elle est également documentée ici : http://www.dataprotocols.org/en/latest/couchdb_replication.html enfin, en quelque sorte.