SQLite ist 138x langsamer als DAS?! (Stoolap im Test)

BBetter Stack
컴퓨터/소프트웨어AI/미래기술

Transcript

00:00:00Wenn du ein neues Projekt startest und eine Datenbank brauchst, was ist die erste Option,
00:00:03die dir einfällt? SQLite? Wahrscheinlich SQLite, oder? Ich meine, es ist super, zuverlässig,
00:00:09konfigurationsfrei und ein Industriestandard. Aber wenn unsere lokalen Daten umfangreicher
00:00:14und die Abfragen komplexer werden, stoßen wir allmählich an die Grenzen dessen, was eine
00:00:20Single-Threaded-Engine mit Dateisperren leisten kann. Doch nun gibt es einen neuen Player,
00:00:25der diese Probleme lösen will: Stulab. Eine komplett in Rust geschriebene Datenbank-Engine,
00:00:31die gerade einen nativen Node.js-Treiber veröffentlicht hat, der eine wirklich starke Performance zeigt.
00:00:36Die Datenbank soll 138-mal schneller als SQLite sein. In diesem Video schauen wir uns also
00:00:43Stulab genauer an, prüfen die Funktionsweise und machen einen Live-Benchmark-Test, um zu sehen,
00:00:50ob es wirklich so leistungsstark ist, wie behauptet. Das wird spannend, also legen wir los. Was ist Stulab?
00:01:00Im Kern ist Stulab eine eingebettete OLAP-Datenbank (Online Analytical Processing).
00:01:06Standard-Datenbanken wie SQLite oder Postgres sind typischerweise OLTP-Datenbanken
00:01:14(Online Transaction Processing), die – wie der Name sagt – für Transaktionen optimiert sind.
00:01:20Stulab ist anders. Es ist für analytische Workloads konzipiert, von Grund auf in Rust gebaut
00:01:27und auf Hochgeschwindigkeits-Datenverarbeitung fokussiert. Es bietet die Portabilität
00:01:33einer SQLite-Datei, kombiniert mit der analytischen Power von DuckDB oder BigQuery.
00:01:39Das Beste ist, dass man es dank des nativen Node-Treibers jetzt mit Node.js nutzen kann.
00:01:45Wenn ich von einem nativen Treiber spreche, meine ich keinen Standard-Wrapper.
00:01:49Normalerweise muss eine Node.js-App mit Datenbanken in Sprachen wie Rust oder C++ über eine Bridge kommunizieren.
00:01:56Oft müssen Daten in JSON konvertiert, über einen lokalen Socket gesendet und dann
00:02:02wieder zurückkonvertiert werden. Das nennt man Serialisierungs-Overhead – ein echter Performance-Killer.
00:02:08Stulab Node macht das anders. Es nutzt NAPI-RS, ein Framework, mit dem die
00:02:15Rust-Engine in ein natives Binary kompiliert wird, das direkt in den Node.js-Prozess geladen wird.
00:02:21Es gibt also keine Bridge und keinen Übersetzer dazwischen. Bei einer Abfrage teilen
00:02:27sich Node.js und Rust quasi denselben Speicherbereich. Es gibt drei Gründe für den Speed:
00:02:33Erstens nutzt es MVCC (Multi-Version Concurrency Control). Anders als bei SQLite,
00:02:40wo ein einzelner Schreibvorgang die ganze Datenbank sperren kann, erlaubt Stulab
00:02:47simultane Lese- und Schreibzugriffe. Zweitens nutzt es parallele Ausführung.
00:02:53Stulab nutzt den Scheduler “Rayon”. Bei massiven Abfragen wird die Last nicht auf nur
00:03:00einem CPU-Kern verarbeitet, sondern auf alle verfügbaren Kerne deiner Maschine aufgeteilt.
00:03:06Drittens nutzt es einen kostenbasierten Optimizer. Es führt SQL nicht einfach blind aus,
00:03:13sondern analysiert die Daten, schätzt die Kosten verschiedener Pfade und wählt den schnellsten Weg.
00:03:19Das soll Stulab viel schneller als SQLite machen. Aber testen wir mal, ob das wirklich stimmt.
00:03:25Für diesen Test nutzen wir ein einfaches Node.js-Projekt und installieren sowohl Stulab
00:03:30als auch SQLite als Abhängigkeiten. Ein Bereich, in dem Stulab glänzen soll, ist “Count Distinct”.
00:03:37Ich bin gespannt, ob das zutrifft. Ich habe ein Skript erstellt, das eine In-Memory-Version
00:03:43beider Datenbanken startet und eine einfache Verkaufstabelle anlegt. Wir füllen diese
00:03:49Tabelle mit 10.000 Zeilen Testdaten, wobei jede Zeile einen Verkauf eines Nutzers (ID 0-1000)
00:03:56in einer bestimmten Kategorie darstellt. Wir führen dann einen Batch-Insert in beide
00:04:03Datenbanken aus und messen die Performance beim Zählen der eindeutigen Verkäufe
00:04:10eines bestimmten Nutzers in einer Kategorie. Ich muss allerdings anmerken,
00:04:16dass die Paketinstallation aktuell frustrierenderweise nicht richtig funktioniert.
00:04:22Beim Ausführen des Benchmarks gab es Fehlermeldungen wegen fehlender nativer Bindings.
00:04:28Der Autor hat offenbar vergessen, die Binaries hinzuzufügen oder korrekt zu verlinken.
00:04:34Ich musste es also aus dem Quellcode selbst bauen: Repo klonen, Build ausführen,
00:04:39zurück zum Benchmark-Projekt und das Source-Verzeichnis als Abhängigkeit verknüpfen.
00:04:44Das ist momentan etwas mühsam, hoffentlich fixen die Autoren das bald.
00:04:49Aber nachdem das erledigt war, konnten wir den Benchmark endlich starten.
00:04:54Wie ihr seht, ist die “Count Distinct”-Operation in Stulab tatsächlich viel schneller,
00:05:01wenn auch nicht so extrem wie beworben. Es ist etwa viermal schneller. Was passiert,
00:05:07wenn wir eine Null dranhängen und den Test mit 1.000.000 Zeilen wiederholen?
00:05:12Selbst bei einer Million Zeilen ist Stulab nur sechsmal schneller, nicht 138-mal.
00:05:20Dennoch ist das ein tolles Ergebnis. Das war der “Count Distinct”-Test. Ich habe noch
00:05:26einen zweiten Benchmark für die Kombination aus “Distinct” und “Order By” gemacht.
00:05:33Hierfür habe ich zufällige Logs mit verschiedenen IP-Adressen und Statuscodes geladen.
00:05:39Ziel war es, eindeutige IP-Statuscode-Paare zu finden und diese nach IP aufsteigend
00:05:47und Statuscode absteigend zu sortieren. Wie man sieht, performt Stulab auch hier besser
00:05:53als SQLite, aber nicht um den Faktor 14, sondern nur etwa 1 bis 1,5-mal schneller.
00:06:01Die angegebenen Messwerte sind meiner Meinung nach etwas übertrieben, aber Stulab ist schneller.
00:06:08Fairerweise erwähnt der Autor auch Bereiche, in denen SQLite immer noch besser abschneidet.
00:06:13Das betrifft vor allem Operationen auf einzelnen Zeilen. Stulab ist für analytische,
00:06:19komplexe Abfragen gedacht. Ist Stulab also der SQLite-Killer? Ehrlich gesagt: Nein.
00:06:26Sie sind für völlig unterschiedliche Zwecke gebaut. SQLite bleibt dein zuverlässiger
00:06:32Daily Driver für Transaktionen, während Stulab der Rennwagen für die Datenanalyse ist.
00:06:38Aber dass wir jetzt eine reine Rust-Engine haben, die wir per NAPI-RS einfach in ein
00:06:45Node.js-Projekt einbinden können, ist großartig. Das NPM-Paket muss nur noch gefixt werden,
00:06:50damit wir nicht selbst kompilieren müssen. Das war Stulab im Schnelldurchlauf.
00:06:55Was denkt ihr darüber? Ist der Performance-Boost den Wechsel wert, oder bleibt ihr
00:07:01bei der Zuverlässigkeit von SQLite? Schreibt es uns in die Kommentare.
00:07:06Wenn euch das Video geholfen hat, zeigt es mir gerne mit einem Klick auf den Like-Button.
00:07:11Und vergesst nicht, den Kanal zu abonnieren. Ich bin Andris von Better Stack,
00:07:17wir sehen uns im nächsten Video!

