NoSQL (z angličtiny nejen SQL – nejen SQL ) je označení pro širokou třídu heterogenních systémů pro správu databází, které se objevily koncem 20. století – začátkem 2010 a výrazně se liší od tradičních relačních DBMS s přístupem k datům pomocí jazyka SQL . Platí pro systémy, které se pokoušejí řešit problémy škálovatelnosti a dostupnosti kvůli úplnému nebo částečnému odmítnutí požadavků na atomičnost a konzistenci dat [1] .
Zpočátku bylo slovo NoSQL akronymem dvou anglických slov: No (“Not”) a SQL (zkratka anglického Structured Query Language - “strukturovaný dotazovací jazyk”), což dává výrazu význam “popírání SQL” . Je možné, že první, kdo začal tento termín používat, chtěl říci „No RDBMS“ („není relační DBMS “) nebo „no relational“ („ne relační“), ale NoSQL znělo lépe a nakonec se zakořenilo (jako alternativa, byla také navržena NonRel). Později bylo NoSQL vytvořeno jako vysvětlení "Not Only SQL" ("nejen SQL"). NoSQL se stalo obecným pojmem pro různé databáze a úložiště, ale neoznačuje žádnou konkrétní technologii nebo produkt [2] .
Myšlenka nerelačních databází sama o sobě není nová a používání nerelačního úložiště se datuje do dob prvních počítačů. Nerelační databáze vzkvétaly v dobách sálových počítačů a později, v dobách dominance relačních DBMS, našly využití ve specializovaných obchodech, jako jsou hierarchické adresářové služby . Vznik nové generace nerelačních DBMS byl způsoben potřebou vytvořit paralelní distribuované systémy pro vysoce škálovatelné internetové aplikace, jako jsou vyhledávače [2] .
Na počátku 21. století Google vybudoval svůj vysoce škálovatelný vyhledávač a aplikace: GMail , Mapy Google , Google Earth atd., které řeší problémy škálovatelnosti a paralelního zpracování velkého množství dat. Výsledkem byl distribuovaný souborový systém a distribuovaný koordinační systém, úložiště rodiny sloupců , běhové prostředí založené na algoritmu MapReduce . Zveřejnění popisů těchto technologií společností Google vedlo k nárůstu zájmu mezi vývojáři s otevřeným zdrojovým kódem , což vedlo k vytvoření Hadoop a zahájení souvisejících projektů určených k vytvoření technologií podobných Googlu. O rok později, v roce 2007, následoval Amazon.com příklad Google publikováním článků o vysoce dostupné databázi Amazon DynamoDB [3] .
Podpora oborových gigantů za necelých pět let vedla k širokému přijetí technologií NoSQL (a podobných) pro správu „velkých dat“ a přidaly se k tomu další velké i malé společnosti, jako například: IBM , Facebook , Netflix , eBay , Hulu , Yahoo! , se svými proprietárními a open source řešeními [3] .
Tradiční DBMS se řídí požadavky ACID na transakční systém: atomicita ( atomicita ), konzistence ( anglicky konzistence ), izolace ( anglicky isolation ), trvanlivost ( anglicky trvanlivost ), zatímco v NoSQL lze místo ACID nastavit sadu vlastností BASE. zvažováno [1] :
Termín „BASE“ navrhl Eric Brewer, autor CAP teorému , podle kterého lze v distribuovaných výpočtech zajistit pouze dvě ze tří vlastností: konzistenci dat, dostupnost nebo toleranci oddílů [1] .
Systémy na bázi BASE samozřejmě nelze použít ve všech aplikacích: pro fungování směnárenských a bankovních systémů je použití transakcí nutností. Zároveň vlastnosti ACID, jakkoli jsou žádoucí, je téměř nemožné dosáhnout v systémech s mnohamilionovým webovým publikem, jako je amazon.com [1] . Návrháři systému NoSQL tedy obětují konzistenci dat, aby dosáhli dalších dvou vlastností teorému CAP [4] . Některé DBMS, jako je Riak , umožňují vyladit požadované charakteristiky konzistence dostupnosti i pro jednotlivé požadavky zadáním počtu uzlů potřebných k potvrzení úspěchu transakce. [5]
NoSQL řešení se liší nejen designem pro škálování. Dalšími významnými funkcemi řešení NoSQL jsou [6] [7] :
Popis datového schématu v případě použití řešení NoSQL lze provést pomocí různých datových struktur: hashovací tabulky , stromy a další.
V závislosti na datovém modelu a přístupech k distribuci a replikaci existují v hnutí NoSQL čtyři hlavní typy systémů: „key-value“ ( anglicky key-value store ), „family of columns“ ( column-family store ), document -orientovaný ( úložiště dokumentů ), graf.
Nejjednodušší možností je model párů klíč–hodnota , který pro přístup k hodnotě používá klíč. Takové systémy se používají pro ukládání obrázků, specializované systémy souborů, mezipaměti objektů a systémy navržené pro škálovatelnost . Příklady takových úložišť jsou Berkeley DB , MemcacheDB , Redis , Riak , Amazon DynamoDB [6] .
Dalším typem systému je „rodina sloupců“, předchůdcem tohoto typu je systém Google BigTable . V takových systémech jsou data uložena jako řídká matice, jejíž řádky a sloupce se používají jako klíče. Typickou aplikací pro tento typ DBMS je indexování webu a také úlohy velkých objemů dat se sníženými požadavky na konzistenci . Příklady tohoto typu DBMS jsou: Apache HBase , Apache Cassandra , ScyllaDB , Apache Accumulo , Hypertable [6] [8] .
Sloupcové rodinné systémy a systémy orientované na dokumenty mají podobné případy použití: systémy pro správu obsahu, blogy, protokolování událostí. Použití časových razítek umožňuje použít tento typ systému pro organizaci přepážek, jakož i záznam a zpracování různých časových údajů [8] .
Na rozdíl od sloupcového úložiště používaného v některých relačních DBMS , které ukládají data po sloupcích v komprimované formě pro efektivitu ve scénářích OLAP , model "rodiny sloupců" ukládá data řádek po řádku a poskytuje vysoký výkon především v provozních scénářích , zatímco pro dotazy, které vyžadují procházení velkého množství dat s agregací výsledků jsou zpravidla neefektivní [8] [9] .
Dokumentově orientované DBMS se používají k ukládání hierarchických datových struktur. Své uplatnění najdou v redakčním systému , publikování, vyhledávání dokumentů . Příklady tohoto typu DBMS jsou CouchDB , Couchbase , MongoDB , eXist , Berkeley DB XML [6] .
Graf DBMS se používají pro úlohy, ve kterých mají data velké množství odkazů, například sociální sítě , detekce podvodů. Příklady: Neo4j , OrientDB , AllegroGraph , Blazegraph [10] , InfiniteGraph , FlockDB , Titan [6] [8] .
Protože hrany grafu jsou materializované , to znamená, že jsou uloženy, procházení grafu nevyžaduje další výpočty (jako spojení v SQL ), ale k nalezení počátečního vrcholu procházení jsou vyžadovány indexy. Graph DBMS obecně podporují ACID a také podporují specializované dotazovací jazyky jako Gremlin , Cypher , SPARQL , GraphQL .
V červenci 2011 Couchbase, vývojář CouchDB , Memcached a Membase , oznámil vytvoření nového dotazovacího jazyka podobného SQL – UnQL (Unstructured Data Query Language). O vytvoření nového jazyka se postarali tvůrce SQLite Richard Hipp a zakladatel projektu CouchDB Damien Katz . Vývoj byl převeden na komunitu jako veřejná doména [11] [12] [13] . Naposledy byl UnQL aktualizován v srpnu 2011 [14] , ve skutečnosti projekt nezískal žádnou podporu.