126 lines
6.0 KiB
Markdown
126 lines
6.0 KiB
Markdown
# 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.
|
||
|
||
---
|
||
|
||
<sub>von Paul Horn · gebaut, um zu verstehen · auf dem Weg nach BC 🏔️</sub> |