# paulDB πŸ¦€πŸ³οΈβ€πŸŒˆ > **Eine eigene HTAP-Datenbank in Rust.** > Row- *und* Column-Storage in einer Engine, mit einem Delta-Merge-Konzept, > inspiriert von SAP HANA. Ein Langzeitprojekt – gebaut, um zu *verstehen*, nicht nur zu benutzen. --- ## Was ist paulDB? paulDB ist mein Versuch, eine Datenbank von Grund auf selbst zu schreiben – in Rust. Nicht, weil die Welt noch eine Datenbank braucht, sondern weil ich wissen will, **warum** Datenbanken so funktionieren, wie sie funktionieren. Jede Zeile Code hier ist eine Antwort auf eine Frage, die ich mir sonst nur theoretisch beantworten kΓΆnnte: - Wie speichert eine Engine Daten wirklich auf Platte und im Speicher? - Wie wird aus `SELECT … WHERE …` ein ausgefΓΌhrter Plan? - Wie hΓ€lt man OLTP (schnelle Einzelzugriffe) und OLAP (große Aggregationen) in *einem* System gleichzeitig schnell – also **HTAP**? - Wie macht HANA das mit **Delta** und **Main** – und kann ich das nachbauen? paulDB ist mein β€žCrafting Interpreters", nur fΓΌr Datenbanken. --- ## Warum HTAP + Delta-Merge? Klassische Systeme zwingen zur Wahl: | | Optimiert fΓΌr | Speicherform | |---|---|---| | **OLTP** | viele kleine Schreib-/Lesezugriffe | Row-Store (Zeilen) | | **OLAP** | wenige große Aggregationen | Column-Store (Spalten) | **HTAP** (Hybrid Transactional/Analytical Processing) will beides in einem System. SAP HANA lΓΆst das elegant ΓΌber zwei Bereiche: ``` Schreibzugriffe Leseanalysen β”‚ β”‚ β–Ό β–Ό β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” Delta-Merge β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ DELTA β”‚ ───────────────▢ β”‚ MAIN β”‚ β”‚ (schreib- β”‚ (periodisch) β”‚ (lese- β”‚ β”‚ optimiert) β”‚ β”‚ optimiert, β”‚ β”‚ β”‚ β”‚ komprimiert) β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ ``` - **Delta**: schreib-optimiert, nimmt neue Daten schnell auf. - **Main**: lese-optimiert, stark komprimiert, ideal fΓΌr Analytik. - **Delta-Merge**: schiebt periodisch Delta β†’ Main, hΓ€lt Lesezugriffe schnell. Genau dieses Prinzip ist das HerzstΓΌck von paulDB. --- ## Architektur-Vision ``` β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ SQL-Frontend β”‚ β”‚ Parser β†’ AST β†’ Planner β†’ Optimizer β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ Execution Engine β”‚ β”‚ (vektorisiert, wo es geht) β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ Row-Store β”‚ Column-Store β”‚ β”‚ (OLTP / Delta) β”‚ (OLAP / Main) β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ Transaktionen: MVCC + WAL β”‚ Delta-Merge-Worker β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ Storage Layer (Pages, B-Tree) β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ ``` --- ## Roadmap Etappenweise – jede Stufe ist fΓΌr sich ein vollstΓ€ndiges Lernziel. *(Reihenfolge ist Plan, kein Versprechen an einen Zeitpunkt.)* - [ ] **Etappe 0 – Fundament**: Rust lernen, Projektstruktur, `cargo`, Tests - [ ] **Etappe 1 – Storage Engine**: Pages, ein einfacher B-Tree, Lesen/Schreiben auf Platte - [ ] **Etappe 2 – Row-Store + REPL**: Tabellen, Zeilen einfΓΌgen/lesen, kleine SQL-Teilmenge - [ ] **Etappe 3 – SQL-Parser**: Tokenizer β†’ AST β†’ einfacher Planner - [ ] **Etappe 4 – Transaktionen**: WAL (Write-Ahead-Log), Crash-Recovery, ACID-Grundlagen - [ ] **Etappe 5 – MVCC**: Multi-Version-Concurrency, mehrere Leser/Schreiber - [ ] **Etappe 6 – Column-Store**: spaltige Speicherung, Kompression, vektorisierte Aggregation - [ ] **Etappe 7 – Delta-Merge**: Delta + Main, periodischer Merge-Worker – das HTAP-Herz ❀️ - [ ] **Etappe 8 – Optimizer**: Statistiken, Histogramme, kostenbasierte Planwahl --- ## Prinzipien - **Verstehen vor Benutzen.** Jedes Modul kommentiert das *Warum*, nicht nur das *Was*. - **Klein, aber echt.** Lieber eine simple Engine, die wirklich lΓ€uft, als ein leeres Framework. - **Analogien nutzen.** paulDB ↔ Postgres ↔ HANA ↔ DuckDB – Vergleiche machen Konzepte greifbar. - **Ehrlich zum Stand.** Was lΓ€uft, lΓ€uft. Was noch nicht da ist, steht offen in der Roadmap. --- ## Lernressourcen Die Schultern, auf denen paulDB steht: - πŸ“˜ **Database Internals** – Alex Petrov *(Storage Engines, B-Trees, verteilte Systeme)* - πŸ“— **Crafting Interpreters** – Robert Nystrom *(Parser, AST, Interpreter – fΓΌrs SQL-Frontend)* - πŸ’» **[cstack/db_tutorial](https://cstack.github.io/db_tutorial/)** *(eine simple DB Schritt fΓΌr Schritt in C)* - πŸ—ƒοΈ **SQLite Source Code** *(das Vorbild fΓΌr β€žklein, robust, vollstΓ€ndig")* - πŸ¦€ **The Rust Programming Language** (β€žthe Book") + **Rust by Example** --- ## Status 🌱 **Vision-Phase.** paulDB ist aktuell ein Zuhause fΓΌr einen Traum, der bewusst wartet, bis mein SAP-Fundament steht. Das ist kein RΓΌckstand – das ist Reihenfolge. Ein leeres Repo mit klarem Plan ist kein Hochstapeln. Es ist ein Versprechen an mich selbst. --- von Paul Horn Β· gebaut, um zu verstehen Β· auf dem Weg nach BC πŸ”οΈ