IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La version 2.0 d'Automerge, un CRDT qui permet d'enregistrer les modifications apportées aux données, est disponible,
Avec des améliorations de performance et de fiabilité

Le , par Bruno

25PARTAGES

4  0 
L’équipe chargée du développement d’Automerge a annoncé la sortie de la version 2.0 d’Automerge. « Automerge 2.0 est là, il est prêt pour vous, et nous sommes très heureux de le partager avec vous. Nous avons rendu Automerge plus rapide, plus efficace en termes de mémoire, et nous l'apportons à plus de plateformes que jamais », écrit l'équipe chargée de son développement.

Automerge 2.0 est la première version supportée résultant d'une réécriture complète. Le résultat est un CRDT (Conflict-free Replicated Data Type ) prêt pour la production avec d'énormes améliorations en termes de performance et de fiabilité. Il est disponible à la fois en JavaScript et Rust, et inclut des types TypeScript et des liaisons C pour une utilisation dans d'autres écosystèmes. Mieux encore, Automerge 2.0 est livré avec une documentation améliorée et, pour la première fois, des options de support pour les utilisateurs en production.


Automerge est un CRDT qui permet d'enregistrer les modifications apportées aux données, puis de les rejouer à d'autres endroits, en produisant de manière fiable le même résultat à chaque fois. Il prend en charge les données de type JSON, y compris les cartes et les tableaux imbriqués arbitrairement, ainsi que certains types de données plus avancés tels que le texte et les compteurs numériques.

Type de données répliqué sans conflit (CRDT)

Un Conflict-free Replicated Data Type en français, type de données répliqué sans conflit, ou CRDT est une structure de données qui simplifie les systèmes de stockage de données distribués et les applications multi-utilisateurs. Dans de nombreux systèmes, des copies de certaines données doivent être stockées sur plusieurs ordinateurs (appelés répliques). Voici quelques exemples de tels systèmes :

  • Les applications mobiles qui stockent des données sur le périphérique local, et qui doivent synchroniser ces données avec d'autres périphériques appartenant au même utilisateur (comme les calendriers, les notes, les contacts ou les rappels) ;
  • Les bases de données distribuées, qui maintiennent plusieurs répliques des données (dans le même centre de données ou dans différents endroits) afin que le système continue de fonctionner correctement si certaines des répliques sont hors ligne ;
  • Les logiciels de collaboration, tels que Google Docs, Trello, Figma, ou bien d'autres, dans lesquels plusieurs utilisateurs peuvent apporter simultanément des modifications au même fichier ou aux mêmes données ;
  • les systèmes de stockage et de traitement de données à grande échelle, qui répliquent les données afin d'obtenir une évolutivité globale.

Les CRDT sont utilisés dans les systèmes avec réplication optimale, où ils prennent en charge la résolution des conflits. Les CRDT garantissent que, quelles que soient les modifications apportées aux données sur les différentes répliques, les données peuvent toujours être fusionnées dans un état cohérent. Cette fusion est effectuée automatiquement par le CRDT, sans nécessiter de code spécial de résolution de conflit ou d'intervention de l'utilisateur.

En outre, une caractéristique importante des CRDT est qu'ils supportent un fonctionnement décentralisé : ils ne supposent pas l'utilisation d'un serveur unique, ils peuvent donc être utilisés dans des réseaux peer-to-peer et d'autres environnements décentralisés. À cet égard, les CRDT diffèrent des algorithmes utilisés par Google Docs, Trello et Figma, qui exigent que toute communication entre utilisateurs passe par un serveur.

Automerge-RS : reconstruit pour la performance et la portabilité

Les versions précédentes d'Automerge étaient implémentées en JavaScript. Les implémentations initiales étaient théoriquement valables, mais beaucoup trop lentes et utilisaient trop de mémoire pour la plupart des cas d'utilisation en production.

De plus, le support de JavaScript sur les appareils mobiles et les systèmes embarqués est limité. « Nous voulions une version rapide et efficace d'Automerge qui soit disponible partout : dans le navigateur, sur n'importe quel appareil mobile, et même sur des microcontrôleurs comme l'ESP32 », indique l’équipe chargée d’Automerge.

Au lieu d'essayer de coordonner plusieurs versions distinctes d'Automerge, elle a décidé de réécrire Automerge en Rust et d'utiliser des wrappers spécifiques aux plateformes pour le rendre disponible dans chaque écosystème linguistique. De cette façon, elle pouvait être sûre que la logique de base de CRDT est identique sur toutes les plateformes et que tout le monde bénéficie des nouvelles fonctionnalités et optimisations.

Pour les applications JavaScript, cela signifie compiler Rust en WebAssembly et fournir un wrapper JavaScript qui maintient l'API Automerge existante. Les applications Rust peuvent évidemment utiliser la bibliothèque directement, et « nous nous assurons qu'il est aussi facile que possible d'implémenter le support dans d'autres langages avec des traits bien conçus et un ensemble complet de liaisons C », indique l’équipe Automerge.

Pour livrer cette nouvelle version, les membres du laboratoire Alex Good et Orion Henry ont fait équipe avec des collaborateurs open source, dont Andrew Jeffery et Jason Kankiewicz, pour peaufiner et optimiser l'implémentation Rust et le wrapper JavaScript. Le résultat est une base de code qui serait des centaines de fois plus rapide que les versions précédentes, radicalement plus économe en mémoire, mieux testée et plus fiable.

