Integrace více databází v rámci jednoho 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, časových řad, 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áší výhody, 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é databázi se šíří do ostatních přes události (CDC, outbox) a vznikají materiálované pohledy.
Virtuální integrace: vrstva dotazování (federace SQL/GraphQL) agreguje data v reálném čase bez fyzické replikace.
ETL/ELT: periodické dávkové zpracování do datového skladu nebo datového jezera pro analytické scénáře.

Volba strategií podle use-casu

Use-case	Doporučený vzor	Poznámka
Transakční provoz	Saga, outbox, CQRS	Vyhnout se 2PC, zpracování musí být idempotentní
Fulltext a fasety	Asynchronní indexace (CDC → search)	Materiálovaný index (Elasticsearch/OpenSearch)
360° pohled na zákazníka	MDM + virtuální federace	Řešit kvalitu dat a golden record
Analytika/BI	ELT do DWH/lakehouse	Denormalizace, time-travel, SCD
Grafové vztahy	Dual-write → graf	Kurátorované projekce vztahů

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í databázi.
Referenční integrita: mimo jednu databázi není zajištěna – vynucujte ji aplikačně (části workflow, kompenzace).
Schéma a kontrakty: spravujte přes schema registry (JSON Schema, Protobuf), verzování se zpětnou kompatibilitou.

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

Silná konzistence napříč DB je nákladná (latence, dostupnost). Použijte ji pouze tam, kde je nezbytná (např. zůstatky).
Eventual consistency pro většinu projekcí; uživateli komunikujte 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 zápisu.

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

2PC (two-phase commit): jednoduchý mentální model, ale vysoké náklady, koordinátor jako SPOF, omezená podpora napříč databázemi.
Saga pattern: obchodní proces jako série lokálních transakcí s kompenzačními kroky; orchestrace (centrální) vs. choreografie (řízená událostmi).
TCC (Try-Confirm/Cancel): rezervace zdrojů následovaná potvrzením; vhodné pro platební a rezervační systémy.

Outbox, CDC a přesuny dat

Transactional outbox: zapisujte události do outbox tabulky ve stejné transakci jako obchodní změnu; zajišťuje 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) části umožňuje optimalizovat data pro specifické dotazy. Čtecí modely (např. dokumentové, vyhledávací indexy, agregace) se aktualizují asynchronně na základě událostí.

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

Data Access Layer (DAL): jasné hranice podle domény, anti-korupční vrstvy pro specifické databázové ovladače.
Federace GraphQL: sjednocení více zdrojů pod jedním schématem; pozor na N+1 dotazy a latenci resolverů.
SQL federace/virtualizace: triggery pouze 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 na databázi; 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 procesů.

Řešení konfliktů a souběhu

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

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/šifrování na úrovni sloupců 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 provoz.

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 databázové dotazy.
Metriky: počet událostí/s, zpoždění replikace, velikost outbox/lag, chybovost spotřeby, saturace poolů.
Logy: strukturované, bez citlivých dat; 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) v izolaci; odhalení problémů s idempotencí a pořadím.
Chaos a failover: simulace výpadků jedné databáze, split-brain, testy zotavení a konzistence.

Migrace, verze a změna schémat

Blue/green & dual-run: dočasně zapisujte do staré i nové databáze, porovnávejte čtení (shadow reads).
Expand/contract: nejprve přidejte nové sloupce/typy, poté upravte producenty a postupně odstraňte 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 vlastníky dat.

Příklad referenční architektury

Primární transakční databáze (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 PostgreSQL, čtení z materiálizovaných pohledů (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 definujte 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.