Postgres in Rust bauen — ein Ansatz mit LLVM für Datenbanken

 (turso.tech)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Turso erweitert seinen Rust-basierten Datenbank-Core, indem es ein Postgres-kompatibles Frontend anschließt – hin zu einer LLVM-für-Datenbanken-Architektur, in der eine einzige Ausführungs-Engine mehrere Datenbanksprachen verarbeitet
  • Postgres-SQL wird in einen gemeinsamen AST geparst und zu VDBE-Bytecode kompiliert; das als Machbarkeitsnachweis dienende pgmicro wurde in den Haupt-Codebaum gemergt und dient nun als offizielle Entwicklungsbasis
  • Der bestehende Core unterstützt SQLite-Dateikompatibilität, gleichzeitige Schreibvorgänge per MVCC, asynchrone Ausführung, ein reiches Typsystem und automatisch aktualisierte materialisierte Views; die Zuverlässigkeit wird mit mehreren Testmethoden validiert
  • Das System ist so konzipiert, dass es in Browsern, auf Mobilgeräten und auf diversen Geräten eingebettet oder als einzelne Datei läuft, während bestehende Anwendungen, ORMs und psql über das Postgres-Wire-Protokoll darauf zugreifen können
  • Der Fokus liegt nicht auf 100%iger Übereinstimmung, sondern auf häufig genutzten Kernfunktionen, damit die meisten bestehenden Anwendungen unverändert laufen; für Extensions und PL/pgSQL werden WASM und Kompatibilitätsschichten geprüft, entwickelt wird unter MIT-Lizenz

Warum Postgres auf Turso gebaut wird

  • Turso ist ein moderner, in Rust geschriebener Datenbank-Core; darauf wird eine Postgres-kompatible Datenbank von Grund auf aufgebaut
  • Das langfristige Ziel ist nicht, das bestehende Postgres einfach nach Rust zu portieren, sondern eine neue Datenbank mit moderner Architektur zu schaffen
    • Es wird nicht für jede Verbindung ein separater Prozess verwendet
    • Sie kann eingebettet im Browser laufen
    • Eine Datenbank kann als einzelne Datei gehandhabt werden
    • Materialisierte Views werden ohne zusätzliche Arbeit automatisch aktualisiert
  • Angestrebt wird eine austauschbare Compiler-Architektur, bei der mehrere Frontends an einen stabilen Core angeschlossen werden
    • SQLite ist das erste Frontend
    • Postgres ist das nächste offizielle Frontend
    • Künftig können auch Frontends wie MySQL, Redis oder experimentelle Datenbanken ergänzt werden
  • Das aktuelle Ergebnis ist kein fertiges Produkt, sondern eine tatsächlich ausführbare Entwicklungsbasis

Von der SQLite-Neuimplementierung zum gemeinsamen Datenbank-Core

  • Turso war ursprünglich ein Projekt zur vollständigen Neuimplementierung von SQLite in Rust und mit moderner Architektur; dabei bleibt die Dateikompatibilität erhalten, sodass SQLite-Dateien geöffnet und erstellt werden können
  • Es verfügt bereits über Funktionen, die über den Umfang von SQLite hinausgehen
    • Wie Postgres unterstützt es gleichzeitige Schreibvorgänge per MVCC
    • Es bietet ein reiches Typsystem ähnlich wie Postgres
    • Es arbeitet vollständig asynchron und eignet sich dadurch für die native Ausführung auch in eingeschränkten Umgebungen wie Browsern
    • Materialisierte Views werden in Echtzeit automatisch aktualisiert, sodass keine Cronjobs für REFRESH MATERIALIZED VIEW oder Trigger-Kombinationen nötig sind
  • Auch mit dem zusätzlichen Postgres-Frontend ändern sich die Ziele von Turso und SQLite nicht
    • Vollständige SQLite-Kompatibilität und Funktionserweiterungen für künftige Workloads werden weiter verfolgt
    • Bei der Implementierung benötigter Funktionen können auch Postgres-Tests genutzt werden, was die Entwicklung beschleunigen kann

