SQLite est 138x plus lent que ça ?! (Test de Stoolap)

BBetter Stack
Computing/SoftwareInternet Technology

Transcript

00:00:00Lorsque vous lancez un nouveau projet et que vous avez besoin d'une base de données, quelle est la première option qui
00:00:03vous vient à l'esprit ? SQLite ? C'est probablement SQLite, n'est-ce pas ? C'est génial, fiable,
00:00:09sans configuration et c'est un standard de l'industrie. Mais à mesure que nos données locales s'alourdissent et que nos requêtes
00:00:14deviennent plus complexes, on commence à atteindre les limites de ce qu'un moteur
00:00:20monothread à verrouillage de fichiers peut faire. Mais un nouvel acteur vient d'arriver pour résoudre ces problèmes.
00:00:25Il s'appelle Stulab. C'est un moteur de base de données entièrement écrit en Rust, et il vient de sortir
00:00:31un driver natif Node.js qui affiche, pour être honnête, de très solides performances. Cette
00:00:36base de données est 138 fois plus rapide que SQLite. Dans cette vidéo, nous allons donc regarder
00:00:43sous le capot de Stulab pour voir comment ça marche et lancer un benchmark en direct pour voir s'il est aussi puissant
00:00:50qu'il le prétend. Ça va être passionnant, alors plongeons dans le vif du sujet. Qu'est-ce que Stulab au juste ?
00:01:00À la base, Stulab est une base de données OLAP embarquée, c'est-à-dire pour le traitement analytique en ligne. Si
00:01:06vous avez l'habitude des bases de données standards comme SQLite ou Postgres, ce sont généralement des bases OLTP
00:01:14ou de traitement transactionnel en ligne, qui sont, comme leur nom l'indique, optimisées pour les transactions. Mais
00:01:20Stulab est différent. Il est conçu pour les charges de travail analytiques et construit de A à Z en Rust
00:01:27en se concentrant sur le traitement de données à haute vitesse. Voyez-le comme ayant la portabilité d'un fichier SQLite,
00:01:33mais avec la puissance analytique brute d'un DuckDB ou d'un BigQuery. Mais le plus cool,
00:01:39c'est que vous pouvez désormais l'utiliser avec Node.js grâce à son driver natif. Et quand je dis
00:01:45driver natif, je ne parle pas d'un simple adaptateur standard. Habituellement, lorsqu'une base de données
00:01:49est écrite dans un autre langage comme Rust ou C++, votre application Node.js doit communiquer via un pont.
00:01:56Cela signifie souvent convertir vos données en JSON ou un autre format, les envoyer via un socket réseau local
00:02:02puis les convertir à nouveau de l'autre côté. C'est ce qu'on appelle le surcoût de sérialisation, et
00:02:08c'est un énorme frein à la performance. Mais Stulab Node fait les choses différemment. Il utilise NAPI-RS,
00:02:15un framework qui permet de compiler le moteur Rust en un binaire natif qui se charge
00:02:21directement dans votre processus Node.js. Il n'y a donc plus de pont ni de traducteur intermédiaire. Quand vous envoyez
00:02:27une requête, Node.js et Rust partagent essentiellement le même espace mémoire. Et il y a trois raisons majeures
00:02:33pour lesquelles Stulab est incroyablement rapide. Premièrement, il utilise le MVCC ou contrôle de concurrence multi-versions.
00:02:40Contrairement à SQLite où un seul scripteur peut verrouiller toute la base, Stulab permet à plusieurs lecteurs
00:02:47et scripteurs de travailler simultanément. Deuxièmement, il utilise l'exécution parallèle. Stulab utilise un ordonnanceur
00:02:53appelé Rayon. Avec Rayon, lorsque vous lancez une requête massive, au lieu de n'utiliser qu'un seul cœur CPU, il fragmente
00:03:00la requête et utilise chaque cœur disponible sur votre machine. Et troisièmement, il utilise un optimisateur
00:03:06basé sur les coûts. Il n'exécute pas SQL aveuglément : il analyse vos données, estime
00:03:13le coût des différents chemins et choisit le moyen le plus rapide d'obtenir vos résultats. Voilà ce qui ferait
00:03:19de Stulab une option bien plus rapide que SQLite. Mais testons cela pour voir si c'est vraiment le cas.
00:03:25Pour ce test, nous utiliserons un projet Node.js simple et nous installerons Stulab ainsi que
00:03:30SQLite en tant que dépendances. L'un des plus grands atouts de Stulab est l'utilisation du “count distinct”.
00:03:37Je suis donc curieux de savoir si c'est vraiment le cas. J'ai configuré ce script simple où nous lançons
00:03:43une version en mémoire de chaque base et créons une table de ventes. Nous remplissons ensuite cette table
00:03:49avec 10 000 lignes de données de ventes aléatoires, où chaque ligne représente une vente d'un utilisateur dont l'ID varie
00:03:56de 0 à 1 000 dans une catégorie spécifique. Nous allons ensuite insérer les données par lots dans
00:04:03les deux bases, puis lancer le benchmark en sélectionnant un décompte distinct des ventes effectuées par un utilisateur
00:04:10donné dans une catégorie précise, et calculer la performance de chaque base de données. Cependant, je dois
00:04:16noter qu'il est un peu frustrant de voir qu'actuellement, l'installation du package ne fonctionne pas. Si nous lançons
00:04:22le test de benchmark maintenant, il se plaint d'une liaison native manquante. L'auteur du projet a
00:04:28clairement oublié d'ajouter les binaires ou de lier les bons au package. Ce que j'ai dû faire,
00:04:34c'est le compiler à partir des sources. J'ai cloné le dépôt, lancé la compilation à l'intérieur, puis je suis revenu
00:04:39à mon projet de benchmark et j'ai lié mon répertoire source comme dépendance. C'est un peu
00:04:44agaçant pour le moment, j'espère donc que les auteurs corrigeront cela à l'avenir. Mais
00:04:49quoi qu'il en soit, après avoir fait cela, nous pouvons enfin lancer le benchmark. Allons-y.
00:04:54Comme vous pouvez le voir, l'opération “count distinct” est effectivement beaucoup plus rapide sur Stulab, bien que
00:05:01pas autant qu'annoncé. C'est seulement quatre fois plus rapide. Et si on ajoutait un zéro au nombre
00:05:07de données à générer pour relancer le test avec 1 000 000 de lignes ? Essayons cela maintenant.
00:05:12Même pour un million de lignes, Stulab n'est que six fois plus rapide, pas 138 fois. Mais malgré tout,
00:05:20c'est un excellent résultat. Voilà pour le test du “count distinct”. J'ai décidé de faire un autre benchmark
00:05:26pour tester l'opération “distinct + order by”. Pour ce second test, j'ai mis en place une ingestion
00:05:33de logs aléatoires avec différentes adresses IP et codes d'état, puis j'ai cherché les logs distincts
00:05:39par paire adresse IP et code d'état, avant de les trier par IP croissante et code d'état
00:05:47décroissant. Et comme vous pouvez le voir, une fois le test lancé, Stulab est toujours plus performant que SQLite,
00:05:53mais pas de 14 fois, seulement 1 à 1,5 fois plus rapide. Les mesures annoncées sont donc un peu
00:06:01gonflées, à mon avis. Néanmoins, Stulab est bel et bien plus rapide que SQLite, comme nous venons de le voir.
00:06:08Pour être juste, l'auteur mentionne aussi des domaines où SQLite reste plus performant que Stulab.
00:06:13Il s'agit principalement de situations impliquant des opérations sur une seule ligne. Stulab est idéal pour
00:06:19les requêtes analytiques et complexes. Alors, Stulab est-il le tueur de SQLite ? Honnêtement, non. Ils sont faits
00:06:26pour des choses totalement différentes. SQLite reste votre outil fiable au quotidien pour les transactions,
00:06:32mais Stulab pourrait être votre voiture de course haute performance pour l'analyse de données. Mais le fait
00:06:38d'avoir maintenant un moteur analytique pur Rust que l'on peut intégrer dans un projet Node.js avec NAPI-RS
00:06:45est une excellente chose. Les propriétaires du projet doivent juste s'assurer de corriger leur package NPM
00:06:50pour qu'on n'ait pas à le compiler soi-même. Voilà, vous savez tout sur Stulab en quelques mots.
00:06:55Mais qu'en pensez-vous ? Le gain de performance vaut-il le passage à Stulab, ou préférez-vous rester
00:07:01sur la fiabilité de SQLite ? Dites-le-nous dans les commentaires. Et les amis, si vous avez trouvé cette
00:07:06vidéo utile, n'hésitez pas à me le faire savoir en cliquant sur le bouton j'aime sous la vidéo. N'oubliez pas
00:07:11non plus de vous abonner à notre chaîne. C'était Andris de Better Stack, et je vous dis à bientôt
00:07:17dans de prochaines vidéos.