Avec Automerge 2.0, l’équipe a fait un gros investissement pour améliorer la documentation. En plus des exemples de code, elle dispose maintenant d'un tutoriel et d'un guide de démarrage rapide qui prennent en charge Vite et create-react-app, ainsi que de la documentation interne, du format de fichier et du protocole de synchronisation.

Performances : Vitesse, mémoire et disque

Le but de tous les auteurs de CRDT est de trouver les bons compromis entre la préservation de l'historique utile, la réduction de la surcharge de la CPU et le stockage efficace des données en mémoire et sur disque. L'utilisation d'un CRDT s'accompagne intrinsèquement de frais généraux : il faut suivre des informations supplémentaires afin de pouvoir fusionner correctement des travaux provenant de sources différentes.

Avec le projet Automerge, l’objectif est de conserver l'historique complet de tout document et de permettre à un auteur de reconstruire n'importe quel point dans le temps sur demande. En tant que développeurs de logiciels, il est difficile d'imaginer un contrôle de version sans historique.

Avec Automerge 2.0, un format de données binaire efficace avec des performances rapides de mise à jour, d'enregistrement et de chargement a été réuni. Sans trop entrer dans les détails, l’équipe dit être parvenu en regroupant les données de manière efficace en mémoire, en veillant à ce que les données connexes soient stockées à proximité les unes des autres pour une récupération rapide.

L'un des critères de référence les plus difficiles pour les CRDT est la collaboration textuelle en temps réel. En effet, une longue session d'édition peut se traduire par des centaines de milliers de frappes individuelles à enregistrer et à synchroniser. Martin Kleppmann a enregistré les frappes de touches effectuées lors de la rédaction d'un article universitaire et la relecture de ces données est devenue un repère populaire pour les CRDT.


Bien entendu, même les auteurs les plus productifs ont du mal à taper un article entier aussi rapidement. En effet, la rédaction d'un article peut s'étaler sur des mois, voire des années, d'où l'importance de la taille de stockage sur le disque et des performances de chargement.


Le format binaire fonctionne à merveille dans cet exemple, puisqu'il code l'historique complet du document avec seulement 30 % de surcharge. C'est moins d'un octet supplémentaire par caractère ! L'encodage en format JSON souvent utilisé dans la version 0.14 d'Automerge pouvait dépasser 1 300 octets par caractère.


Le chargement du document compressé serait également rapide, ce qui aurait pour conséquence de garantir le meilleur temps de démarrage possible. « Bien que nous soyons fiers de ces résultats, nous continuerons à investir dans l'amélioration des performances à chaque version, comme vous pouvez le constater avec les chiffres préliminaires de la prochaine version 2.0.2 d'Automerge », écrit l’équipe Automerge.

Les améliorations trouvées dans "2.0.2-unstable" résultent principalement d'une amélioration à venir de l'API pour le texte. Notons également que la version automerge 1.0.1 est en fait la version automerge@1.0.1-preview-7. Automerge 1.0.1 est une réécriture significative de la 0.14 et a une architecture similaire à l'implémentation Rust. Les améliorations entre 1.0.1 et 2.0.1 sont le résultat de l'optimisation et de l'adoption de WebAssembly plutôt qu'un changement d'architecture.

Automerge-Repo

L’équipe en charge a travaillé pour qu'Automerge reste indépendant des plateformes et prenne en charge une grande variété d'environnements de déploiement. Elle n'avait pas besoin d'une pile réseau ou d'un système de stockage particulier, et Automerge a été utilisé avec succès dans des applications web client-serveur, des logiciels de bureau en peer-to-peer, et comme moteur de synchronisation de données pour des services en cloud. Malheureusement, l'exclusion du réseau et du stockage de la bibliothèque a laissé une grande partie du travail aux développeurs d'applications, et leur a demandé d'en apprendre beaucoup sur les systèmes distribués juste pour démarrer.

La nouvelle bibliothèque, Automerge-Repo, est une approche modulaire avec batteries incluses pour construire des applications web avec Automerge. Elle fonctionne à la fois dans le navigateur (bureau et mobile) et dans Node, et supporte une variété d'adaptateurs de réseau et de stockage. Il y a même des bindings d'éditeur de texte pour Quill et Prosemirror ainsi que des React Hooks pour faciliter un démarrage rapide.

Synchronisation améliorée

Le système de synchronisation actuel d'Automerge a de grandes propriétés. Dans de nombreux cas, il peut mettre à jour deux clients avec seulement un seul aller-retour dans chaque direction. Cela dit, un grand potentiel d'amélioration des performances CPU de ce processus est possible, et aussi beaucoup d'opportunités d'améliorer les performances de synchronisation de nombreux documents à la fois.

Source : Automerge

Et vous ?

Quelle appréciation faites-vous d'Automerge et des CRDT en général ?

Avez-vous déjà utilisé un CRDT ? Jugez-vous vous nécessaire l'utilisation des CRDT ?

Voir aussi :

Elastic annonce des améliorations pour la recherche et la réplication inter-clusters : une résilience accrue, une latence réduite, et accès aux données dans les environnements sur site et cloud

HC-tree, un dorsal expérimental de base de données haute-concurrence pour SQLite, il vise à développer un nouveau module de base de données qui améliore SQLite

Une erreur dans cette actualité ? Signalez-nous-la !