Stockage SQLite à latence nulle dans chaque Durable Object

 (simonwillison.net)
2 points par GN⁺ 2024-10-15 | 1 commentaires | Partager sur WhatsApp

  • Zero-latency SQLite storage in every Durable Object

    • Kenton Varda présente la prochaine version de la plateforme Durable Object de Cloudflare. Celle-ci a récemment été mise à niveau d’un stockage clé/valeur vers un système relationnel complet basé sur SQLite
    • Pour un contexte utile sur la première version de Durable Objects, on peut consulter durable multiplayer moat de Cloudflare par Paul Butler. Cette approche est populaire pour créer des applications collaboratives en temps réel basées sur WebSocket
    • Les nouveaux Durable Objects basés sur SQLite constituent un élément fascinant de conception de systèmes distribués, proposant une manière intéressante de concevoir des applications à grande échelle

  • Idée centrale des Durable Objects

    • Un Durable Object place la logique applicative et les données sur le même hôte physique, ce qui permet des lectures et écritures très rapides
    • Un objet unique s’exécute sur un seul thread d’une seule machine, donc son débit est limité. Pour gérer davantage de trafic, on crée plus d’objets. Cela fonctionne surtout lorsque chaque unité d’état a un trafic suffisamment faible pour être géré par un seul objet

  • Exemple d’un système de réservation de vols

    • Chaque vol peut être mappé à un Durable Object dédié avec sa propre base de données SQLite. Des milliers de nouvelles bases de données sont créées chaque jour pour chaque compagnie aérienne
    • Chaque DO possède un nom unique, et le réseau de Cloudflare achemine les requêtes vers cet objet où qu’il se trouve dans le monde

  • Détails techniques

    • Inspiré de Litestream, chaque DO diffuse en continu une séquence d’entrées WAL vers un object store. Cela est regroupé tous les 16 Mo ou toutes les 10 secondes
    • Pour garantir la durabilité pendant cette fenêtre de 10 secondes, les écritures sont transmises dès leur validation à cinq répliques dans des data centers proches, et l’écriture est reconnue une fois que trois d’entre elles l’ont confirmée

  • Conception de l’API JavaScript

    • Elle est conçue de manière bloquante plutôt qu’asynchrone. L’objectif est de fournir des opérations de persistance rapides sur un seul thread
    • Des exemples montrent volontairement un motif de requêtes N+1 que SQLite sait bien gérer

  • Storage Relay Service

    • Il s’agit du système sous-jacent des Durable Objects, et il prend déjà en charge le système SQLite D1 existant de Cloudflare depuis plus d’un an

  • Lieu de création des Durable Objects

    • Une fois créés, les Durable Objects ne changent pas d’emplacement. Par défaut, ils sont instanciés dans le data center où la requête get() initiale est effectuée
    • Pour créer manuellement des Durable Objects à un autre endroit, on fournit le paramètre optionnel locationHint à get()

  • Site where.durableobjects.live

    • Il s’agit d’un site qui permet de suivre l’endroit où les DO sont créés sur le réseau Cloudflare

Récapitulatif GN⁺

  • Les Durable Objects de Cloudflare, désormais basés sur SQLite, ouvrent de nouvelles possibilités pour la conception d’applications à grande échelle. Ils offrent de hautes performances en plaçant les données et la logique applicative sur le même hôte physique
  • Ce système est particulièrement utile pour les applications collaboratives en temps réel et offre la flexibilité nécessaire pour gérer diverses unités d’état
  • Durable Objects crée des répliques dans plusieurs data centers afin de garantir la durabilité des données, ce qui renforce la stabilité et la fiabilité
  • Cette technologie peut intéresser les développeurs qui travaillent sur la conception de grands systèmes distribués. Des systèmes offrant des fonctionnalités similaires incluent Amazon DynamoDB et Google Firestore

À lire aussi

1 commentaires

 
GN⁺ 2024-10-15
Commentaires Hacker News

  • L’API d’écriture est synchrone, mais comporte une attente asynchrone cachée. Si une écriture échoue, le runtime remplace la réponse par un échec HTTP, ce qui permet de traiter automatiquement les écritures par lots et de supposer leur réussite

    • Il n’y a pas de transaction de lecture, donc il est difficile d’obtenir un snapshot à un instant donné
    • Chaque instance du runtime est limitée à 128 Mo de RAM
    • Les WebSockets peuvent être mis en hibernation, sans coût pendant cette période. Cela permet aux clients de conserver la connexion même lorsque le DO est en veille
    • Il existe une fonctionnalité RPC automatique permettant de communiquer avec d’autres DO ou workers comme avec de simples appels JS. Le runtime gère la sérialisation et l’analyse

  • Chaque DO diffuse une séquence d’entrées WAL vers object storage, regroupée par lots tous les 16 Mo ou toutes les 10 secondes

    • À l’échelle mondiale, il peut s’écouler jusqu’à 10 secondes entre l’écriture et la lecture
    • Difficile de remplacer un cluster de bases de données déployé régionalement

  • J’aime la conception des Durable Objects. Leur fonctionnement interne est facile à comprendre

    • Les DO sont bien adaptés à la création d’expériences temps réel rapides et peu coûteuses, mais l’analytique et la génération de vues d’ensemble sont difficiles
    • Si les données sont stockées dans SQLite, il faut interroger plusieurs petites instances SQLite et fusionner les résultats

  • Il est difficile de comprendre où se trouvent physiquement les Durable Objects

    • Je me demande s’ils sont situés dans la région où l’appel API a lieu
    • Je me demande si un DO peut se déplacer automatiquement vers un autre emplacement

  • Il est difficile de comprendre les nouvelles technologies cloud

    • J’ai plus de 15 ans d’expérience en développement web, mais j’ai l’impression que ce type de technologie n’est pas fait pour moi

  • Je me demande comment gérer les migrations de schéma

    • Si une base de données existe par tenant, appliquer les changements de schéma à chaque DO semble difficile

  • La conception des DO est intéressante, mais j’ai l’impression qu’elle ne convient qu’aux systèmes à forte charge ou aux projets jouets

    • En production, il faut des systèmes éprouvés, et les DO ne sont pas encore assez matures

  • Je suis impressionné par la conception des DO. J’ai l’impression que leur manière de traiter des tâches complexes à petite échelle ressemble à la structure d’un vrai produit

  • Je remarque que CF encourage les développeurs à utiliser les DO

    • Les connexions WebSocket des workers expirent après 30 secondes, et l’utilisation des DO est recommandée

  • Je me demande si les DO correspondent au « modèle » dans une architecture MVC

    • Je me demande comment utiliser des DO par tenant, puis interroger ou faire des jointures sur l’ensemble des DO