Key Takeaway

Bien que les promesses de performance soient survendues, Stoolap s'impose comme une alternative analytique puissante à SQLite pour les environnements Node.js grâce à son architecture native en Rust.

Highlights

Présentation de Stoolap

Timeline

Introduction et limites de SQLite

L'auteur introduit SQLite comme le standard industriel incontournable pour lancer de nouveaux projets grâce à sa fiabilité et sa simplicité sans configuration. Cependant, il souligne que les limites techniques apparaissent rapidement lorsque les données s'alourdissent et que les requêtes deviennent complexes. Le moteur monothread et le système de verrouillage de fichiers de SQLite freinent alors les performances globales de l'application. C'est dans ce contexte qu'intervient Stoolap, un nouvel acteur écrit en Rust promettant des gains de vitesse allant jusqu'à 138 fois. Cette section pose le décor d'une confrontation entre la tradition et une nouvelle technologie de pointe.

Architecture technique : OLAP vs OLTP

Cette séquence explique la différence fondamentale entre Stoolap, une base de données OLAP (analytique), et SQLite ou Postgres, qui sont des bases OLTP (transactionnelles). Stoolap est comparé à DuckDB ou BigQuery pour sa puissance brute tout en conservant la portabilité d'un simple fichier local. L'innovation majeure réside dans son driver natif Node.js utilisant NAPI-RS, qui élimine le besoin de convertir les données en JSON ou de passer par un socket réseau. En partageant le même espace mémoire que le processus Node.js, le moteur évite le surcoût de sérialisation qui paralyse habituellement les performances. Cette intégration profonde permet une communication quasi instantanée entre le langage de haut niveau et le moteur système.

