Limbo - une réécriture complète de SQLite en Rust

• Limbo est un projet expérimental qui réimplémente SQLite en Rust afin d’offrir la sûreté mémoire
  • Ils apprécient la nature embarquée de SQLite, mais voulaient un modèle de développement plus ouvert, ce qui a conduit au lancement du projet libSQL
• Pourquoi avoir forké SQLite : cela permet d’intégrer plus facilement de nouvelles fonctionnalités tout en conservant la compatibilité avec le code existant
  • Inconvénient : la suite de tests de SQLite est propriétaire et écrite en C, ce qui complique l’évolution du code
• Nouvelle approche
  • L’ajout de fonctions de recherche vectorielle leur a fait toucher les limites de SQLite
  • Réécrire SQLite depuis zéro pour préserver la compatibilité tout en explorant la possibilité d’ajouter des fonctionnalités de manière plus ambitieuse
• Prochaines étapes
  • Faire de Limbo un projet officiel de Turso
  • Objectif : construire une nouvelle architecture offrant la sûreté mémoire tout en conservant le même niveau de fiabilité que SQLite
• Remettre en jeu la fiabilité de SQLite
  • Obtenir un haut niveau de fiabilité grâce à des tests de simulation déterministe (DST)
  • Utilisation d’un framework DST au niveau système en collaboration avec Antithesis
• État actuel
  • E/S entièrement asynchrones : Limbo adopte une conception totalement asynchrone, ce qui résout les problèmes de l’interface synchrone de SQLite
  • Conçu pour WASM : une architecture pensée pour une utilisation dans des environnements WASM
  • Performances : des performances équivalentes ou supérieures à celles de SQLite sur de nombreuses charges de travail
  • Simplicité : une meilleure expérience utilisateur grâce à la suppression de fonctionnalités moins importantes dans les environnements modernes
• Informations supplémentaires
  • Limbo est disponible sur GitHub sous licence MIT
  • Invitation à toutes les personnes intéressées par la création de bases de données embarquées visant à faire franchir une nouvelle étape à la promesse de SQLite

[seonwoo960000]

C’est amusant de voir un projet auquel je contribuais apparaître sur Hacker News haha

[GN⁺]

Avis Hacker News

• SQLite semble être un projet qui n’a pas besoin d’être réécrit, en raison de la qualité de son code et de la rigueur de ses tests

  • Certains estiment qu’il vaudrait mieux réécrire d’autres projets en C en priorité

• Le débat selon lequel SQLite ne serait pas « ouvert aux contributions » néglige le fait qu’accepter des contributions ne signifie pas toujours les intégrer

  • SQLite dispose d’une procédure de contribution et fonctionne en implémentant les fonctionnalités proposées
  • D’autres projets de l’écosystème SQLite, comme Litestream et LiteFS, ont eux aussi des politiques de contribution similaires

• Certains étaient négatifs lors de l’annonce initiale du fork de SQLite3 vers LibSQL

  • Ils pensaient que le fork risquait d’échouer, car la suite de tests de SQLite3 est propriétaire
  • Mais s’il existe un objectif produit majeur, comme une réécriture dans un langage à mémoire sûre, alors le fork peut avoir du sens

• Pour des performances maximales, il faut choisir le mode WAL et désactiver les verrous consultatifs POSIX

  • Certains se demandent si le mode wal2 figure dans le radar du projet

• Certains disent avoir appris pour la première fois que la suite de tests de SQLite est propriétaire

  • Android a été construit d’une manière similaire, mais c’est un autre sujet

• Certains n’adhèrent pas à la logique de la section sur l’async IO

  • Ils estiment qu’il n’est pas nécessaire de réécrire SQLite pour lui ajouter une interface asynchrone
  • Le problème de l’interface synchrone de SQLite est que le thread reste inactif pendant l’attente des E/S
  • SQLite est conçu pour s’exécuter très près du stockage, de sorte que le blocage des E/S peut être très court, voire inexistant

• Certains estiment qu’il s’agit d’un projet à un stade précoce

  • Un exemple de code utilisant Python et Limbo est fourni

• En compilant avec Fil-C, on peut obtenir un SQLite à mémoire sûre

  • Seuls de légers changements sont nécessaires et il passe presque entièrement la suite de tests

• SQLite se compose d’environ 156�000 lignes de code et 92�000 lignes de code de test

• On suppose que la certification DO-178B pour la variante Rust n’est pas envisagée

• Le nom « Limbo » est aussi utilisé pour le langage post-C/UNIX de l’OS Inferno d’AT&T

[aer0700]

SQLite semble être un projet qui n’a pas besoin d’être réécrit grâce à la qualité de son code et à la rigueur de ses tests -> cette appréciation de SQLite est vraiment enviable et impressionnante.

[regentag]

Il suit le processus DO-178B et aurait atteint 100 % de couverture de code MC/DC.
L’histoire méconnue de SQLite