Key Takeaway

Stoolap bietet als Rust-basierte OLAP-Datenbank signifikante Performance-Vorteile für analytische Abfragen in Node.js-Umgebungen, auch wenn die extremen Werbeversprechen in der Praxis moderater ausfallen.

Highlights

Stoolap (Stulab) ist eine neue

Timeline

Einführung in Stoolap und das SQLite-Limit

Der Sprecher thematisiert die weite Verbreitung von SQLite als Industriestandard für neue Projekte. Er erklärt, dass SQLite bei wachsenden Datenmengen und komplexen Abfragen aufgrund seiner Single-Threaded-Natur an Grenzen stößt. Als Lösung wird Stoolap vorgestellt, eine neue Datenbank-Engine, die komplett in der Programmiersprache Rust entwickelt wurde. Es wird ein leistungsstarker Node.js-Treiber erwähnt, der laut Marketing eine bis zu 138-mal höhere Geschwindigkeit verspricht. Dieses Video soll prüfen, ob diese ambitionierten Behauptungen in einem realen Benchmark-Test standhalten können.

OLAP vs. OLTP und die Architektur von Stoolap

In diesem Abschnitt wird der grundlegende Unterschied zwischen OLTP-Datenbanken wie SQLite oder Postgres und OLAP-Datenbanken wie Stoolap erläutert. Während Erstere für Transaktionen optimiert sind, fokussiert sich Stoolap auf analytische Hochgeschwindigkeits-Verarbeitung ähnlich wie DuckDB. Ein technisches Highlight ist die Integration in Node.js via NAPI-RS, wodurch die Datenbank direkt in den Prozess geladen wird. Dies eliminiert den typischen Serialisierungs-Overhead, der normalerweise bei der Kommunikation über JSON oder Sockets entsteht. Node.js und die Rust-Engine teilen sich hierbei effizient denselben Speicherbereich für maximale Performance.

Die drei Säulen der Performance

Der Sprecher analysiert drei spezifische Gründe, warum Stoolap technisch überlegen sein soll. Erstens nutzt die Engine MVCC, was simultane Lese- und Schreibzugriffe ohne die bei SQLite üblichen Datenbanksperren ermöglicht. Zweitens wird durch den Rayon-Scheduler eine echte parallele Ausführung erreicht, die alle verfügbaren CPU-Kerne für Abfragen nutzt. Drittens verfügt Stoolap über einen kostenbasierten Optimizer, der den effizientesten Ausführungspfad für SQL-Befehle berechnet. Diese Kombination aus moderner Speicherverwaltung und paralleler Rechenkraft bildet das Rückgrat für die versprochene Geschwindigkeit.

Benchmark-Setup und Installationshürden

Für den Praxistest wird ein Node.js-Projekt aufgesetzt, das Stoolap und SQLite in einer In-Memory-Konfiguration vergleicht. Der Test fokussiert sich auf eine Verkaufstabelle mit zunächst 10.000 Zeilen, um die Performance von "Count Distinct"-Operationen zu messen. Der Sprecher berichtet jedoch von erheblichen Schwierigkeiten bei der Installation des NPM-Pakets aufgrund fehlender nativer Bindings. Er musste die Software schließlich manuell aus dem Quellcode klonen und kompilieren, um den Test überhaupt durchführen zu können. Dieser Umstand verdeutlicht, dass sich das Projekt aktuell noch in einer frühen, potenziell instabilen Entwicklungsphase befindet.

Testergebnisse und Vergleich der Metriken

Die Benchmarks zeigen, dass Stoolap bei 10.000 Zeilen etwa viermal schneller ist als SQLite. Bei einer Erhöhung auf eine Million Zeilen steigt dieser Vorsprung auf das Sechsfache an, was jedoch weit hinter dem Faktor 138 zurückbleibt. Ein zweiter Test mit "Distinct" und "Order By" liefert nur noch eine minimale Steigerung von 1 bis 1,5-mal der SQLite-Geschwindigkeit. Der Sprecher merkt kritisch an, dass die offiziellen Marketing-Messwerte deutlich übertrieben wirken. Dennoch bleibt festzuhalten, dass Stoolap in seinen Kernkompetenzen, den analytischen Abfragen, messbar führt.

Fazit: Kein SQLite-Killer, aber ein Spezialist

Abschließend wird klargestellt, dass Stoolap kein direkter Ersatz für SQLite ist, da beide Systeme unterschiedliche Einsatzzwecke verfolgen. Während SQLite der zuverlässige Standard für alltägliche Transaktionen bleibt, glänzt Stoolap als spezialisierter "Rennwagen" für komplexe Datenanalysen. Die Integration von Rust in das Node.js-Ökosystem wird als großer Gewinn für die Entwickler-Community bewertet. Sobald die Probleme mit dem NPM-Paket behoben sind, bietet Stoolap eine spannende Alternative für datenintensive lokale Anwendungen. Der Sprecher verabschiedet sich mit einem Aufruf zur Diskussion über die Relevanz dieses Performance-Boosts.

Community Posts

View all posts