Zuverlässigkeit und offenes Beitragsmodell

  • Um die Robustheit von SQLite nachzubilden, wird Zuverlässigkeit als Produktfunktion behandelt
    • Es werden deterministische Simulationstests verwendet
    • Es werden Tests mit Antithesis durchgeführt
    • Oracle-Tests, Fuzzing und formale Methoden kommen ebenfalls zum Einsatz
  • Turso hat derzeit mehr als 260 Mitwirkende und betreibt ein Modell der Open Contribution, bei dem auch Externe an der Projektausrichtung mitwirken können
  • Angestrebt wird eine Linux-Kernel-artige Umgebung, in der Code und hohe Qualitätsstandards im Zentrum stehen und kontinuierlich aktive Beitragende auch an Projektentscheidungen teilnehmen
  • Auch von KI geschriebene Beiträge werden akzeptiert, müssen aber ausreichende Qualität haben; Menschen müssen den Code sorgfältig prüfen und die Architektur verstehen

Die VDBE-VM im Inneren von SQLite

  • SQLite ist keine Einzelschicht, die SQL direkt ausführt, sondern besitzt eine VM-Architektur, in der SQL im SQLite-Dialekt zu VDBE-Bytecode kompiliert und ausgeführt wird
  • VDBE ist kein universeller Bytecode wie JVM, .NET oder WASM, sondern bietet datenbankspezifische High-Level-Operationen wie Eintrag in einem B-Tree finden
  • Für diese Bytecode-Sprache gibt es keine öffentliche Spezifikation oder modulare Schnittstelle, sie existiert aber tatsächlich im Inneren von SQLite; Turso übernimmt dasselbe Design
  • Um die Allgemeinheit von Turso VDBE zu validieren, wurde Doom mit einem kleinen C-to-VDBE-Compiler übersetzt
    • Die echte Turso-Engine wurde nach WASM kompiliert und führt den VDBE-Bytecode von Doom in einem Browser-Tab aus
    • Doom wird auf dieselbe Weise ausgeführt, wie die Datenbank ein SELECT verarbeitet
    • Jeder Frame wird als eine Ergebniszeile behandelt
    • Speicherbereiche werden als les- und schreibbare Blobs dargestellt
    • Die Implementierung ist im Repository turso-vdbe-doom-example zu sehen

Compiler-Architektur des Postgres-Frontends

  • Frühere Versuche, SQLite und Postgres zu kombinieren, stützten sich wegen der monolithischen Struktur von SQLite hauptsächlich auf Übersetzung auf Query-Ebene, also darauf, Postgres-Queries in SQLite-Queries umzuwandeln; wegen der Unterschiede im äußeren Verhalten der beiden Datenbanken war das Impedance Mismatch groß
  • Intern führen die meisten SQL-Datenbanken ähnliche Grundoperationen rund um B-Trees und Indexmengen aus
  • Zwischen den Speicherstrukturen von Postgres und SQLite gibt es klare Unterschiede
    • Postgres legt Zeilen in Heap-Dateien ab und verwendet separate B-Tree-Indizes, Tupelversionen, TIDs und Vacuum
    • SQLite clustert Daten in B-Trees
  • Diese Unterschiede entstehen vor allem daraus, wie Bytes auf der Festplatte angeordnet werden; die für Postgres benötigten Operationen lassen sich mit dem bestehenden VDBE darstellen oder durch Erweiterung der VDBE-Befehle unterstützen
  • In der neuen Struktur kann das Datenbank-Frontend ausgetauscht werden
    1. Die Postgres-Sprache wird in einen gemeinsamen AST geparst
    2. Der AST wird zu Turso-Bytecode kompiliert
    3. Der gemeinsame Turso-Core führt den Bytecode aus
  • Das erste Experiment zur Machbarkeitsprüfung wurde mit pgmicro durchgeführt; die Ergebnisse wurden in den Turso-Haupt-Codebaum gemergt und in ein offizielles Projekt überführt

