1 points par GN⁺ 2025-04-02 | 1 commentaires | Partager sur WhatsApp

Une nouvelle approche de la réplication en périphérie

  • La synchronisation des données est un problème plus difficile qu’il n’y paraît. Les solutions existantes se divisent entre la synchronisation de l’ensemble du jeu de données vers le client et le suivi des modifications logiques.
  • Graft a été conçu pour résoudre ces problèmes et constitue un moteur de stockage open source qui combine une réplication physique simple et une réplication logique efficace.

Synchronisation paresseuse : synchroniser au rythme souhaité

  • Graft permet aux clients de choisir quand se synchroniser, ce qui le rend adapté aux environnements edge connectés au réseau de manière intermittente.
  • Le serveur fournit l’index des pages modifiées depuis le dernier instantané du client, et le client peut récupérer de manière sélective uniquement les données dont il a besoin.

Synchronisation partielle : ne synchroniser que le nécessaire

  • Dans les environnements edge, il n’est pas possible de télécharger l’ensemble du jeu de données ; Graft prend donc en charge la synchronisation partielle en récupérant sélectivement uniquement les pages nécessaires.
  • Graft peut précharger les pages nécessaires en s’appuyant sur des algorithmes de prédiction généraux et sur la connaissance du domaine.

Edge : synchroniser au plus près de l’endroit nécessaire

  • Graft distribue les données via des serveurs edge dans le monde entier, afin de maintenir une faible latence et une forte réactivité où que se trouvent les utilisateurs.
  • Le client est conçu pour être léger et peut être facilement intégré dans des navigateurs, des applications mobiles et des environnements serverless.

Cohérence : une synchronisation sûre

  • Graft fournit un modèle de cohérence fort, permettant de gérer en toute sécurité les conflits entre clients.
  • Grâce au modèle d’isolation par instantané, les clients obtiennent une vue cohérente des données, tandis que les écritures sont strictement sérialisées.

Que peut-on construire avec Graft ?

  • Graft offre une base solide pour divers types d’applications edge-native.
  • Il permet des applications offline-first, des données cross-platform, des réplicas de lecture sans état et la réplication de données arbitraires.

Extension SQLite de Graft (libgraft)

  • libgraft est une extension native de SQLite qui permet d’exécuter SQLite même dans des environnements aux ressources limitées, en ne répliquant que la partie de la base de données réellement utilisée par le client.
  • Elle fournit des fonctionnalités telles que la réplication asynchrone, la réplication partielle paresseuse, l’isolation par instantané et la restauration à un instant donné.

Comment participer

  • Graft est développé sur GitHub et accueille avec plaisir les contributions de la communauté.
  • Il est possible de rejoindre Discord ou d’envoyer des retours par e-mail.
  • Il est également possible de s’inscrire sur la liste d’attente du service managé Graft.

Feuille de route

  • Graft est encore en cours de développement, avec des projets tels que la prise en charge de WebAssembly, l’intégration avec SQLSync et la prise en charge de diverses bibliothèques clientes.
  • Des fonctionnalités comme la réduction de la latence d’écriture, le garbage collection, l’authentification et l’autorisation, le volume forking et la gestion des conflits sont également prévues.

Comparaison avec d’autres solutions de réplication SQLite

  • Graft présente des avantages distinctifs par rapport à mvSQLite, Litestream, cr-sqlite, Cloudflare Durable Objects, Cloudflare D1, Turso & libSQL, rqlite & dqlite, Verneuil et d’autres.
  • Ses principaux points de différenciation sont la réplication partielle, la prise en charge de structures de données arbitraires et une réplication efficace en edge.

1 commentaires

 
GN⁺ 2025-04-02
Avis Hacker News
  • Le modèle de cohérence n’est pas clair

    • Le client Graft valide en local puis tente une validation à distance de manière asynchrone
    • Si deux clients valident simultanément à partir du même snapshot, l’un réussit et l’autre échoue
    • L’API ne fournit qu’une seule opération de commit
    • Si la validation locale réussit mais que la propagation asynchrone échoue, cela pose un problème de rollback
    • Plusieurs concepts de « commit » semblent être mélangés
  • L’auteur de Graft remercie les participants

    • Il assiste à l’Antithesis BugBash à Washington DC
    • Il aimerait rencontrer des personnes présentes à Washington
  • Le modèle de cohérence est compris comme similaire à git

    • On modifie une copie locale et des conflits peuvent survenir au moment du « push »
    • Il n’existe pas de moyen propre de détecter les conflits
    • Des conflits peuvent se produire à cause de conflits de lecture
  • Quand un client récupère Graft, il peut savoir exactement ce qui a changé

    • Comparaison avec le manifeste de Cloud-Backed SQLite
    • Aucun calcul côté serveur n’est nécessaire
  • Aucun détail d’implémentation n’est mentionné

    • Il faut une couche de synchronisation qui permette aux développeurs d’applications de ne pas se soucier de la synchronisation
    • Cela pourrait permettre une synchronisation personnelle sans abonnement
  • L’utilisation de VFS est considérée comme un « hack » amusant

    • Développement en cours d’un moteur de synchronisation maison pour un IDE offline-first
    • La résolution de conflits avec une structure en arbre est un défi
  • Le projet utilisant l’algorithme Leap est très intéressant

    • Il est facile de se concentrer sur l’intégration avec SQLite, mais l’approche vise un problème de stockage distribué plus général et de plus bas niveau
    • Une solution générale sans expérience concrète peut être risquée
  • Des problèmes peuvent survenir quand un client mobile est sur une connexion lente

    • Proposition d’une approche hybride qui détecte une synchronisation lente et envoie directement les requêtes au serveur
  • L’approche qui utilise la page comme unité de synchronisation de base est intéressante

    • Des conflits peuvent survenir avec un grand nombre d’utilisateurs simultanés
    • OT ou CRDT pourrait être préférable
  • C’est un problème très difficile

    • Envie d’essayer cela dans une application React Native