# 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:

```mermaid
flowchart LR
    W[Schreibzugriffe] --> DELTA[DELTA<br/>schreib-optimiert]
    R[Leseanalysen] --> MAIN[MAIN<br/>lese-optimiert, komprimiert]
    DELTA -- Delta-Merge periodisch --> MAIN
```

```
        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>