OLTP-jádro: API a adaptive tuning v SRD

Implementace OLTP jádra: API smlouvy, velikost stránky a adaptivní ladění

Specialisté na vývoj nové OLTP SÚBD implementovali striktní architekturu s izolovanými vrstvami prostřednictvím trait rozhraní v Rustu. Každá vrstva má jasné API smlouvy, velikost stránky se nastavuje pro jednotlivé tabulkové prostory, konfigurace je řízena Resource Brokerem bez manuálního ladění. Diagnostika je integrována přes USDT a eBPF.

Nastavení velikosti stránky a tabulkových prostorů

Velikost datové stránky se pohybuje od 4–8 KB pro čistý OLTP až po 16–32 KB pro HTAP na NVMe. Každý tabulkový prostor je samostatný soubor s neměnnou velikostí stránky po vytvoření. Výchozí hodnota je 16 KB. PageId je složený: [tablespace_id:16][page_index:48]. BufferPool směruje požadavky do podúložišť podle velikosti.

Superblok na začátku souboru uchovává metadata tabulkového prostoru nezávisle na velikosti stránky. Při montování se kontroluje konfigurace; nesoulad vede k zamítnutí spuštění bez degradace.

Architektonické vrstvy a API smlouvy

Jádro je rozděleno do čtyř vrstev:

• Adapter Layer (async tokio): ukončuje TLS, parsuje wire-protokol.

#[async_trait]
pub trait NetworkAdapter {
    async fn handle_connection(&self, stream: Box<dyn ConnectionStream>) -> Result<(), NetworkError>;
}

• CompatLayer: parsuje SQL do AST, emuluje pg_catalog, převádí do LogicalPlan, odfiltrovává nepodporované funkce (chyba 0A000).

pub trait CompatLayer {
    fn translate_query(&self, ast: SqlAst) -> Result<LogicalPlan, CompatError>;
}

• Core Engine (sync): optimalizátor, vykonávač, manažer transakcí. Spouští se v poolu spawn_blocking.

pub trait ExecutionEngine {
    fn execute_plan(&self, plan: LogicalPlan, session: &Session) -> Result<ResultSet, ExecutionError>;
}

• StorageManager: fasáda nad PageProvider a TransactionLogSink. Jádro žádá stránky a UNDO záznamy.

pub trait StorageManager {
    fn pin_page(&self, page_id: PageId, mode: LockMode) -> Result<PageGuard, StorageError>;
    fn append_undo(&self, txn_id: TxnId, record: UndoRecord) -> Result<UndoPtr, StorageError>;
}

Hranice vrstev vylučují únik detailů: metriky zámků nezahrnují async čekání.

Adaptivní ladění a Resource Broker

Přibližně 60 parametrů je rozděleno do rozpočtů, zábran a přepsání. Operátor zadává vysokou úroveň limitů:

[resources]
memory_budget = "16GB"
cpu_budget    = "auto"
io_iops       = 5000

Poradci (MemoryAdvisor, IoAdvisor, CpuAdvisor) přerozdělují zdroje každou sekundu:

• CpuAdvisor: DOP a pool vláken proti throttlingu.
• MemoryAdvisor: BufferPool vs work_mem pod zátěží.
• IoAdvisor: priorita transakcím, burst awareness v cloudu.

Ochranné mechanismy

• Hystereze: okno 5 s, kroky 5 % proti oscilacím.
• Hard Floors: min. 128 MB pro BufferPool/UNDO.
• Graceful Transition: nové limity pro nové alokace.
• Expert overrides překrývají autoladění.

Pozadí purge UNDO logu místo VACUUM. Změny za běhu bez restartu.

Diagnostika: USDT sondy a eBPF

Mechanizmy diagnostiky jsou vestavěny do binárníku. USDT sondy pro runtime analýzu, eBPF pro tracing bez overheadu.

Co je důležité:

• Velikost stránky pro tabulkové prostory s ochranou při startu.
• Striktní trait smlouvy mezi vrstvami vylučují úniky.
• Resource Broker: rozpočty → autoladění se zábranami.
• Diagnostika přes eBPF/USDT v jádru.
• Odmítnutí manuálního ladění ve prospěch adaptivních mechanismů.

— Editorial Team