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!