À la recherche d’un SQLite plus rapide

• SQLite est déjà un système de base de données rapide, mais des chercheurs cherchent encore des moyens de l’accélérer davantage.
• Des chercheurs de l’Université d’Helsinki et de Cambridge ont publié un article intitulé « co-conception runtime serverless/base de données via les E/S asynchrones », montrant qu’il est possible de réduire la latence de queue (tail latency) jusqu’à 100 fois. Cet article sert de base à Limbo, une réécriture de SQLite en Rust.

io_uring

• Description de io_uring : le sous-système io_uring du noyau Linux fournit une interface pour les E/S asynchrones. Il réduit le surcoût des copies de tampon grâce à un buffer circulaire entre l’espace utilisateur et l’espace noyau. Une application peut soumettre des requêtes d’E/S et effectuer d’autres tâches jusqu’à ce que l’OS signale la fin des opérations.

• Exécution des requêtes dans SQLite : SQLite utilise des fichiers pour stocker les données, ouvre la base avec la fonction sqlite3_open() et convertit les instructions SQL en bytecode avec sqlite3_prepare(). La fonction sqlite3_step() exécute ensuite les instructions du bytecode pour traiter la requête.

Prémisses

• Essor du serverless : dans les environnements serverless, la latence de la base de données peut devenir un problème. Si la base est directement embarquée dans le runtime edge, il n’y a pas de latence réseau, et SQLite convient bien à ce type d’environnement.

• Problèmes de SQLite : l’utilisation d’E/S synchrones empêche une utilisation optimale des ressources et pose des problèmes de concurrence et de multi-tenant.

• Passage à io_uring : remplacer les appels d’E/S POSIX par io_uring n’est pas simple, et il faut repenser SQLite pour l’adapter à un modèle d’E/S asynchrones.

Limbo

• Prise en charge des E/S asynchrones : les composants VM et BTree ont été modifiés pour prendre en charge les E/S asynchrones, en remplaçant les instructions synchrones du bytecode par des instructions asynchrones. Les E/S asynchrones éliminent le blocage et améliorent la concurrence.

• Séparation du moteur de requêtes et du moteur de stockage : il est proposé de séparer le moteur de requêtes du moteur de stockage afin de maximiser l’utilisation des ressources.

Évaluation et résultats

• Benchmarking : un runtime serverless multi-tenant a été simulé de sorte que chaque tenant dispose de sa propre base embarquée. En comparant la latence des requêtes entre SQLite et Limbo, Limbo réduit la latence de queue au niveau p999 d’un facteur 100.

• Travaux futurs : d’autres benchmarks incluant plusieurs lecteurs et rédacteurs sont prévus, et l’avantage en performance ne devient vraiment marqué qu’au-delà de p999.

• Code open source : le code de Limbo est disponible en open source : Limbo GitHub

[GN⁺]

Commentaires sur Hacker News

• Discussion sur le fait que certains cas d’usage du serverless computing, par exemple AWS Lambda avec une base de données centrale, ne s’accordent pas toujours bien avec des applications conçues de manière serverless

  • Il y a 6 ou 7 ans, quelqu’un a travaillé sur un problème nécessitant de traiter des fichiers hiérarchiques complexes et d’en extraire certaines informations
  • Le FaaS coûte cher pour les tâches gourmandes en calcul, et charger puis parser de gros fichiers XML à chaque fois était inefficace
  • La solution a consisté à utiliser une fonction centrale exécutée par un minuteur pour lire et parser les fichiers, les charger dans une base de données SQLite, les indexer, puis stocker les fichiers dans S3
  • Les fonctions Lambda téléchargeaient le fichier depuis S3 et effectuaient les recherches s’il était plus récent que la copie locale ou en cas de cold start
  • Il a été constaté que Lambda dispose d’un répertoire local /tmp et que le runtime Python inclut SQLite, donc il n’était pas nécessaire de déployer du code supplémentaire en dehors de la fonction
  • Il est intéressant de voir qu’un travail est en cours pour rendre ce type de solution encore plus rapide

• Il pourrait être utile de préciser que l’un des deux chercheurs est le supérieur hiérarchique de l’auteur

  • Il a été supposé à tort que l’auteur et les chercheurs n’avaient aucun lien

• Accord avec l’idée que « les gains ne sont vraiment visibles qu’au-delà de p999, et qu’à p90 et p99 les performances sont presque identiques à celles de SQLite »

  • SQLite et les optimisations sont appréciés, mais c’est effectivement vrai

• SQLite dispose d’une suite de tests très étendue et a donc été testé de manière approfondie

  • Une question se pose sur le fait de savoir si la réécriture bénéficiera de tests comparables, surtout en utilisant des fonctionnalités rapides mais difficiles à programmer et potentiellement sujettes aux bugs, comme io_uring

• Pour les benchmarks, un runtime serverless multi-tenant a été simulé, où chaque tenant possède sa propre base de données embarquée

  • SQLite dispose de son propre thread par tenant, et les requêtes sont exécutées dans chaque thread pour les mesures
  • Question sur le fait de savoir si une configuration SQLite serverless utiliserait un processus SQLite par requête

• Il y a déjà eu par le passé des tentatives d’introduire l’I/O asynchrone dans Postgres, mais elles ont été abandonnées

  • Une proposition récente vise à permettre le remplacement personnalisé du gestionnaire de stockage sans avoir à forker la base de code
  • Il y a beaucoup d’intérêt pour cette nouvelle proposition, en lien avec le mouvement de séparation entre stockage et calcul

• Question sur l’idée qu’on puisse faire autre chose pendant que l’I/O asynchrone est en cours

  • Interrogation sur le fait de savoir s’il faut tout de même attendre la fin de la transaction lorsqu’on travaille avec une base de données

• En tant qu’auteur du billet de blog, quelqu’un ne s’attendait pas à ce que cet article arrive en première page

  • Il travaille chez Turso, l’article académique a été publié en avril 2024, et de nombreuses améliorations ont été apportées depuis

• SQLite est open source, mais son important harnais de test ne l’est pas

  • Question sur la manière dont une alternative pourrait garantir la compatibilité

• Quelqu’un a essayé de trouver une voie simple pour créer, comme sous-ensemble strict du format de fichier SQLite, un format proche de JSON, mais sans succès

  • Il y a beaucoup d’arbitraire dans le format de fichier, ce qui a fait perdre l’intérêt pour le sujet, même si quelqu’un d’autre pourrait y parvenir