Vysvětlení rozdílů mezi NoSQL a relačními databázemi
platí pro: 
SQL api
rozhraní API Cassandra
Gremlin api
rozhraní API pro tabulky
Azure Cosmos DB api pro MongoDB
Tento článek uvádí některé klíčové výhody databází NoSQL ve srovnání s relačními databázemi. Probereme také některé problémy při práci s NoSQL. Pokud se chcete podrobně podívat na různá existující úložiště dat, podívejte se na náš článek o výběru vlastního úložiště dat.
Vysoká propustnost
Jedním z nejběžnějších problémů při údržbě relačního databázového systému je, že většina relačních modulů používá zámky a západky k vynucení striktní sémantiky ACID. Tento přístup má výhody z hlediska zajištění konzistentního stavu dat v databázi. S ohledem na souběžnost, latenci a dostupnost ale existují velké promyšlosti. Vzhledem k těmto základním omezením architektury může vysoké objemy transakcí vést k sadě ručních horizontálních oddílů dat. Implementace ručního horizontálního dělení může být časově náročné a náročné cvičení.
V těchto scénářích mohou distribuované databáze nabízet škálovatelné řešení. Údržba ale může být i tak nákladná a časově náročná. Správci možná musí udělat další práci, aby zajistili, že distribuovaná povaha systému bude transparentní. Je také možné, že budou muset zohlednit "odpojenou" povahu databáze.
Azure Cosmos DB tyto výzvy zjednodušuje tím, že je nasazovat po celém světě ve všech oblastech Azure. Rozsahy oddílů je možné dynamicky rozdělit, aby se databáze bez problémů zvětšila v souladu s aplikací a současně zachovala vysoká dostupnost. Jemně odstupňovaná vícevrstvá a vysoce kontrolovaná správa prostředků nativní pro cloud usnadňuje snížení záruk latence a předvídatelného výkonu. Dělení je plně spravované, takže správci nemusí psát kód ani spravovat oddíly.
Pokud vaše transakční svazky dosahují extrémních úrovní, například u mnoha tisíc transakcí za sekundu, měli byste zvážit distribuovanou databázi NoSQL. Zvážení služby Azure Cosmos DB pro dosažení maximální efektivity, snadné údržby a snížení celkových nákladů na vlastnictví.
Hierarchická data
Existuje mnoho případů použití, kdy transakce v databázi mohou obsahovat mnoho vztahů nadřazený-podřízený. Tyto vztahy se v průběhu času mohou výrazně zvětšovat a jejich správa může být obtížná. Během 80. let 20. let se objevily formy hierarchických databází, ale nebyly oblíbené kvůli neefektivnímu ukládání. S tím, jak se relační model Teda Codda stal ve skutečnosti standardem používaným prakticky všemi běžnými systémy pro správu databází, se ztratily.
Dnes se ale výrazně zvýšila oblíbenost databází ve stylu dokumentů. Tyto databáze se můžou považovat za nové vynalézání paradigmatu hierarchické databáze, které se teď nepřebývá obavami ohledně nákladů na ukládání dat na disk. V důsledku toho je teď možné udržovat mnoho složitých vztahů mezi entitami nadřazený-podřízený v relační databázi v porovnání s moderními přístupy orientovanými na dokumenty za anti-vzor.
Vznik objektově orientovaného návrhu a neshody impedance, ke které dochází při jeho kombinování s relačními modely, také zvýrazní anti-vzor v relačních databázích pro určité případy použití. V důsledku toho mohou vznikat skryté, ale často významné náklady na údržbu. I když se přístupy ORM vyvinuly, aby se tento problém částečně zmírňuje, dokumentově orientované databáze se ale s objektově orientovanými přístupy mnohem lépe směřuje. S tímto přístupem nejsou vývojáři nuceni být potvrzeni ovladači ORM nebo moduly databáze OO Database specifické pro určitý jazyk. Pokud vaše data obsahují mnoho vztahů nadřazenosti a podřízené úrovně hierarchie a hluboké úrovně hierarchie, můžete zvážit použití dokumentové databáze NoSQL, jako je azure Cosmos DB SQL API.
Složité sítě a vztahy
Je ironií, že vzhledem k jejich názvu představují relační databáze méně než optimální řešení pro modelování hlubokých a složitých vztahů. Důvodem je to, že relace mezi entitami ve skutečnosti v relační databázi neexistují. Musí se počítat za běhu, kdy složité relace vyžadují kartézská spojení, aby bylo možné mapování pomocí dotazů. V důsledku toho jsou operace exponenciálně dražší z hlediska výpočtů s tím, jak se relace zvyšují. V některých případech se relační databáze pokoušející o správu takových entit stane nepoužitelnou.
V době, kdy se objevily relační databáze, se objevily různé formy "síťových" databází, ale stejně jako u hierarchických databází se tyto systémy snažily získat popularitu. Pomalé přijetí bylo způsobeno nedostatkem případů použití v době a nedostatečnou efektivitou úložiště. Grafové databázové stroje by se dnes mohly považovat za obnovení paradigmatu síťové databáze. Klíčovou výhodou těchto systémů je to, že relace jsou v databázi uložené jako "prvošénové občany". Proto je možné relace procházení provést v konstantním čase, místo toho, aby se při každém novém spojení nebo křížových produktech zvětšuje časová složitost.
Pokud ve své databázi udržujete složitou síť relací, můžete zvážit použití grafové databáze, jako je rozhraní Gremlin API služby Azure Cosmos DB pro správu těchto dat.
Azure Cosmos DB je databázová služba pro více modelů, která nabízí projekci rozhraní API pro všechny hlavní typy modelů NoSQL. Rodinu sloupců, Dokument, Graph a Klíč-hodnota. Vrstvy rozhraní Api pro dokumenty Gremlin (graf) a SQL (Core) jsou plně interoperabilní. To má výhody při přepínání mezi různými modely na úrovni programovatelnosti. Graph úložiště lze dotazovat jak z hlediska komplexních síťových procházení, tak transakcí modelovaných jako záznamy dokumentů ve stejném obchodě.
Schéma fluid
Další zvláštní charakteristikou relačních databází je to, že schémata musí být definována v době návrhu. To má výhody z hlediska referenční integrity a zachování dat. Může však být také omezující s tím, jak aplikace roste. Reakce na změny ve schématu napříč logicky oddělenými modely, které sdílejí stejnou definici tabulky nebo databáze, může být časem složitá. Takové případy použití často těží z toho, že schéma se přemisťují do aplikace a spravuje se pro každý záznam. To vyžaduje, aby databáze byla "bez schématu" a aby záznamy "popisovala sama sebe" z hlediska dat, která jsou v nich obsažena.
Pokud spravujete data, jejichž struktury se neustále mění vysokou rychlostí, zejména v případě, že transakce pocházejí z externích zdrojů, u kterých je obtížné vynutit provázanost napříč databází, můžete zvážit přístup, který není založený na schématu, a to pomocí spravované databázové služby NoSQL, jako je Azure Cosmos DB.
Mikroslužby
Model mikroslužeb se v posledních letech výrazně rozrostl. Tento model má své kořeny v architektuře orientované na služby. De facto standard pro přenos dat v těchto moderních architekturách mikroslužeb je JSON, což je také úložné médium pro velkou většinu dokumentově orientovaných databází NoSQL. Díky tomu jsou úložiště dokumentů NoSQL mnohem bezproblémovější pro trvalost i synchronizaci (pomocí vzorů event sourcing)napříč komplexními implementacemi mikroslužeb. V těchto architekturách může být údržba tradičnějších relačních databází mnohem složitější. Je to způsobené větším množstvím transformací, které jsou potřeba pro stav i synchronizaci mezi rozhraními API. Azure Cosmos DB má zejména řadu funkcí, díky které je ještě hladší pro architektury mikroslužeb založené na JSON než mnoho databází NoSQL:
- Výběr čistě datových typů JSON
- Modul JavaScriptu a rozhraní API pro dotazy integrované do databáze.
- Moderní informační kanál změn, ke kterému se klienti mohou přihlásit k odběru, aby mohli dostat oznámení o změnách kontejneru.
Některé problémy s databázemi NoSQL
I když implementace databází NoSQL má určité jasné výhody, je tu také několik výzev, které byste měli vzít v úvahu. Při práci s relačním modelem nemusí být přítomné ve stejné míře:
- transakce s mnoha relacemi odkazující na stejnou entitu.
- transakce, které vyžadují silnou konzistenci v celé datové sadě.
Při pohledu na první výzvu je obecné pravidlo v databázích NoSQL obecně denormalizace, která , jak jsme už zmínili dříve, produkuje efektivnější čtení v distribuovaném systému. S tímto přístupem ale přicházejí do hry některé problémy s návrhem. Podívejme se na příklad produktu, který souvisí s jednou kategorií a několika značkami:
Osvědčeným postupem v databázi dokumentů NoSQL je denormalizovat názvy kategorií a značek přímo v "dokumentu produktu". Aby však byly kategorie, značky a produkty synchronizované, možnosti návrhu, které to usnadňují, mají větší složitost údržby, protože data jsou duplikována napříč více záznamy v produktu, a nikoli jako jednoduchá aktualizace v relaci 1:N a spojení pro načtení dat.
Je to proto, že čtení je v denormalizovaném záznamu efektivnější a s rostoucím počtem koncepčně připojených entit je stále efektivnější. Stejně jako se ale efektivita čtení zvyšuje s rostoucím počtem připojených entit v denormalizovat záznamu, zvyšuje se i složitost údržby, která znamená udržování synchronizovaných entit. Jedním ze zdrojů, jak tento obchod zmírnit, je vytvoření hybridního datového modelu.
V databázích NoSQL je sice k dispozici větší flexibilita při řešení těchto obchodních možností, ale větší flexibilita může také vytvářet větší rozhodnutí o návrhu. Informace o modelování a dělení dat ve službě Azure Cosmos DBnajdete v našem článku s příkladem z reálného světa, který zahrnuje přístup k synchronizaci denormalizovaných uživatelských dat, kdy uživatelé nesedí nejen v různých oddílech, ale i v různých kontejnerech.
S ohledem na silnou konzistenci je vzácné, že se to bude požadováno napříč celou datovou sadu. V případech, kdy je to potřeba, to ale může být v distribuovaných databázích problém. Aby se zajistila silná konzistence, musí se data synchronizovat napříč všemi replikami a oblastmi, aby je klienti načetly. To může zvýšit latenci čtení.
Azure Cosmos DB opět nabízí větší flexibilitu než relační databáze pro různé obchody, které jsou zde relevantní, ale pro implementace v malém měřítku může tento přístup přidat další aspekty návrhu. Další podrobnosti najdete v našem článku o kompromisech mezi konzistencí, dostupností a výkonem.
Další kroky
Zjistěte, jak spravovat účet azure Cosmos a další koncepty: