Více databází v systému

Účel a kontext: proč integrovat více databází v jednom systému

Moderní systémy často vyžadují kombinaci relačních, dokumentových, časosběrných, grafových či vyhledávacích databází. Důvody jsou výkonnostní (optimalizace pro různé dotazovací vzory), funkční (fulltext, geodata, analytika) i provozní (oddělení domén, právní a regionální požadavky). Integrace více databází v jedné aplikační platformě – polyglot persistence – přináší benefity, ale i náročnost v oblasti konzistence, transakcí, modelování dat, observability, governance a bezpečnosti.

Integrační paradigmata a architektonické vzory

• Transakční integrace: aplikační logika zapisuje napříč úložišti v rámci jedné obchodní operace (typicky bez distribuovaných transakcí, viz Sagy).
• Asynchronní integrace: změny v jedné DB se šíří do jiných přes události (CDC, outbox) a tvoří materiálované pohledy.
• Virtuální integrace: vrstva dotazování (federace SQL/GraphQL) agreguje data za běhu bez fyzické replikace.
• ETL/ELT: periodické dávky do datového skladu/data lake pro analytické scénáře.

Volba strategií podle use-casu

Modelování dat napříč úložišti

• Doménové oddělení: každá doména má “primární” úložiště (system of record) a ostatní jsou konzumenti projekcí.
• Identifikátory: stabilní globální ID (ULID/UUIDv7) pro korelaci; vyhýbat se složeným ID závislým na konkrétní DB.
• Referenční integrita: mimo jednu DB neexistuje – vynucujte ji aplikačně (složky workflow, kompenzace).
• Schéma a kontrakty: spravujte přes schema registry (JSON Schema, Protobuf), verzování s backward kompatibilitou.

Konzistence: silná, eventual a „read-committed reality“

• Silná konzistence napříč DB je drahá (latence, dostupnost). Použijte jen tam, kde je nutná (např. zůstatky).
• Eventual consistency pro většinu projekcí; komunikujte uživateli zpoždění a stav synchronizace.
• Read-your-writes lokálně zajistíte přesměrováním čtení na primární zápisové úložiště nebo cache s potvrzením.

Distribuované transakce: 2PC vs. Sagy vs. TCC

• 2PC (two-phase commit): jednoduchý mentální model, ale vysoké náklady, coordinator jako SPOF, omezená podpora napříč DB.
• Saga pattern: obchodní proces jako série lokálních transakcí s kompenzačními kroky; orchestrace (centrální) vs. choreografie (event-driven).
• TCC (Try-Confirm/Cancel): rezervace zdrojů, poté potvrzení; vhodné pro platební a rezervací systémy.

Outbox, CDC a přesuny dat

• Transactional outbox: zapisujte události do outbox tabulky ve stejné transakci jako business změnu; spolehlivý export (poller/stream).
• Change Data Capture (CDC): čtení binárních logů (např. Debezium) a proud změn do dalších úložišť (indexy, cache, graf, DWH).
• Idempotence: události s klíčem eventId, deduplikace na cíli, exactly-once je spíše procesní než technická vlastnost.

CQRS a materiálované pohledy

Oddělení zápisové (command) a čtecí (query) strany umožňuje optimalizovat data pro konkrétní dotazy. Čtecí modely (např. dokumentové, vyhledávací indexy, agregace) se aktualizují asynchronně z událostí.

Vrstva přístupu k datům a API federace

• Data Access Layer (DAL): jasné hranice per doména, anti-korupční vrstvy pro konkrétní DB ovladače.
• Federace GraphQL: sjednocení více zdrojů pod jedním schématem; pozor na N+1 dotazy a resolver latence.
• SQL federace/virtualizace: triggery jen pro čtení; zápisy směrujte na system of record.

Výkon, latence a kapacitní plánování

• Připojení: connection pooling a max connections per DB; backpressure a circuit breaker.
• Indexace: účelové indexy pro čtecí projekce; na zápisové straně minimalizovat sekundární indexy.
• Cache: read-through/write-through/side cache; invalidace řízená událostmi.
• Batching: agregace malých zápisů, komprese, bulk operace u analytických pump.

Řešení konfliktů a souběhu

• Optimistické zámky: verzovací sloupce (version, etag) při zápisu přes více čteček.
• Merge strategie: poslední zápis vyhrává, doménová pravidla, CRDT pro vybrané typy dat (počítadla, množiny).
• Čas a pořadí: stabilní časové značky (ULID/Hybrid Logical Clock), vyvarovat se závislosti na NTP posunech.

Bezpečnost napříč databázemi

• Autentizace a autorizace: separátní účty/služby s minimálními právy; row-level security tam, kde je dostupná.
• Šifrování: TLS in-flight, TDE/column-level at-rest, envelope encryption s KMS; rotace klíčů a audit.
• Maskování a anonymizace: definujte klasifikaci PII; materiálované pohledy bez citlivých atributů.
• Audit a nepopiratelnost: neměnné logy (WORM), hash řetězení, oddělené účty pro administraci a běh.

Governance, kvalita dat a MDM

• Data catalog & lineage: dohledatelnost původu a transformací; dopad změn schémat.
• Master Data Management (MDM): deduplikace entit, pravidla slučování, survivorship a správa golden record.
• Validace kvality: pravidla integrity, profily dat, monitorování anomálií v toku CDC.

Observabilita a provoz

• Tracing: korelační ID napříč vrstvami (OpenTelemetry), měření latencí per zdroj a span pro DB dotazy.
• Metriky: počet událostí/s, zpoždění replikace, velikost outbox/lag, chybovost spotřeby, saturace poolů.
• Logy: strukturované, bez tajemství; sampling pro vysokou propustnost.

Testování a verifikace

• Contract testing: validace schémat a kompatibility mezi producenty a konzumenty dat.
• Replay testy: přehrání proudů (CDC) do izolace; odhalení problémů s idempotencí a pořadím.
• Chaos a failover: simulace výpadků jedné DB, split-brain, test zotavení a konzistence.

Migrace, verze a změna schémat

• Blue/green & dual-run: dočasně zapisujte do staré i nové DB, porovnávejte čtení (shadow reads).
• Expand/contract: nejprve přidat nové sloupce/typy, až poté měnit producenty a postupně odstranit staré.
• Backfill: dávkové doplnění historických dat s řízeným tempem a kontrolou integrity.

Anti-patterny a jak se jim vyhnout

• Dual-write bez koordinace: závody a nekonzistence; používejte outbox/CDC.
• Přehnaná federace: složité dotazy přes více zdrojů v hot-path; preferujte projekce.
• Skryté kopie dat: stínové integrace bez governance; zavádějte katalog a vlastnictví dat.

Příklad referenční architektury

• Primární transakční DB (PostgreSQL) jako system of record domény Objednávky.
• CDC (Debezium) → Kafka → konzumenti: search-indexer (OpenSearch), reporting-writer (lakehouse), graph-projector (Neo4j).
• Outbox v rámci transakcí objednávek pro spolehlivé publikování doménových událostí.
• BFF/API vrstva s CQRS: zápisy míří na Postgres, čtení z materiálů (cache, search, předpočty).
• OpenTelemetry tracing, SLO: p95 latence čtení < 120 ms, zpoždění projekcí < 5 s.

Checklist pro implementaci

• Určete system of record pro každou entitu a deklarujte SLA konzistence projekcí.
• Zaveďte globální ID a idempotentní zpracování událostí.
• Implementujte outbox/CDC a monitorujte lag.
• Oddělte write/read cesty (CQRS) a navrhněte materiálované pohledy.
• Nasazujte observabilitu (tracing, metriky, logy) a alerting na anomálie.
• Definujte governance (katalog, vlastníci dat, pravidla kvality, bezpečnostní klasifikace).
• Plánujte migrace (expand/contract), testujte recovery a rollbacky.

Závěr

Integrace více databází v jednom systému je silný nástroj pro škálování, funkční bohatost a odolnost. Úspěch nestojí na jednom produktu, ale na disciplinovaném návrhu: jasném určení system of record, řízené konzistenci přes události, robustních projekcích pro čtení, observabilitě a striktní bezpečnosti. V kombinaci s dobrým řízením schémat, kvality dat a provozními SLO lze dosáhnout architektury, která efektivně obsluhuje heterogenní požadavky bez zbytečné složitosti pro vývojáře i provoz.