The very best from relational and document databases in one model based on data consistency and integrity with unmatched performance.
Airport information boards, Flight Information Display Systems.
Vývoj a integrita dat Oracle vs Mongo db.
Největší úspora oproti Mongu je v tom, co nemusíte programovat.
V dokumentovém modelu se sdílená data typicky duplikují napříč kolekcemi a aplikace pak musí sama hlídat, aby byly všechny kopie konzistentní , když se změní gate u letu, musí ji kód dohledat a přepsat všude. Oracle to bere obráceně: data leží jednou v normalizovaných tabulkách, data jsou uložena na jednom místě, sdílení částí dokumentů se definuje deklarativně při tvorbě view a o synchronizaci se stará databáze. Změna se okamžitě propíše do všech dokumentů i tabulek, které danou hodnotu používají.
Stejně tak odpadá programování validací a integrity.
Cizí klíče, primární klíče, unikátnost, kontroly mezi tabulkami a business pravidla se definují jednou na úrovni databáze (přes constraints a tzv. validation directives) a vynutí se automaticky bez ohledu na to, která aplikace nebo jazyk zápis provádí.
Není tedy rozsáhlá a roztříštěná validační logiku v deseti mikroslužbách, kde se dá snadno obejít. MongoDB tuhle SQL funkcionalitu nemá, takže by vývojáři museli psát spoustu kódu navíc, což zvyšuje náklady na vývoj i údržbu a vytváří bezpečnostní díry.
Odpadá taky celá ORM vrstva. Klasicky se mezi objekty aplikace a relační tabulky musí stavět mapovací můstek. U duality views se operace provádějí optimálně uvnitř databáze, všechny řádky potřebné pro jeden objekt aplikace se načtou a uloží jedním přístupem do databáze, na rozdíl od často neefektivního přístupového kódu, který generují ORM nástroje. Aplikace prostě přečte dokument, upraví ho a zapíše zpět, bez řešení mapování a struktury pod tím.
Praktická výhoda pro projekt: pokud někde už máte mongo aplikaci nebo tým zvyklý na dokumentový styl, jde použít Oracle Database API for MongoDB nad dokumenty z duality view a všechna duality views jsou s MongoDB API kompatibilní. Migrovat se dá i přes JSON-to-Duality migrátor, který z existujících kolekcí navrhne normalizované tabulky a views. Přechod tak nemusí znamenat přepsání klientů.
Výkon, velikost a duplikace dat.
Tohle je přímý důsledek normalizace. Duality views ukládají dokumenty interně ve velmi úsporném normalizovaném formátu ,data jsou fyzicky jen jednou.
V Mongu se kvůli dotazovacím vzorům běžně denormalizuje, takže informace o letu nebo cestujícím leží v několika kolekcích současně.
To je nejen plýtvání místem, ale hlavně, jak píše i dokumentace, noční můra pro údržbu, protože aplikace musí společné části držet v synchronizaci. U MongoDB se data musí duplikovat, aby zůstala konzistentní, za cenu složitého aplikačního kódu.
Důležitý detail pro letiště, kde se hodně reportuje a analyzuje (zpoždění, vytíženost gate, statistiky odbavení): spouštět analytiku a reporty nad daty je v MongoDB problém. Oracle nad těmi samými daty nabízí standardní SQL, JOINy přes všechny typy dat včetně JSON a plnohodnotnou analytiku. Nemusíte data tahat jinam do datového skladu jen kvůli reportům.
Zároveň platí, že duality views se dají navrhnout účelově , pro různé skupiny uživatelů a use-casy různé pohledy nad stejnými tabulkami, bez extra úložného nákladu, protože dokumenty se materializují až na vyžádání, neukládají se.
Ale pozor na obecné pravidlo z dokumentace: čím vyšší míra normalizace, tím víc tabulek a tím víc rozkládání při zápisu a skládání (JOINů) při čtení. U objektů, které se skoro vždy čtou jako celek, se vyplatí mít to na paměti při návrhu.
Update jen části dokumentu
Rozdíl není v tom, jestli jde updatovat jen jedno pole, ale co se přitom fyzicky děje s daty.
U duality views jsou data uložená rozložená do sloupců tabulek. Když změníte jedno pole JSON dokumentu (přes json_transform s operací SET), databáze sáhne jen na příslušný sloupec daného řádku. Zbytek dokumentu se nepřepisuje. A protože sdílené hodnoty leží jen jednou, jedna změna se promítne do všech pohledů a dokumentů, které tu hodnotu používají, aniž byste museli aktualizovat kopie.
Mongo to má jinak. Každý dokument je uložený jako jeden celek pod jedním klíčem v B-stromu. Operátor $set na úrovni API vypadá jako úprava jednoho pole, ale dole pod tím to často znamená přepis celého dokumentu. Není efektivní způsob, jak změnit malou část velké hodnoty: pokud chcete upravit jeden čítač uvnitř šestnáctikilobajtového bloku, přepíše se celá hodnota. U velkých dokumentů, kterých na letišti bude dost (let s vnořenými cestujícími, zavazadly, posádkou), to znamená zbytečnou zátěž při každé drobné změně.
Druhá část je duplikace. Pokud je tatáž hodnota kvůli rychlosti čtení rozkopírovaná do víc kolekcí, musíte při změně projít a přepsat každou kopii zvlášť, jinak se data rozejdou. U duality views tohle odpadá, protože hodnota existuje jen jednou.
Stručně: u Oraclu změna jednoho pole sáhne na jeden sloupec a propíše se všude, u Monga může i drobná úprava znamenat přepis celého dokumentu a u duplikovaných dat několik zápisů.
Souběžnost bez zámků
Pro provoz, kde na stejných datech pracuje víc systémů naráz (odbavovací přepážky, mobilní appky, gate, integrace s aerolinkami), je klíčové řízení souběhu. Oracle používá optimistic / lock-free model přes ETAG hodnoty. Tradiční zamykání u bezstavových operací typu REST GET a PUT nefunguje, protože zámky jsou stavové a nedají se držet přes bezstavová volání. ETAG se počítá z obsahu dokumentu, takže zápis projde jen tehdy, když data od posledního čtení nikdo nezměnil. Je to spolehlivější než verze nebo časová razítka a automaticky to zajišťuje konzistenci i mezi dokumentovými zápisy a přímými SQL zápisy do tabulek. Navíc to drží vysokou propustnost, protože se nezamyká.
A na rozdíl od MongoDB jsou tu plně ACID transakce napříč více dokumenty i tabulkami, ne jen v rámci jednoho dokumentu, což u finančních a bezpečnostně citlivých operací (platby, vydání palubní vstupenky, přiřazení sedadla) prostě potřebujete.
Vysoká dostupnost — RAC a Data Guard
Letiště je 24/7 provoz, kde výpadek databáze znamená zastavené odbavení. Tady má Oracle vyzrálý a integrovaný stack. Oracle RAC řeší systémové výpadky rychlým a automatickým zotavením z pádů uzlů a instancí a zároveň přidává škálovatelnost, protože víc nezávislých serverů sdílí přístup k jedné databázi. S RAC máte striktní nulovou ztrátu dat při lokálních výpadcích bez výkonnostní penalizace distribuovaných databází, a přitom s plnou škálovatelností zápisu.
Data Guard je druhá vrstva, pro výpadky celé lokality.
Řeší havárie celého místa a ochranu dat pomocí transakčně konzistentních primárních a záložních databází, které nesdílejí disky, takže umožní zotavení z katastrofy lokality i z poškození dat. RAC řeší vysokou dostupnost, ale ne disaster recovery; Data Guard řeší disaster recovery, ale ne rozložení zátěže v rámci clusteru dohromady dávají dostupnost od začátku do konce. Kombinace obojího je to, čemu Oracle říká Maximum Availability Architecture, a reálně se používá třeba u nemocničních a bankovních systémů s podobnými nároky, jaké má letiště.
Bezpečnost
Bezpečnost se u duality views řeší centrálně v databázi, ne rozrříštěně v aplikačním kódu. Definujete různá views pro různé skupiny aktérů a přidělujete na ně práva a role, řízení přístupu až na úroveň jednotlivých polí. To je zásadní rozdíl proti tomu, kdybyste museli aplikačním kódem nebo ORM bránit uživateli v přístupu k celým tabulkám nebo dokumentům. Pravidlo se vynutí pokaždé, bez ohledu na to, odkud zápis přijde.
Duality views se dají kombinovat s Transparent Data Encryption (šifrování dat v klidu), Data Redaction (maskování citlivých údajů při čtení, typicky osobní data cestujících) a Virtual Private Database (řádková bezpečnost podle kontextu uživatele). K tomu auditing a granulární řízení přes role a granty. Oracle obecně nabízí bezpečnostní rámec s robustní autentizací, autorizací a auditingem, zatímco MongoDB poskytuje základní bezpečnostní funkce, které pro pokročilejší potřeby často vyžadují další konfiguraci. U letiště, kde jdou dohromady osobní údaje cestujících, bezpečnostní seznamy a provozní data, je tahle úroveň kontroly spíš nutnost než bonus.
- Data for examples.
- Duality viwes sql and graphql.
- Oracle json relational duality example.
- Relational model
Odkazy: