Co znamená Restrictive by Default v OLTP DB?

Explicitní limity na zdroje s fail-closed: reject místo throttling pro jasné SQLSTATE a předvídatelnost.

Proč Rust místo C++ nebo Go?

Rust zajišťuje typovou bezpečnost, kontrolu alokací a nízkou tailovou latenci bez GC.

Jak je zajištěna pgwire kompatibilita?

Pomocí boundary vrstvy pro wire protokol, bez kopírování interních struktur PostgreSQL.

Návrh OLTP databáze v Rustu: principy

Článek popisuje principy návrhu OLTP databáze od nuly v Rustu: restrictive by default, contract-first prostřednictvím traits, hybridní asynchronita. Implementováno unified storage, MVCC, WAL. Fokus na předvídatelnost a spolehlivost pro production.

By Sudonull Editorial Team • Published 2026-04-14 • Updated 2026-04-14

Architektura OLTP databáze: od principů k implementaci v Rustu

Byly implementovány klíčové subsystémy OLTP enginu: unified storage v jediném souboru na databázi, disk-backed storage s UNDO-log MVCC, WAL a recovery podle ARIES, společný BufferPool, in-memory engine a pgwire-protokol kompatibilní s PostgreSQL. Kód funguje, ale vyžaduje zátěžové testy a stabilizaci okrajových případů. Nejde o finální produkt, ale o ranou fázi s pevně stanovenými kontrakty.

Základní principy návrhu

Projekt se opírá o přísná pravidla pro rozhodování. Každé nové rozhodnutí je musí dodržovat nebo musí odchylku odůvodnit.

Restriktivní jako výchozí nastavení

Komponenty mají explicitní limity s chováním fail-closed místo throttlingu. To zajišťuje předvídatelnost při zátěži.

|-----------|---------|------------------------|----------|

Fail-closed poskytuje jasné SQLSTATE pro opakování nebo circuit breaker v aplikaci.

Přístup Contract-First

Architektonické kontrakty jsou fixovány v Rustových traitech: TableEngine, PageProvider, TransactionLogSink, StorageIo. Tím se zabrání odchylkám v implementaci a kontrolují se invarianty ve fázi kompilace.

Volba Rustu

Rust byl zvolen pro předvídatelnou latenci, kontrolu alokací a typovou bezpečnost. Send/Sync na async/sync hranicích, explicitní chyby místo runtime problémů. C++ vyžaduje dodatečnou disciplínu, Go není vhodný kvůli GC pro tail latenci OLTP.

Rozdělení odpovědnosti

Databáze funguje jako data engine bez obchodní logiky: na začátku nejsou triggery, PL/pgSQL, uložené procedury. User-defined functions budou možné později s sandboxingem a bez vedlejších účinků.

Hybridní asynchronita

Síťová/pgwire vrstva: async (accept, TLS, send).
Jádro (query execution, storage, WAL, MVCC): sync pro korektnost a ladění.
Hranice je jednosměrná přes bridge.

StorageIo je abstrahováno pro budoucí async I/O bez přepisování transakcí.

| Vrstva | Runtime | Příklady |

|------|---------|---------|

| Network/Protocol | async | pgwire, TLS |

| Query Execution | sync | plán, provedení |

| Storage/WAL | sync (async I/O později) | HeapStore, BufferPool |

| MVCC/Transactions | sync | snapshot, zámky |

Kompatibilita s PostgreSQL

Pgwire zajišťuje integraci s ovladači a ORM bez migrace klienta. Kompatibilita na wire úrovni přes boundary vrstvu, bez kopírování interních struktur PostgreSQL (MVCC heap, VACUUM). Jádro si zachovává architektonickou svobodu.

Platformní omezení a spolehlivost

Pouze Linux pro zaměření na io_uring, eBPF bez multiplatformních kompromisů. Priority: absence poškození dat, bezpečný návrat optimalizací, odolnost vůči user input, vestavěná bezpečnost.

Co je důležité

Restriktivní jako výchozí nastavení s fail-closed pro předvídatelnost při zátěži.
Contract-First přes Rust traits pro kontrolu invariantů.
Hybridní async/sync: stabilita jádra před zrychlením I/O.
Pgwire kompatibilita bez kopírování interních struktur PostgreSQL.
Data engine bez obchodní logiky pro čistotu a testovatelnost.

— Editorial Team

Návrh OLTP databáze v Rustu: principy

Architektura OLTP databáze: od principů k implementaci v Rustu