Ausführungsformen und Nutzungsszenarien

  • Ziel ist, dasselbe Postgres-SQL und dasselbe Datenbankverhalten in mehreren Formen ohne Server bereitzustellen
    • Eine echte Postgres-kompatible Datenbank läuft in einem Browser-Tab
    • Ein Agent erstellt für jeden Nutzer eine neue Datenbank und verwaltet jede davon als einzelne Datei
    • Local-first-Anwendungen laden Postgres-Daten als einzelne Datei herunter und synchronisieren sie anschließend wieder
    • Auf Mobiltelefonen und verschiedensten Geräten läuft sie eingebettet wie SQLite
  • Auch die Funktion, bestehende Turso-Datenbanken in lokale Dateien zu synchronisieren, soll in Turso/Postgres unterstützt werden
  • Neben Einzeldatei- und eingebetteter Ausführung gehören auch Wire-Protokoll und Server-Implementierung dazu, sodass bestehende Anwendungen, ORMs und psql eine Verbindung herstellen können
  • Die offiziellen Frontends, die das Turso-Team in naher Zukunft selbst entwickeln wird, sind SQLite und Postgres; die Struktur wird geöffnet, damit externe Beitragende andere Frontends bauen können

Aktuelle Ausführung und Mitmachen

  • Es gibt noch kein veröffentlichtes Paket, aber es lässt sich direkt aus dem Quellcode bauen und ausführen 
    cd postgres/cli && cargo run
  • Das Postgres-Frontend ist kein separates Repository, sondern wird von Tag eins an als offizielles Frontend im Turso-Codebaum entwickelt
  • Entwicklung und Beiträge erfolgen im Turso-GitHub-Repository

Ziele und Grenzen der Kompatibilität

  • Aufgrund der im Vergleich zu SQLite deutlich höheren Komplexität von Postgres ist 100%ige Kompatibilität kein zwingendes Ziel
  • Der Fokus liegt darauf, Kernfunktionen und breit genutzte Funktionen ausreichend zu unterstützen, damit die meisten Nutzer ihre Anwendungen ohne Änderungen ausführen können
  • Wenn moderne Funktionen und perfekte 1:1-Kompatibilität in Konflikt geraten, wird je Funktion entschieden
    • Tursos materialisierte Views werden in Echtzeit automatisch aktualisiert
    • Es ist noch nicht entschieden, ob zusätzlich der alte, nicht automatisch aktualisierte Ansatz nur für vollständige Kompatibilität implementiert wird
  • Je größer der Funktionsumfang wird, desto eher kann Turso/Postgres zu einer eigenständigen Datenbank statt zu einem Postgres-Klon werden

KI-Einsatz und Entwicklungsgeschwindigkeit

  • KI-Tools werden aktiv genutzt, ohne dabei Code-Review und Architekturverständnis auszulassen
  • Bei so kritischen Komponenten wie Datenbanken ist man der Ansicht, dass KI-Tools noch nicht das Niveau erreicht haben, die Verantwortung für Validierung zu ersetzen
  • Im Vergleich zu einem 24-Stunden-Betrieb von Fable mag die Geschwindigkeit pro Commit niedriger sein, dafür beginnt man mit einem bereits funktionierenden und umfassend getesteten Datenbank-Core
  • Statt sich schnell zu verändern und dabei das System zu beschädigen, wird ein Ansatz gewählt, der langsamer, aber korrekt implementiert
  • Um alle Funktionen fertigzustellen, wird Zeit benötigt; manche Funktionen müssen einen langen Entwicklungsprozess durchlaufen, bis die passende Architektur steht

PL/pgSQL und Extensions

  • PL/pgSQL ist keine unmöglich zu implementierende Komponente, sondern eine prozedurale Sprache; statt sie unverändert neu zu implementieren, ist es wahrscheinlicher, eine separate prozedurale Sprache und eine Kompatibilitätsschicht bereitzustellen
  • Es gibt einen Proof of Concept, einige Postgres-Extensions in einem WASM-Container zu laden
    • Extensions, die nur die vom WASM-Container bereitgestellten Symbole verwenden, können beliebig geladen werden
    • Durch die WASM-Ausführung entstehen Performance-Einbußen
    • Der Ansatz ist noch nicht als endgültiges Design festgelegt
  • Ein Extension-System, das beliebigen Code ohne Einschränkungen ausführen lässt, wird als nicht wünschenswert angesehen
  • Einige Extensions könnten nicht unterstützt werden, aber man geht davon aus, dass viele Extensions geladen werden können, wenn sie nach WASM kompiliert werden

