Vídám mnoho nejasností ohledně místa a účelu mnoha nových databázových řešení („NoSQL databází“) ve srovnání s relačními databázemi, které existují již mnoho let. Pokusím se tedy vysvětlit rozdíly a nejlepší případy použití každého z nich.
Nejprve si tato databázová řešení objasníme do dvou skupin:
1) Relační databáze, které lze také nazývat relační systémy pro správu databází (RDBMS) nebo databáze SQL. Mezi nejoblíbenější z nich patří Microsoft SQL Server, Oracle Database, MySQL a IBM DB2. Tyto systémy RDBMS se většinou používají ve velkých podnicích, s výjimkou MySQL, která se většinou používá k ukládání dat pro webové aplikace, obvykle jako součást populárního zásobníku LAMP (Linux, Apache, MySQL, PHP/ Python/ Perl).
2) Nerelační databáze, nazývané také databáze NoSQL, mezi nejoblíbenější patří MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis a Neo4j. Tyto databáze se obvykle dělí do čtyř kategorií:
Všechny relační databáze lze použít pro správu transakčně orientovaných aplikací (OLTP) a většinu nerelačních databází, které patří do kategorií Document stores a Column stores, lze také použít pro OLTP, což přispívá ke zmatku. Databáze OLTP lze považovat za „operační“ databáze, které se vyznačují častými, krátkými transakcemi, které zahrnují aktualizace a které se dotýkají malého množství dat a kde je velmi důležitá souběžnost tisíců transakcí (příklady zahrnují bankovní aplikace a online rezervace). Integrita dat je velmi důležitá, takže podporují transakce ACID (Atomicity, Consistency, Isolation, Durability). To je protiklad k datovým skladům, které jsou považovány za „analytické“ databáze vyznačující se dlouhými, složitými dotazy, které se dotýkají velkého množství dat a vyžadují mnoho prostředků. Aktualizace nejsou časté. Příkladem je analýza prodejů za poslední rok.
Relační databáze obvykle pracují se strukturovanými daty, zatímco nerelační databáze obvykle pracují s polostrukturovanými daty (např. XML, JSON).
Podívejme se na jednotlivé skupiny podrobněji:
Relační databáze
Relační databáze je organizována na základě relačního modelu dat, který navrhl E. F. Codd v roce 1970. Tento model organizuje data do jedné nebo více tabulek (nebo „relací“) řádků a sloupců s jedinečným klíčem pro každý řádek. Obecně platí, že každý typ entity, který je popsán v databázi, má svou vlastní tabulku, jejíž řádky představují instance daného typu entity a sloupce představují hodnoty přiřazené dané instanci. Protože každý řádek v tabulce má svůj vlastní jedinečný klíč, lze řádky v tabulce propojit s řádky v jiných tabulkách uložením jedinečného klíče řádku, s nímž má být propojen (přičemž takový jedinečný klíč je znám jako „cizí klíč“). Codd ukázal, že pomocí této jednoduché sady pojmů lze reprezentovat datové vztahy libovolné složitosti.
Prakticky všechny relační databázové systémy používají jazyk SQL (Structured Query Language) jako jazyk pro dotazování a údržbu databáze.
Důvody dominance relačních databází jsou: jednoduchost, robustnost, flexibilita, výkonnost, škálovatelnost a kompatibilita při správě obecných dat.
Aby však mohly toto vše nabídnout, musí být relační databáze vnitřně neuvěřitelně složité. Například relativně jednoduchý příkaz SELECT může mít desítky potenciálních cest provedení dotazu, které optimalizátor dotazu vyhodnotí za běhu. To vše je uživatelům skryto, ale pod kapotou RDBMS určuje nejlepší „plán provedení“ pro zodpovězení požadavků pomocí věcí, jako jsou algoritmy založené na nákladech.
U velkých databází, zejména těch používaných pro webové aplikace, je hlavním problémem škálovatelnost. Vzhledem k tomu, že stále více aplikací vzniká v prostředích s obrovskou pracovní zátěží (např. Amazon), mohou se jejich požadavky na škálovatelnost velmi rychle měnit a růst. Relační databáze se škálují dobře, ale obvykle pouze tehdy, když k tomuto škálování dochází na jednom serveru („scale-up“). Když je kapacita tohoto jediného serveru vyčerpána, je třeba „scale-out“ a rozdělit tuto zátěž na více serverů, čímž se přechází na tzv. distribuované výpočty. V tomto okamžiku začíná složitost relačních databází způsobovat problémy s jejich potenciálem škálování. Pokud se pokusíte škálovat na stovky nebo tisíce serverů, složitost se stane ohromující. Vlastnosti, které činí relační databáze tak přitažlivými, jsou tytéž, které také drasticky snižují jejich životaschopnost jako platformy pro velké distribuované systémy.
Nerelační databáze
Databáze NoSQL poskytuje mechanismus pro ukládání a vyhledávání dat, která jsou modelována jinými prostředky než tabulkovými relacemi používanými v relačních databázích.
Motivace pro tento přístup zahrnují:
- Jednoduchost návrhu. Nemuset řešit „impedanční nesoulad“ mezi objektovým přístupem k psaní aplikací a tabulkami a řádky relační databáze založenými na schématu. Například uložení všech informací o objednávkách zákazníků do jednoho dokumentu na rozdíl od nutnosti spojovat mnoho tabulek dohromady, což vede k menšímu množství kódu k psaní, ladění a údržbě
- Lepší „horizontální“ škálování na clustery strojů, které řeší problém při prudkém nárůstu počtu současně pracujících uživatelů u aplikací přístupných přes web a mobilní zařízení. Použití dokumentů výrazně usnadňuje škálování, protože všechny informace pro danou objednávku zákazníka jsou obsaženy na jednom místě, na rozdíl od toho, aby byly rozptýleny v několika tabulkách. Databáze NoSQL automaticky rozdělují data mezi servery, aniž by vyžadovaly změny v aplikaci (auto-sharding), což znamená, že nativně a automaticky rozdělují data mezi libovolný počet serverů, aniž by aplikace musela znát složení serverového fondu. Data a zatížení dotazů se automaticky vyrovnávají mezi servery, a když dojde k výpadku serveru, lze jej rychle a transparentně nahradit bez přerušení provozu aplikace
- Jemnější kontrola nad dostupností. Servery lze přidávat nebo odebírat bez výpadku aplikace. Většina databází NoSQL podporuje replikaci dat, ukládání více kopií dat napříč clusterem nebo dokonce napříč datovými centry, aby byla zajištěna vysoká dostupnost a obnova po havárii
- Snadné zachycení všech druhů dat „Big Data“, která zahrnují nestrukturovaná a částečně strukturovaná data. Umožňuje vytvořit flexibilní databázi, která snadno a rychle pojme jakýkoli nový typ dat a není narušena změnami struktury obsahu. Databáze dokumentů jsou totiž bezschémové, což umožňuje volně přidávat pole do dokumentů JSON, aniž by bylo nutné nejprve definovat změny (schema-on-read namísto schema-on-write). Můžete mít dokumenty s jiným počtem polí než ostatní dokumenty. Například záznam pacienta, který může, ale nemusí obsahovat pole se seznamem alergií
- Rychlost. Datové struktury používané databázemi NoSQL (tj. dokumenty JSON) se liší od těch, které se standardně používají v relačních databázích, díky čemuž je mnoho operací v NoSQL rychlejších než v relačních databázích, protože není nutné spojovat tabulky (za cenu většího úložného prostoru kvůli duplikaci dat – ale úložný prostor je dnes tak levný, že to obvykle není problém). Ve skutečnosti většina databází NoSQL ani nepodporuje spojování
- Náklady. Databáze NoSQL obvykle používají clustery levných komoditních serverů, zatímco RDBMS se obvykle spoléhají na drahé proprietární servery a úložné systémy. Také licence pro systémy RDBMS mohou být poměrně drahé, zatímco mnoho databází NoSQL je open source, a tedy zdarma
Konkrétní vhodnost dané databáze NoSQL závisí na problému, který musí řešit.
Databáze NoSQL se stále častěji používají ve velkých datech a webových aplikacích pracujících v reálném čase. Oblíbenými se staly se zavedením webu, kdy databáze přešly od maximálně několika stovek uživatelů v interní podnikové aplikaci k tisícům nebo milionům uživatelů ve webové aplikaci. Systémům NoSQL se také říká „nejen SQL“, aby se zdůraznilo, že mohou podporovat i dotazovací jazyky podobné SQL.
Mnohá úložiště NoSQL ustupují od konzistence (ve smyslu teorému CAP) ve prospěch dostupnosti a tolerance rozdělení. Mezi důvody, které blokují přijetí NoSQL úložišť, patří používání nízkoúrovňových dotazovacích jazyků, nedostatek standardizovaných rozhraní a obrovské investice do stávajícího SQL. Většina NoSQL úložišť také postrádá skutečné ACID transakce nebo podporuje transakce pouze za určitých okolností a na určitých úrovních (např. na úrovni dokumentů). A konečně, RDBMS se obvykle používají mnohem jednodušeji, protože mají grafické uživatelské rozhraní, zatímco mnohá řešení NoSQL používají rozhraní příkazového řádku.
Srovnání obou
Jedním z nejzávažnějších omezení relačních databází je, že každá položka může obsahovat pouze jeden atribut. Použijeme-li příklad banky, každý aspekt vztahu zákazníka s bankou je uložen jako samostatné řádkové položky v samostatných tabulkách. Takže hlavní údaje o zákazníkovi jsou v jedné tabulce, údaje o účtu v jiné tabulce, údaje o úvěru v další tabulce, investice v jiné tabulce atd. Všechny tyto tabulky jsou vzájemně propojeny pomocí relací, jako jsou primární klíče a cizí klíče.
Nerelační databáze, konkrétně databázová úložiště klíč-hodnota nebo dvojice klíč-hodnota, se od tohoto modelu radikálně liší. Páry klíč-hodnota umožňují uložit několik souvisejících položek do jednoho „řádku“ dat v téže tabulce. Slovo „řádek“ dáváme do uvozovek, protože řádek zde ve skutečnosti není totéž co řádek relační tabulky. Například v nerelační tabulce téže banky by každý řádek obsahoval údaje o zákazníkovi a také údaje o jeho účtu, úvěru a investicích. Všechny údaje týkající se jednoho zákazníka by byly pohodlně uloženy pohromadě jako jeden záznam.
Tento způsob ukládání dat se zdá být zjevně lepší, ale má zásadní nevýhodu: úložiště klíč-hodnota na rozdíl od relačních databází nemohou vynucovat vztahy mezi datovými položkami. Například v naší databázi klíč-hodnota by byly údaje o zákazníkovi (jméno, sociální pojištění, adresa, číslo účtu, číslo vyřízení úvěru atd.) uloženy jako jeden datový záznam (místo aby byly uloženy v několika tabulkách jako v relačním modelu). Transakce zákazníka (výběry z účtu, vklady na účet, splátky úvěru, bankovní poplatky atd.) by byly rovněž uloženy jako další jediný datový záznam.
V relačním modelu existuje zabudovaný a spolehlivý způsob zajištění a vynucení obchodní logiky a pravidel na databázové vrstvě, například že výběr je účtován na správný bankovní účet, prostřednictvím primárních klíčů a cizích klíčů. V úložištích typu klíč-hodnota tato odpovědnost padá přímo na aplikační logiku a mnoha lidem je velmi nepříjemné ponechat tuto klíčovou odpovědnost pouze na aplikaci. To je jeden z důvodů, proč se relační databáze budou používat i nadále.
Pokud však jde o webové aplikace využívající databáze, aspekt důsledného vynucování obchodní logiky často nepatří mezi hlavní priority. Nejvyšší prioritou je schopnost obsloužit velké množství uživatelských požadavků, které jsou obvykle dotazy pouze pro čtení. Například na stránkách, jako je eBay, většina uživatelů pouze prochází a prohlíží zveřejněné položky (operace pouze pro čtení). Pouze zlomek těchto uživatelů skutečně podává nabídky nebo rezervuje položky (operace pro čtení a zápis). A nezapomeňte, že mluvíme o milionech, někdy i miliardách zobrazení stránek denně. Správci webu eBay mají větší zájem na rychlé odezvě, aby zajistili rychlejší načítání stránek pro uživatele webu, než na tradičních prioritách prosazování obchodních pravidel nebo zajištění rovnováhy mezi čtením a zápisem.
Databáze s relačním modelem lze vyladit a nastavit tak, aby prostřednictvím datových skladů bylo možné provádět rozsáhlé operace pouze pro čtení, a tím potenciálně obsloužit velké množství uživatelů, kteří se dotazují na velké množství dat, zejména při použití relačních architektur MPP, jako jsou Analytics Platform System, Teradata, Oracle Exadata nebo IBM Netezza, které všechny podporují škálování. Jak již bylo zmíněno, datové sklady se od typických databází liší tím, že se používají pro složitější analýzu dat. Tím se liší od transakčních (OLTP) databází, jejichž hlavním využitím je podpora provozních systémů a nabídka každodenního reportování v malém měřítku.
Skutečným problémem je však nedostatečná škálovatelnost relačního modelu při práci s aplikacemi OLTP nebo jakýmkoli řešením s velkým množstvím jednotlivých zápisů, což je doménou relačních SMP architektur. Zde mohou nerelační modely skutečně zazářit. Mohou snadno rozložit datovou zátěž mezi desítky, stovky a v extrémních případech (vzpomeňte si na vyhledávač Google) dokonce tisíce serverů. Vzhledem k tomu, že každý server zpracovává pouze malé procento z celkového počtu požadavků od uživatelů, je doba odezvy pro každého jednotlivého uživatele velmi dobrá. Ačkoli tento model distribuovaných výpočtů lze vytvořit i pro relační databáze, jeho implementace je velmi náročná, zejména při velkém množství zápisů (tj. OLTP), což vyžaduje techniky jako sharding, které obvykle vyžadují značné kódování mimo obchodní logiku aplikace. Je to proto, že relační model trvá na integritě dat na všech úrovních, která musí být zachována, i když k datům přistupuje a upravuje je několik různých serverů. To je důvod, proč je nerelační model architekturou volby pro webové aplikace, jako je cloud-computing a sociální sítě.
Takže shrnuto, RDBMS netrpí horizontálním škálováním pro vysoké transakční zatížení (miliony čtení-zápisů), zatímco databáze NoSQL řeší vysoké transakční zatížení, ale na úkor integrity dat a spojování.
Mějte na paměti, že mnoho řešení bude používat kombinaci relačních a nerelačních databází (viz Co je to polyglotní perzistence?).
Mějte také na paměti, že nemusíte potřebovat výkon nerelační databáze a místo toho vám bude stačit jen ukládání souborů do HDFS a použití Apache Hive (Apache Hive je infrastruktura datového skladu postavená nad Hadoopem pro poskytování sumarizace dat, dotazování a analýzy, kterou zajišťuje prostřednictvím jazyka podobného SQL zvaného HiveQL).
A na závěr poznámka, která přispívá ke zmatku, máme tu další kategorii tvořící název NewSQL: NewSQL je třída moderních RDBMS, které se snaží poskytovat stejný škálovatelný výkon jako systémy NoSQL pro pracovní zátěže OLTP pro čtení a zápis při zachování záruk ACID tradičních relačních databázových systémů. Jejich nevýhodou je, že nejsou určeny pro dotazy typu OLAP a jsou nevhodné pro databáze o velikosti nad několik terabytů. Příklady: VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix a Altibase.
Obrázek znázorňující kategorie, do kterých řada produktů spadá:
Vynikající graf, který ukazuje, jak všechny technologie zapadají do cloudu Azure, je z publikace Understanding NoSQL on Microsoft Azure:
Podstatné pro použití řešení NoSQL je, pokud máte aplikaci OLTP, která má tisíce uživatelů a má velmi rozsáhlou databázi vyžadující scale-out řešení a/nebo používá data JSON, zejména pokud tato data JSON mají různé struktury. Získáte také výhodu vysoké dostupnosti, protože řešení NoSQL ukládají více kopií dat. Jen mějte na paměti, že kvůli výkonu můžete obětovat konzistenci dat, stejně jako možnost spojovat data, používat SQL a provádět rychlé hromadné aktualizace. MongoDB: Pohled na relační a nerelační databáze
10 věcí, které byste měli vědět o databázích NoSQL
Úvod do databází
Rozdíl mezi SQL a NoSQL : srovnání
Rozdíl mezi databázemiSQL a NoSQL vysvětlený na několika příkladech DB
NoSQL, NewSQL nebo RDBMS: Jak si vybrat
NewSQL – RDBMS na steroidech
NoSQL vs NewSQL databáze Vyberte správný nástroj pro správnou práci
SQL vs NoSQL: chcete mít ve výchozím nastavení relační úložiště
Oracle brání relační DB proti NoSQL konkurenci
Poznejte NoSQL na Microsoft Azure
Poznejte avantgardu nových relačních databází
Do SQL nebo NoSQL? To je databázová otázka
CAP Theorem:
Co je skutečně nového v NewSQL?
MongoDB vs MySQL: Srovnávací studie databází
Vlastnosti a rozdíly mezi databázemiSQL a NoSQL