Problém Polyglot: řešení paradoxu „správné“ databáze

(Leszek Glasner/)

Polyglot Persistence, poprvé představený v roce 2011, je v něm nyní téměř kanonickým právem. Takže to, co musím říct, může působit jako rouhání.

většina organizací dnes přijala koncept vytrvalosti Polyglot — nasazení různých technologií pro ukládání dat založených na různých způsobech, které dotazují, analyzují a nasazují svá data. A růst a všudypřítomnost key / hodnota, graf, časové řady, a JSON datových skladů poskytla vývojářům bohaté možnosti vybrat ten správný datový nástroj pro správnou práci.

ale požadavky na nás jako vývojáře se rychle vyvinuly a věřím, že vytrvalost Polyglot se rychle bude snažit udržet krok. Nebo, možná, to je již realita, které čelíte dnes. Proč? Protože úkol, který máme, je skličující a vývojové týmy jsou již natažené tenké.

rozmanitost databází

musíme být odborníky na široké spektrum databázových technologií, z nichž každá má své vlastní dotazovací jazyky. Potřebujeme, aby naše aplikace přinášely efektivní výsledky v rostoucím počtu případů použití. A my jsme požádáni, abychom vytvořili a spravovali stovky rostoucích až tisíce různých aplikací založených na datech, které vyžadují různé datové modely a nasazení. Dokážete si představit zvládnutí a udržování další technologie nebo dotazovacího jazyka? Co takhle dalších pět? Ještě deset?

Software požírá svět, naše vývojové úsilí poroste, čas a náklady na integraci více datových úložišť jsou neudržitelné a vývojáři se zoufale potřebují zaměřit na konečnou sadu databázových technologií.

ještě důležitější je, že případy použití rostou v sofistikovanosti a to, co budeme požadovat od našich dat, bude vyžadovat použití více datových modelů, možná i okamžitě. Vytváření řešení do kódu aplikace pro výpočet dotazů není udržitelné nebo škálovatelné. Věřím, že je čas, aby organizace hledaly hybridní přístupy, které jim umožní zjednodušit své technologické portfolio a mít flexibilitu při výběru správného datového modelu pro správnou práci.

zkoumání datových modelů

zjistil jsem, že je užitečné pochopit, které datové modely fungují dobře pro různá použití a jak je lze kombinovat.

JSON databáze dokumentů

JSON je velmi univerzální pro nestrukturovaná a strukturovaná data. Rekurzivní povaha JSON umožňuje vkládání subdokumentů a seznamů proměnných délek. Kromě toho můžete dokonce ukládat řádky tabulky jako dokumenty JSON a moderní úložiště dat jsou tak dobrá při kompresi dat, že ve srovnání s relačními databázemi v podstatě neexistuje paměťová režie. Pro strukturovaná data lze validaci schématu implementovat podle potřeby pomocí rozšiřitelného HTTP API.

databáze grafů

databáze grafů jsou dobrými datovými modely pro vztahy. V mnoha reálných případech je graf velmi přirozeným datovým modelem. Zachycuje vztahy a může obsahovat informace o štítcích s každou hranou a s každým vrcholem. JSON dokumenty jsou přirozené vhodné pro ukládání tohoto typu dat vertex a edge.

databáze grafů je zvláště vhodná pro dotazy „graf“. Zásadní věc je, že dotazovací jazyk musí implementovat rutiny jako „nejkratší cesta“ a „graph traversal“, základní schopností pro ně je rychlý přístup k seznamu všech odchozích nebo příchozích okrajů vrcholu.

Multi-model databáze

multi-model databáze kombinuje možnosti dokumentu, klíč / hodnota, a graf databáze. Umožňuje zvolit různé datové modely s menší provozní režií. Mít k dispozici více datových modelů v jednom databázovém stroji zmírňuje některé problémy spojené s používáním různých datových modelů současně, protože to znamená méně provozní režie a méně synchronizace dat,a proto umožňuje obrovský skok v flexibilitě modelování dat.

najednou máte možnost uchovávat související data společně ve stejném úložišti dat, i když potřebuje různé datové modely. Schopnost kombinovat různé datové modely v rámci jednoho dotazu zvyšuje možnosti návrhu aplikací a optimalizace výkonu. A pokud se rozhodnete rozdělit vrstvu perzistence do několika různých databázových instancí (i když používají stejný datový model), stále máte tu výhodu, že musíte nasadit pouze jednu technologii. Dále je zabráněno uzamčení datového modelu.

Polyglot řešení

Polyglot Persistence byla přijata, protože nám umožnila vyhnout se kompromisům na jedné monolitické databázové technologii. Chápali jsme, že vytrvalost Polyglot přišla za cenu složitosti, náklady na výkon, a náklady na konzistenci a dostupnost, protože klastry rostly stále větší a větší. Ale většina, ne-li všechny, z nás cítil, že výhody flexibility datového modelu daleko převažují nad těmito náklady, protože jedna monolitická databáze by nikdy a nikdy neexistovala, aby řešila všechny nebo dokonce většinu požadavků a případů použití.