Les trois piliers de la vitesse de Stoolap

L'analyste détaille les trois raisons techniques rendant Stoolap particulièrement performant par rapport à ses concurrents. Premièrement, le MVCC permet à plusieurs lecteurs et scripteurs de travailler simultanément sans se bloquer mutuellement. Deuxièmement, l'utilisation de l'ordonnanceur Rayon permet de fragmenter une seule requête massive sur tous les cœurs CPU disponibles de la machine. Enfin, un optimisateur intelligent analyse les données pour choisir le chemin d'exécution le moins coûteux au lieu d'exécuter le SQL de manière aveugle. Ces mécanismes transforment radicalement la gestion des charges de travail analytiques lourdes. L'objectif est de démontrer que la performance n'est pas fortuite mais le résultat d'une ingénierie logicielle rigoureuse.

Benchmark : Count Distinct et difficultés d'installation

L'auteur passe à la pratique en configurant un test de benchmark comparatif sur une table de ventes remplie de données aléatoires. Il mentionne une frustration technique importante : le package NPM actuel est défectueux et nécessite une compilation manuelle depuis les sources pour fonctionner. Une fois cet obstacle franchi, le test sur l'opération "count distinct" montre que Stoolap est effectivement plus rapide que SQLite. Cependant, les résultats réels affichent un facteur de 4 à 6 fois supérieur sur un million de lignes, contredisant le chiffre marketing de 138 fois. Ce test souligne l'importance de vérifier les affirmations de performance par des tests en conditions réelles.

Second test et conclusion : Quel outil choisir ?

Un second benchmark portant sur des opérations de tri et de filtrage de logs confirme que Stoolap maintient son avance, bien que de manière moins spectaculaire avec un gain de 1 à 1,5 fois. L'auteur conclut que Stoolap ne tuera pas SQLite car les deux outils répondent à des besoins diamétralement opposés. SQLite reste imbattable pour les petites transactions unitaires fiables, alors que Stoolap est une véritable "voiture de course" pour l'analyse de données complexes. Il encourage les développeurs à surveiller ce projet tout en espérant une correction rapide du système de distribution des binaires. La vidéo se termine sur un appel à l'interaction pour savoir si les gains de performance justifient la complexité actuelle d'installation.

Community Posts

View all posts