Jednou z najzásadnejších volieb pri vývoji aplikácie je, či na ukladanie údajov použiť databázu SQL alebo NoSQL. Konvenčné SQL (t. J. Relačné) databázy sú produktom desaťročí technologického vývoja, osvedčených postupov a stresového testovania v reálnom svete. Sú určené pre spoľahlivé transakcie a ad hoc dotazy, základné prvky podnikových aplikácií. Tiež sú však zaťažení obmedzeniami - napríklad rigidnou schémou -, ktoré ich robia menej vhodnými pre iné druhy aplikácií.
Ako odpoveď na tieto obmedzenia vznikli databázy NoSQL. Systémy NoSQL ukladajú a spravujú údaje spôsobmi, ktoré umožňujú vysokú prevádzkovú rýchlosť a veľkú flexibilitu vývojárov. Mnohé z nich vyvinuli spoločnosti ako Google, Amazon, Yahoo a Facebook, ktoré hľadali lepšie spôsoby ukladania obsahu alebo spracovania údajov pre rozsiahle webové stránky. Na rozdiel od databáz SQL môže byť veľa databáz NoSQL horizontálne zmenšených cez stovky alebo tisíce serverov.
Výhody NoSQL však neprichádzajú bez nákladov. Systémy NoSQL všeobecne neposkytujú rovnakú úroveň konzistencie údajov ako databázy SQL. V skutočnosti, zatiaľ čo databázy SQL tradične obetovali výkon a škálovateľnosť vlastností ACID za spoľahlivé transakcie, databázy NoSQL z veľkej časti zrušili tieto záruky ACID za rýchlosť a škálovateľnosť.
Stručne povedané, databázy SQL a NoSQL ponúkajú rôzne kompromisy. Aj keď môžu súťažiť v kontexte konkrétneho projektu - ako v prípade, pre ktorý sa rozhodnú toto žiadosť alebo že aplikácie - vo väčšom obraze sa dopĺňajú. Každá z nich je vhodná pre rôzne prípady použitia. Rozhodnutie nie je ani tak prípadom, alebo skôr otázkou, ktorý nástroj je pre danú prácu vhodný.
NoSQL vs. SQL
Zásadný rozdiel medzi SQL a NoSQL nie je až taký komplikovaný. Každá z nich má inú filozofiu, ako by sa mali údaje ukladať a načítať.
S databázami SQL majú všetky údaje vrodenú štruktúru. Bežná databáza ako Microsoft SQL Server, MySQL alebo Oracle Database používa a schéma—Formálna definícia zloženia údajov vložených do databázy. Napríklad daný stĺpec v tabuľke môže byť obmedzený iba na celé čísla. Vďaka tomu budú mať údaje zaznamenané v stĺpci vysoký stupeň normalizácie. Tuhá schéma databázy SQL tiež umožňuje pomerne jednoduché vykonávanie agregácií s údajmi, napríklad pomocou JOINov.
S NoSQL možno dáta ukladať bez schémy alebo vo voľnej forme. Do ľubovoľného záznamu je možné uložiť akékoľvek údaje. Medzi databázami NoSQL nájdete štyri bežné modely ukladania údajov, ktoré vedú k štyrom bežným typom systémov NoSQL:
- Databázy dokumentov (napr. CouchDB, MongoDB). Vložené dáta sú uložené vo forme štruktúr JSON alebo „dokumentov“ vo voľnom formáte, kde môžu byť údaje čokoľvek od celých čísel cez reťazce až po voľný text. Nie je nevyhnutne potrebné špecifikovať, aké polia, ak budú nejaké, dokument obsahovať.
- Obchody s kľúčom a hodnotou (napr. Redis, Riak). K hodnotám vo voľnom formáte - od jednoduchých celých čísel alebo reťazcov až po zložité dokumenty JSON - sa v databáze pristupuje pomocou kľúčov.
- Obchody so širokým stĺpcom (napr. HBase, Cassandra). Údaje sa ukladajú do stĺpcov namiesto do riadkov, ako v konvenčnom systéme SQL. Akýkoľvek počet stĺpcov (a teda veľa rôznych typov údajov) je možné podľa potreby zoskupiť alebo agregovať pre dotazy alebo prezeranie údajov.
- Databázy grafov (napr. Neo4j). Dáta sú reprezentované ako sieť alebo graf entít a ich vzťahov, pričom každý uzol v grafe predstavuje voľnú formu dát.
Uloženie dát bez schémy je užitočné v nasledujúcich scenároch:
- Chcete rýchly prístup k údajom a viac ako spoľahlivé transakcie alebo konzistencia sa zaoberáte skôr rýchlosťou a jednoduchosťou prístupu.
- Ukladáte veľké množstvo dát a nechcete sa uzamknúť do schémy, pretože neskoršia zmena schémy môže byť pomalá a bolestivá.
- Beriete neštruktúrované údaje z jedného alebo viacerých zdrojov, ktoré ich vytvárajú, a chcete ich uchovať v pôvodnej podobe pre maximálnu flexibilitu.
- Chcete ukladať údaje v hierarchickej štruktúre, ale chcete, aby tieto hierarchie popisovali samotné údaje, nie externá schéma. NoSQL umožňuje, aby údaje boli náhodne sebareferenčné spôsobom, ktorý je pre emuláciu databáz SQL zložitejší.
Dopytovanie databáz NoSQL
Jazyk štruktúrovaných dotazov používaný tradičnými databázami poskytuje jednotný spôsob komunikácie so serverom pri ukladaní a načítaní údajov. Syntax jazyka SQL je vysoko štandardizovaná, takže hoci jednotlivé databázy môžu s určitými operáciami narábať odlišne (napr. Funkcie okna), základné informácie zostávajú rovnaké.
Naopak, každá databáza NoSQL má tendenciu mať svoju vlastnú syntax pre dopytovanie a správu údajov. Napríklad CouchDB používa na vytvorenie alebo načítanie dokumentov zo svojej databázy žiadosti vo forme JSON, ktoré sú zasielané cez HTTP. MongoDB odosiela objekty JSON cez binárny protokol prostredníctvom rozhrania príkazového riadku alebo jazykovej knižnice.
Niektoré produkty NoSQL môcť na prácu s údajmi používajte syntax podobnú SQL, ale iba v obmedzenej miere. Napríklad Apache Cassandra, databáza pre ukladanie stĺpcov, má svoj vlastný jazyk podobný SQL, Cassandra Query Language alebo CQL. Niektoré zo syntaxe CQL vychádzajú priamo z príručky SQL, napríklad kľúčové slová SELECT alebo INSERT. Ale v Cassandre neexistuje spôsob, ako vykonať JOIN alebo poddotaz, a teda súvisiace kľúčové slová v CQL neexistujú.
Architektúra zdieľaného ničoho
Návrh, ktorý je spoločný pre systémy NoSQL, je architektúra „shared-nothing“. V dizajne zdieľaného ničoho každý uzol servera v klastri pracuje nezávisle od každého iného uzla. Systém nemusí získať konsenzus z každého jedného uzla, aby vrátil časť údajov klientovi. Dotazy sú rýchle, pretože sa dajú vrátiť z ktoréhokoľvek uzla, ktorý je najbližší alebo najpohodlnejší.
Ďalšou výhodou zdieľaného nič je odolnosť a škálovateľnosť. Škálovanie klastra je také ľahké ako roztočenie nových uzlov v klastri a čakanie na ich synchronizáciu s ostatnými. Ak uzol NoSQL vypadne, ostatné servery v klastri sa budú naďalej chug. Všetky údaje zostávajú k dispozícii, aj keď je k dispozícii menej uzlov na vybavenie požiadaviek.
Upozorňujeme, že dizajn zdieľaného ničoho nie je exkluzívny do databáz NoSQL. Mnoho konvenčných systémov SQL je možné nastaviť spôsobom zdieľaného ničoho, aj keď to zvyčajne znamená obetovať konzistenciu v rámci klastra kvôli výkonu.
NoSQL obmedzenia
Ak NoSQL poskytuje toľko slobody a flexibility, prečo neopustiť SQL úplne? Jednoduchá odpoveď: Mnoho aplikácií stále vyžaduje druhy obmedzení, konzistencie a bezpečnostných opatrení, ktoré poskytujú databázy SQL. V týchto prípadoch sa môžu niektoré „výhody“ NoSQL zmeniť na nevýhody. Ďalšie obmedzenia vyplývajú zo skutočnosti, že systémy NoSQL sú relatívne nové.
Žiadna schéma
Aj keď získavate údaje vo voľnom formáte, je takmer vždy potrebné ich obmedziť, aby boli užitočné. V prípade NoSQL ukladanie obmedzení zahŕňa presun zodpovednosti z databázy na vývojára aplikácie. Napríklad, vývojár môže uložiť štruktúru prostredníctvom systému objektového relačného mapovania alebo ORM. Ale ak chcete, aby schéma fungovala so samotnými údajmi„NoSQL to zvyčajne nerobí.
Niektoré riešenia NoSQL poskytujú voliteľné mechanizmy typizácie a overovania údajov. Napríklad Apache Cassandra má množstvo natívnych dátových typov, ktoré pripomínajú tie, ktoré sa nachádzajú v konvenčných SQL.
Prípadná konzistencia
Systémy NoSQL obchodujú so silnou alebo okamžitou konzistenciou pre lepšiu dostupnosť a výkon. Konvenčné databázy zabezpečujú, že operácie sú atómový (všetky časti transakcie uspejú alebo žiadna), dôsledný (všetci používatelia majú na údaje rovnaké zobrazenie), izolovaný (transakcie si nekonkurujú) a odolný (po dokončení prežijú zlyhanie servera).
S týmito štyrmi vlastnosťami, súhrnne označovanými ako ACID, sa vo väčšine systémov NoSQL zaobchádza odlišne. Namiesto okamžitej konzistencie v rámci klastra máte eventuálne konzistencie z dôvodu času potrebného na kopírovanie aktualizácií do iných uzlov v klastri. Údaje vložené do klastra sú nakoniec k dispozícii všade, ale nemôžete zaručiť, kedy.
Transakčná sémantika, ktorá v systéme SQL zaručuje, že všetky kroky v transakcii (napr. Vykonanie predaja a zníženie inventára) sú buď dokončené, alebo vrátené späť, v NoSQL zvyčajne nie sú k dispozícii. Pre akýkoľvek systém, kde musí byť „jediný zdroj pravdy“, napríklad banka, nebude prístup NoSQL fungovať dobre. Nechcete, aby sa váš bankový zostatok líšil podľa toho, do ktorého bankomatu idete; chcete, aby sa všade uvádzalo to isté.
Niektoré databázy NoSQL majú čiastočné mechanizmy, ako to vyriešiť. Napríklad MongoDB má záruky konzistencie pre jednotlivé operácie, ale nie pre databázu ako celok. Microsoft Azure CosmosDB vám umožňuje zvoliť si úroveň konzistencie na žiadosť, takže si môžete zvoliť správanie, ktoré zodpovedá vášmu prípadu použitia. Ale s NoSQL očakávajte ako predvolené správanie prípadnú konzistenciu.
Uzamknutie NoSQL
Väčšina systémov NoSQL je koncepčne podobné, ale sú implementovaná veľmi odlišne. Každý má tendenciu mať svoje vlastné metafory a mechanizmy, ako sa údaje získavajú a spravujú.
Jedným z vedľajších účinkov je potenciálne vysoký stupeň prepojenia medzi logikou aplikácie a databázou. To nie je také zlé, ak si vyberiete systém NoSQL a budete sa ho držať, ale môže sa stať kameňom úrazu, ak systém zmeníte po ceste.
Ak migrujete napríklad z MongoDB na CouchDB (alebo naopak), musíte urobiť nielen migráciu údajov. Musíte sa tiež orientovať v rozdieloch v prístupe k údajom a programových metaforách - inými slovami, musíte prepísať časti aplikácie, ktoré pristupujú k databáze.
Znalosti NoSQL
Ďalším negatívom NoSQL je relatívny nedostatok odborných znalostí. Tam, kde je trh s konvenčnými talentmi SQL stále dosť veľký, je trh so zručnosťami NoSQL rodiaci sa.
Indeed.com uvádza ako referenciu, že ku koncu roka 2017 zostáva objem výpisov úloh pre konvenčné databázy SQL - MySQL, Microsoft SQL Server, Oracle Database atď. - za posledné tri roky vyšší ako objem pracovných miest pre MongoDB, Couchbase a Cassandra. Dopyt po odborných znalostiach NoSQL rastie, stále však predstavuje zlomok trhu s konvenčnými SQL.
Zlúčenie SQL a NoSQL
Môžeme očakávať, že niektoré rozdiely medzi systémami SQL a NoSQL časom zmiznú. Už veľa databáz SQL teraz prijíma dokumenty JSON ako natívny údajový typ a môže s týmito údajmi vykonávať dotazy. Niektoré majú dokonca natívne spôsoby, ako zaviesť obmedzenia na údaje JSON, takže sa s nimi zaobchádza rovnako dôsledne ako s konvenčnými údajmi o riadkoch a stĺpcoch.
Na druhej strane, NoSQL databázy nepridávajú iba dotazovacie jazyky podobné SQL, ale aj ďalšie možnosti tradičných databáz SQL. Napríklad minimálne dve databázy dokumentov - MarkLogic a RavenDB - sľubujú, že budú kompatibilné s ACID.
Tu a tam sa objavia náznaky, že budúce generácie databáz obkročia paradigmy a ponúknu funkcie NoSQL aj SQL. Napríklad Microsoft Azure Cosmos DB používa sadu primitívov pod kapotou na zameniteľnú reprodukciu správania oboch druhov systémov. Google Cloud Spanner je databáza SQL, ktorá kombinuje silnú konzistenciu s horizontálnou škálovateľnosťou systémov NoSQL.
Čisté systémy SQL a čisté NoSQL si stále budú mať svoje miesto ešte mnoho ďalších rokov. Rýchly a vysoko škálovateľný prístup k údajom vo voľnom formáte vám poskytne server NoSQL. To prináša niekoľko nákladov, napríklad konzistenciu čítaní a ďalšie záruky bežné pre databázy SQL. Ale pre mnoho aplikácií môže byť tieto zabezpečenie vhodné za to, čo ponúka NoSQL.