Erwarteter Zeitplan und Open-Source-Strategie

  • Statt eine neue Datenbank von Grund auf zu bauen, beginnt man mit einem Core, der bereits funktioniert, getestet ist und große Teile der internen Struktur mit Postgres teilt
  • Die Umsetzung aller Postgres-Funktionen kann lange dauern, aber ein für die Praxis nützliches, ausreichend großes Funktions-Subset könnte innerhalb weniger Monate bereitstehen
  • Die beiden Kernentwickler sind derzeit etwa 44 Jahre alt und können noch mindestens 20 Jahre entwickeln, daher besteht kein Druck, den vollständigen Funktionsumfang überstürzt fertigzustellen
  • Die tatsächliche Entwicklungsgeschwindigkeit und der Umfang hängen stark von Community-Beiträgen ab
    • Als damals Mehrprozess-Unterstützung für den SQLite-Dialekt entstand, hatte das Team keine Windows-Geräte und ließ die Windows-Implementierung daher aus
    • Ein externer Entwickler, der Turso intensiv nutzte, interessierte sich dafür und stellte die Windows-Unterstützung innerhalb einer Woche fertig
  • Experimentelle Frontends können außerhalb des Codebaums entwickelt werden, aber für das offizielle Postgres-Frontend gilt dieselbe MIT-Lizenz wie für das bestehende Turso

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Kommentare auf Lobste.rs

  • Ich glaube, fast alle SQL-Datenbanken kompilieren Abfragen für eine virtuelle Maschine (VM).
    In dieser Hinsicht wirkt es etwas seltsam, SQLite als Sonderfall herauszustellen.

    • Die meisten Datenbanken erstellen einen Baum relationaler Operatoren und geben jedem Operator ein Push- oder Pull-Interface.
      SQLite hingegen kompiliert Abfragen zu imperativem Bytecode mit Variablen und Schleifen.

  • Als pgwire-Entwickler freut es mich, dass Turso pgwire für eine PostgreSQL-kompatible Datenbank wiederverwendet.

  • Ich frage mich, warum das Unternehmen zu dem Schluss kam, dass eine Richtungsänderung nötig ist.

  • Ich frage mich, ob sie die Neuimplementierung von SQLite abgeschlossen oder aufgegeben haben.
    https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next

  • Ein sehr interessanter Beitrag; es ist beschämend, dass er zu Unrecht gemeldet wurde.

    • Das ist eine Technologie mit großer Tragweite, die eines Tages die Spielregeln für mein Arbeitsprojekt verändern könnte.
      Sie ist keineswegs „off-topic“ oder „spam“, und ich verstehe überhaupt nicht, warum jemand sie so gemeldet hat.
      Vielleicht haben sie wegen eines einzelnen Gedankenstrichs im Text gleich auf KI-Müll geschlossen; jedenfalls fühlt es sich an, als würden die Leute wirklich den Verstand verlieren.
      Die Meldekultur auf dieser Seite ist schrecklich geworden; ich hoffe, die Betreiber unternehmen etwas dagegen. Wenn man ein paar Leute sperrt, die böswillig melden, halten sich die übrigen vielleicht auch zurück.
    • Inzwischen ist unberechtigtes Melden hier praktisch selbst Teil der Kultur geworden.

  • Schon früher habe ich Abneigung dagegen geäußert, dass Turso sich als Nachfolger von SQLite aufspielt, und deshalb habe ich mir vor ein paar Jahren vorgenommen, die Software gar nicht erst auszuprobieren.
    Wenn sie aber schnelle und günstige automatisch aktualisierte materialisierte Views auch außerhalb von SQL Server anbieten, werde ich sie am Ende vielleicht doch nutzen.