dnes je jasné, že potřebujeme výhody vytrvalosti Polyglot bez nákladů. Musíme mít flexibilitu při vytváření vysoce výkonných aplikací, které se horizontálně škálují a využívají různé datové modely. Potřebujeme jazyky dotazů, které nám umožňují dotazovat nativně a napříč různými datovými modely. Potřebujeme databáze, aby nám poskytly svobodu a flexibilitu při používání různých datových modelů jedinečným způsobem, jak se naše projekty nevyhnutelně vyvíjejí.

pro mnoho pokročilých organizací je již běžné používat malou databázi grafů v jedné části projektu, velké nasazení klíčů/hodnot pro jiné nebo kombinaci modelů grafů, klíčů/hodnot a dokumentů (JSON) pro jiné.

datová všestrannost

Vezměme si komplexní soubor dat, jako je tomu u letadlové flotily sestávající z několika letadel, z nichž každý se skládá z několika milionů částí, které tvoří dílčí komponenty, pak větší a menší komponenty, z nichž všechny spadají do hierarchie “ položek.“

pro optimální údržbu vozového parku musí organizace ukládat různá data na různých úrovních hierarchie, např. názvy dílů nebo součástí, sériová čísla, informace o výrobci, intervaly údržby, data údržby, informace o subdodavatelích, odkazy na příručky a dokumentaci, kontaktní osoby, informace o záruce a servisní smlouvě atd. Tento druh datové hierarchie je jasným přirozeným řešením pro databázi grafů, protože zachycuje vztahy mezi různými datovými body včetně informací na každé hraně a vrcholu. Je však databáze grafů ideální pro efektivní zodpovězení klíčových dotazů týmu údržby vozového parku?

databáze grafů funguje dobře pro otázku: „Jaké jsou všechny součásti v dané součásti?“A může pomoci odpovědět na otázku:“ vzhledem k rozbité části A, jaká je nejmenší součást letadla, která obsahuje část a pro kterou existuje postup údržby?“Ale databáze grafů by byla poněkud zbytečná se společnou otázkou, jako je“ které části tohoto letadla potřebují údržbu příští týden?“protože struktura grafu neodpovídá dotazu.

pokud by však tato Grafová data mohla být uložena jako dokumenty JSON, spojující libovolná data s vrcholy a hranami, mohla by být tato otázka snadno zodpovězena dotazem na dokument.

jde o to, že aby všechny dotazy v tomto systému byly provedeny rychle, potřebujete databázi, která může ukládat informace jako různé datové modely, často nazývané multi-modelová databáze. Nebylo by hezké, kdyby tato Grafová databáze mohla implementovat sekundární indexy na svých vrcholových datech?

ale pak by se v podstatě stala vícemodelovou databází. To je dobrý první krok. Ideální scénář je pomocí grafu, dokumentu a klíč / hodnota datový model všechny ve stejnou dobu nejprve najít díly s údržbou kvůli, spustí výše nejkratší cestu výpočtu pro každou z nich, a pak provést operaci spojit s kontakty kolekce přidat konkrétní kontaktní informace. Přístup k jinému datovému modelu by měl pouze měnit dotaz, nikoli databázi. To je místo, kam musíme jít, a brzy.

tento příklad údržby vozového parku není jedinečný nebo dokonce zvláštní. Při rozhovoru s vývojáři jsem zjistil, že je to prostě dobrý analog pro rostoucí počet a rozmanitost případů použití, které vývojáři vidí. Z mého pohledu je základním učením vytrvalosti Polyglot potřeba použít správný datový model pro správnou práci. A s inovacemi v databázové technologii můžeme mít více než jeden ve stejném databázovém stroji. Jinak musíme uznat, že Polyglot Persistence je jeho vlastní kompromis, který nás omezuje a nakonec nás postaví za naše konkurenty.

o autorovi: Max Neunhoeffer je senior developer a architekt v ArangoDB. Ve své akademické kariéře pracoval 16 let na vývoji a implementaci nových algoritmů v počítačové algebře. Před několika lety se zaměřil na databáze NoSQL. V ArangoDB je zodpovědný za „všechny distribuované věci“, včetně nasazení na Kubernetes, ale také odolnost, převzetí služeb při selhání a škálovatelnost. Mezi jeho zvláštní zájmy patří distribuované transakce, samoléčebné distribuované systémy a ladění výkonu. Kdyby jeho dny měly 48 hodin, hrál by golf, plavil se, hrál na klavír a vymýšlel nový programovací jazyk.

tagy: ArangoDB, graf, json, key-value, multi-modelová databáze, polyglot, polyglot persistence, relační

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.