Jednou z nejzásadnějších voleb, které je třeba při vývoji aplikace udělat, je, zda k ukládání dat použít databázi SQL nebo NoSQL. Konvenční databáze SQL (tj. Relační) jsou produktem desetiletí technologického vývoje, osvědčených postupů a zátěžového testování v reálném světě. Jsou určeny pro spolehlivé transakce a ad hoc dotazy, základní prvky podnikových aplikací. Přicházejí ale také zatíženi omezeními - například rigidním schématem -, která je činí méně vhodnými pro jiné druhy aplikací.
Jako odpověď na tato omezení vznikly databáze NoSQL. Systémy NoSQL ukládají a spravují data způsoby, které umožňují vysokou provozní rychlost a velkou flexibilitu ze strany vývojářů. Mnohé z nich byly vyvinuty společnostmi jako Google, Amazon, Yahoo a Facebook, které hledaly lepší způsoby ukládání obsahu nebo zpracování dat pro rozsáhlé webové stránky. Na rozdíl od databází SQL lze mnoho databází NoSQL horizontálně škálovat přes stovky nebo tisíce serverů.
Výhody NoSQL však nepřicházejí bez nákladů. Systémy NoSQL obecně neposkytují stejnou úroveň konzistence dat jako databáze SQL. Ve skutečnosti, zatímco databáze SQL tradičně obětovaly výkon a škálovatelnost vlastností ACID za spolehlivými transakcemi, databáze NoSQL z velké části zrušily tyto záruky ACID pro rychlost a škálovatelnost.
Stručně řečeno, databáze SQL a NoSQL nabízejí různé kompromisy. I když mohou soutěžit v kontextu konkrétního projektu - jako v případě, pro který se rozhodnou tento aplikace nebo že aplikace - ve větším obrazu se doplňují. Každý z nich je vhodný pro různé případy použití. Rozhodnutí není ani tak případem, nebo spíše otázkou, který nástroj je pro danou práci vhodný.
NoSQL vs. SQL
Základní rozdíl mezi SQL a NoSQL není tak komplikovaný. Každý z nich má jinou filozofii, jak by se měla data ukládat a načítat.
S databázemi SQL mají všechna data vlastní strukturu. Konvenční databáze jako Microsoft SQL Server, MySQL nebo Oracle Database používá a schéma—Formální definice toho, jak budou složena data vložená do databáze. Například daný sloupec v tabulce může být omezen pouze na celá čísla. Ve výsledku budou mít data zaznamenaná ve sloupci vysoký stupeň normalizace. Tuhé schéma databáze SQL také umožňuje relativně snadné provádění agregací na datech, například prostřednictvím JOINů.
S NoSQL lze data ukládat způsobem bez schémat nebo volným způsobem. Jakákoli data mohou být uložena v jakémkoli záznamu. Mezi databázemi NoSQL najdete čtyři běžné modely pro ukládání dat, které vedou ke čtyřem běžným typům systémů NoSQL:
- Databáze dokumentů (např. CouchDB, MongoDB). Vložená data jsou uložena ve formě volně dostupných struktur JSON nebo „dokumentů“, kde mohou být data cokoli, od celých čísel po řetězce až po volný text. Není nutné specifikovat, jaká pole, pokud budou nějaká, dokument obsahovat.
- Obchody klíč – hodnota (např. Redis, Riak). K hodnotám ve volném tvaru - od jednoduchých celých čísel nebo řetězců až po složité dokumenty JSON - se v databázi přistupuje pomocí klíčů.
- Široký obchod se sloupci (např. HBase, Cassandra). Data se ukládají do sloupců místo do řádků jako v konvenčním systému SQL. Jakýkoli počet sloupců (a tedy mnoho různých typů dat) lze podle potřeby seskupit nebo agregovat pro dotazy nebo zobrazení dat.
- Grafové databáze (např. Neo4j). Data jsou reprezentována jako síť nebo graf entit a jejich vztahů, přičemž každý uzel v grafu představuje volnou formu dat.
Úložiště dat bez schématu je užitečné v následujících scénářích:
- Chcete rychlý přístup k datům a více než spolehlivé transakce nebo konzistence se zajímáte o rychlost a jednoduchost přístupu.
- Ukládáte velké množství dat a nechcete se uzamknout do schématu, protože pozdější změna schématu může být pomalá a bolestivá.
- Berete nestrukturovaná data z jednoho nebo více zdrojů, které je vytvářejí, a chcete data uchovat v původní podobě pro maximální flexibilitu.
- Chcete ukládat data v hierarchické struktuře, ale chcete, aby tyto hierarchie byly popsány samotnými daty, nikoli externím schématem. NoSQL umožňuje, aby data byla náhodně autoreferenční způsoby, které jsou pro emulaci databází SQL složitější.
Dotazování na databáze NoSQL
Jazyk strukturovaných dotazů používaný tradičními databázemi poskytuje jednotný způsob komunikace se serverem při ukládání a načítání dat. Syntaxe SQL je vysoce standardizovaná, takže zatímco jednotlivé databáze mohou s určitými operacemi zacházet odlišně (např. Funkce okna), základy zůstávají stejné.
Naproti tomu každá databáze NoSQL má tendenci mít svou vlastní syntaxi pro dotazování a správu dat. CouchDB například používá k vytvoření nebo načtení dokumentů ze své databáze žádosti ve formě JSON odeslané prostřednictvím protokolu HTTP. MongoDB odesílá objekty JSON přes binární protokol prostřednictvím rozhraní příkazového řádku nebo jazykové knihovny.
Některé produkty NoSQL umět pro práci s daty používejte syntaxi podobnou SQL, ale pouze v omezené míře. Například Apache Cassandra, databáze úložiště sloupců, má svůj vlastní jazyk podobný SQL, Cassandra Query Language nebo CQL. Některé syntaxe CQL vycházejí přímo z příručky SQL, například klíčová slova SELECT nebo INSERT. Neexistuje však žádný způsob, jak provést spojení nebo poddotaz v Cassandře, a související klíčová slova tedy v CQL neexistují.
Architektura nic sdíleného
Volba designu společná pro systémy NoSQL je architektura „shared-nothing“. V návrhu sdíleného ničeho funguje každý uzel serveru v klastru nezávisle na každém dalším uzlu. Systém nemusí získat konsenzus z každého jednotlivého uzlu, aby vrátil část dat klientovi. Dotazy jsou rychlé, protože je lze vracet z nejbližšího nebo nejvhodnějšího uzlu.
Další výhodou shared-nothing je odolnost a škálovatelnost. Škálování clusteru je stejně snadné jako roztočení nových uzlů v clusteru a čekání na jejich synchronizaci s ostatními. Pokud uzel NoSQL selže, ostatní servery v klastru se budou i nadále chug. Všechna data zůstávají k dispozici, i když je k dispozici méně uzlů pro uspokojení požadavků.
Všimněte si, že design sdíleného ničeho není výhradní do databází NoSQL. Mnoho konvenčních systémů SQL lze nastavit způsobem sdíleného ničeho, i když to obvykle zahrnuje obětování konzistence napříč klastrem kvůli výkonu.
Omezení NoSQL
Pokud NoSQL poskytuje tolik svobody a flexibility, proč neopustit SQL úplně? Jednoduchá odpověď: Mnoho aplikací stále vyžaduje druhy omezení, konzistence a záruk, které poskytují databáze SQL. V takových případech se některé „výhody“ NoSQL mohou změnit v nevýhody. Další omezení vyplývají ze skutečnosti, že systémy NoSQL jsou relativně nové.
Žádné schéma
I když přijímáte data ve volném formátu, téměř vždy je budete muset omezit, aby byla užitečná. U NoSQL vyžaduje uložení omezení přesun odpovědnosti z databáze na vývojáře aplikace. Například vývojář může uložit strukturu prostřednictvím systému relačního mapování objektů nebo ORM. Ale pokud chcete, aby schéma žilo se samotnými daty„NoSQL to obvykle nedělá.
Některá řešení NoSQL poskytují volitelné mechanismy zadávání a ověřování dat. Například Apache Cassandra má spoustu nativních datových typů, které připomínají ty nalezené v konvenčním SQL.
Případná konzistence
Systémy NoSQL obchodují se silnou nebo okamžitou konzistencí pro lepší dostupnost a výkon. Konvenční databáze zajišťují, že operace jsou atomový (všechny části transakce uspějí, nebo žádná), konzistentní (všichni uživatelé mají stejný pohled na data), izolovaný (transakce nekonkurují) a odolný (po dokončení přežijí selhání serveru).
Tyto čtyři vlastnosti, souhrnně označované jako ACID, jsou ve většině systémů NoSQL zpracovávány odlišně. Místo okamžité konzistence napříč klastrem máte eventuální konzistence, kvůli času potřebnému ke kopírování aktualizací do jiných uzlů v clusteru. Data vložená do klastru jsou nakonec k dispozici všude, ale nemůžete zaručit kdy.
Transakční sémantika, která v systému SQL zaručuje, že všechny kroky transakce (např. Provedení prodeje a snížení inventáře) jsou buď dokončeny, nebo vráceny zpět, nejsou v NoSQL obvykle k dispozici. Pro jakýkoli systém, kde musí existovat „jediný zdroj pravdy“, jako je banka, nebude přístup NoSQL fungovat dobře. Nechcete, aby se váš bankovní zůstatek lišil podle toho, do kterého bankomatu chodíte; chcete, aby se všude hlásilo jako totéž.
Některé databáze NoSQL mají částečné mechanismy, jak to vyřešit. Například MongoDB má záruky konzistence pro jednotlivé operace, ale ne pro databázi jako celek. Microsoft Azure CosmosDB umožňuje vybrat úroveň konzistence na požadavek, takže si můžete vybrat chování, které odpovídá vašemu případu použití. Ale s NoSQL očekávejte případnou konzistenci jako výchozí chování.
Uzamčení NoSQL
Většina systémů NoSQL je koncepčně podobné, ale jsou implementováno velmi odlišně. Každý má tendenci mít své vlastní metafory a mechanismy pro způsob dotazování a správy dat.
Jedním z vedlejších účinků je potenciálně vysoký stupeň propojení mezi logikou aplikace a databází. To není tak špatné, pokud si vyberete systém NoSQL a budete se ho držet, ale může se stát překážkou, pokud změníte systémy po silnici.
Pokud migrujete z, řekněme, z MongoDB na CouchDB (nebo naopak), musíte udělat víc než jen migrovat data. Musíte také procházet rozdíly v přístupu k datům a programových metaforách - jinými slovy musíte přepsat části aplikace, které přistupují k databázi.
Dovednosti NoSQL
Další nevýhodou NoSQL je relativní nedostatek odborných znalostí. Tam, kde je trh s konvenčními SQL talenty stále poměrně velký, trh se znalostmi NoSQL rodí.
Indeed.com uvádí jako referenci, že na konci roku 2017 zůstává objem výpisů úloh pro konvenční databáze SQL - MySQL, Microsoft SQL Server, Oracle Database atd. - za poslední tři roky vyšší než objem úloh pro MongoDB, Couchbase a Cassandru. Poptávka po odborných znalostech NoSQL roste, ale stále je to zlomek trhu s konvenčními SQL.
Sloučení SQL a NoSQL
Můžeme očekávat, že některé rozdíly mezi systémy SQL a NoSQL v průběhu času zmizí. Již mnoho databází SQL nyní přijímá dokumenty JSON jako nativní datový typ a může s těmito daty provádět dotazy. Někteří dokonce mají nativní způsoby, jak uvalit omezení na data JSON, aby se s nimi zacházelo se stejnými přísnostmi jako s konvenčními daty řádků a sloupců.
Na druhou stranu NoSQL databáze nepřidávají pouze dotazovací jazyky podobné SQL, ale i další možnosti tradičních databází SQL. Například alespoň dvě databáze dokumentů - MarkLogic a RavenDB - slibují, že budou kompatibilní s ACID.
Sem tam existují náznaky, že budoucí generace databází obkročí paradigmata a nabídnou funkce NoSQL i SQL. Například Microsoft Azure Cosmos DB používá sadu primitiv pod kapotou k zaměnitelné reprodukci chování obou druhů systémů. Google Cloud Spanner je databáze SQL, která kombinuje silnou konzistenci s horizontální škálovatelností systémů NoSQL.
Čisté systémy SQL a čisté NoSQL si stále budou mít své místo po mnoho dalších let. Podívejte se na NoSQL, kde získáte rychlý a vysoce škálovatelný přístup k volným datům. To přichází s několika náklady, jako je konzistence čtení a další ochranná opatření společná pro databáze SQL. Ale pro mnoho aplikací může být tato ochrana dobře obchodovatelná s tím, co nabízí NoSQL.
