Programování

Beyond NoSQL: The case for distributed SQL

Na začátku byly soubory. Později existovaly navigační databáze založené na strukturovaných souborech. Pak tu byly IMS a CODASYL a asi před 40 lety jsme měli některé z prvních relačních databází. Po většinu 80. a 90. let „databáze“ přísně znamenala „relační databáze“. Vládl SQL.

Poté s rostoucí popularitou objektově orientovaných programovacích jazyků si někteří mysleli, že řešením „impedančního nesouladu“ objektově orientovaných jazyků a relačních databází bylo mapování objektů v databázi. Tak jsme skončili u „objektově orientovaných databází“. Zábavné na databázích objektů bylo, že v mnoha případech šlo v zásadě o běžnou databázi s vestavěným mapovačem objektů. Tyto klesaly v popularitě a dalším skutečným pokusem o masový trh byl v roce 2010 „NoSQL“.

Útok na SQL

NoSQL zaútočil na relační databáze i SQL ve stejném duchu. Hlavním problémem tentokrát bylo, že internet zničil základní předpoklad 40leté architektury systému správy relačních databází (RDBMS). Tyto databáze byly navrženy tak, aby šetřily drahocenný prostor na disku a byly vertikálně škálovány. Nyní bylo příliš mnoho uživatelů a příliš mnoho na to, aby to zvládl jeden tlustý server. Databáze NoSQL uvedly, že pokud máte databázi bez připojení, bez standardního dotazovacího jazyka (protože implementace SQL vyžaduje čas) a bez integrity dat, můžete horizontálně škálovat a manipulovat s tímto svazkem. To vyřešilo problém vertikálního měřítka, ale přineslo nové problémy.

Souběžně s těmito systémy pro zpracování transakcí online (OLTP) byl vyvinut další typ převážně relační databáze zvaný systém online analytického zpracování (OLAP). Tyto databáze podporovaly relační strukturu, ale prováděly dotazy s vědomím, že vrátí obrovské množství dat. Podniky v 80. a 90. letech byly stále do značné míry taženy dávkovým zpracováním. Kromě toho systémy OLAP vyvinuly schopnost vývojářů a analytiků představit si a ukládat data jako n-rozměrné kostky. Pokud si představíte dvourozměrné pole a vyhledávání založené na dvou indexech, abyste byli v zásadě stejně efektivní jako konstantní čas, pak to vezměte a přidejte další dimenzi nebo jinou, abyste mohli dělat to, co jsou v podstatě vyhledávání tří nebo více faktorů (řekněme nabídka, poptávka a počet konkurentů) - mohli byste efektivněji analyzovat a předpovídat věci. Jejich konstrukce je však pracná a velmi dávkově zaměřená.

Přibližně ve stejnou dobu jako škálovatelný NoSQL se objevily databáze grafů. Mnoho věcí není „relačních“ samo o sobě, nebo není založeno na teorii množin a relační algebře, ale na vztazích rodič - dítě nebo přítel - přítel. Klasickým příkladem je produktová řada od značky produktu k modelu na komponenty v modelu. Pokud chcete vědět „co je základní deska v mém notebooku“, zjistíte, že výrobci mají komplikované získávání zdrojů a značka nebo číslo modelu nemusí stačit. Pokud chcete vědět, jaké základní desky se používají v produktové řadě, v klasickém (non-CTE nebo Common Table Expression) SQL musíte procházet tabulky a vydávat dotazy v několika krocích. Zpočátku se většina databází grafů vůbec nerozdávala. Ve skutečnosti lze provést mnoho typů analýzy grafů, aniž byste data skutečně ukládali jako graf.

Sliby NoSQL byly dodrženy a sliby porušeny

Databáze NoSQL se škálovaly mnohem, mnohem lépe než Oracle Database, DB2 nebo SQL Server, které jsou založeny na 40 let starém designu. Každý typ databáze NoSQL však měl nová omezení:

  • Úložiště klíč – hodnota: Neexistuje jednodušší vyhledávání než db.get (klíč). Většinu světových údajů a případů použití však nelze strukturovat tímto způsobem. Navíc opravdu mluvíme o strategii ukládání do mezipaměti. Vyhledávání primárního klíče je rychlé v jakékoli databázi; záleží pouze na tom, co je v paměti. V nejlepším případě se tyto měřítko podobá hašovací mapě. Pokud však musíte provést 30 databázových cest, abyste svá data dali dohromady nebo provedli jakýkoli druh komplikovaného dotazu - nebude to fungovat. Ty jsou nyní častěji implementovány jako mezipaměti před jinými databázemi. (Příklad: Redis.)
  • Databáze dokumentů: Dosáhly své popularity, protože používají JSON a objekty lze snadno serializovat do JSON. První verze těchto databází se nepřipojovaly a dostat celou svou „entitu“ do jednoho obrovského dokumentu mělo své vlastní nevýhody. Bez transakčních záruk jste měli také problémy s integritou dat. Dnes některé databáze dokumentů podporují méně robustní formu transakce, ale nejedná se o stejnou úroveň záruky, na kterou je většina lidí zvyklá. I při jednoduchých dotazech jsou často pomalé, pokud jde o latenci - a to i v případě, že mají lepší měřítko, pokud jde o průběh. (Příklady: MongoDB, Amazon DocumentDB.)
  • Sloupcové úložiště: Jedná se o rychlé úložiště klíčů a hodnot pro vyhledávání a mohou ukládat složitější datové struktury. Avšak dělat něco, co vypadá jako spojení napříč třemi tabulkami (v RDBMS Lingo) nebo třemi kolekcemi (v MongoDB Lingo), je přinejlepším bolestivé. Jsou opravdu skvělé pro data časových řad (dej mi vše, co se stalo mezi 13:00 a 14:00).

A existují i ​​další, esoteričtější NoSQL databáze. Co však mají všechny tyto databáze společné, je nedostatečná podpora společných databázových idiomů a tendence soustředit se na „speciální účel“. Některé populární NoSQL databáze (např. MongoDB) vytvořily skvělé databázové rozhraní a ekosystémové nástroje, které vývojářům usnadnily přijetí, ale vytvořily vážná omezení v jejich úložném modulu - nemluvě o omezeních odolnosti a škálovatelnosti.

Standardy databáze jsou stále důležité

Jednou z věcí, díky nimž byly relační databáze dominantní, bylo to, že měly společný ekosystém nástrojů. Nejprve to bylo SQL. Ačkoli dialekty mohou být různé - jako vývojář nebo analytik, pokud jste přešli z SQL Server 6.5 na Oracle 7, možná budete muset opravit své dotazy a použít „(+)“ pro vnější spojení - ale jednoduché věci fungovaly a tvrdé věci byly přiměřeně snadné přeložit.

Zadruhé jste měli mimo jiné ODBC a později JDBC. Téměř jakýkoli nástroj, který se mohl připojit k jednomu RDBMS (pokud nebyl vytvořen speciálně pro správu tohoto RDBMS), se mohl připojit k jakémukoli jinému RDBMS. Existuje spousta lidí, kteří se denně připojují k RDBMS a nasávají data do aplikace Excel, aby je mohli analyzovat. Nemluvím o Tableau ani o žádném ze stovek dalších nástrojů; Mluvím o „mateřské lodi“, Excelu.

NoSQL se zbavil standardů. MongoDB nepoužívá SQL jako primární jazyk. Když Couchbase, nejbližší konkurent MongoDB, hledal dotazovací jazyk, který by nahradil jejich rámec mapreduce založený na Javě, vytvořili svůj vlastní dialekt SQL.

Standardy jsou důležité, ať už se jedná o podporu ekosystému nástrojů, nebo proto, že mnoho lidí, kteří dotazují databáze, nejsou vývojáři - a znají SQL.

GraphQL a vzestup správy státu

Víte, kdo má dva palce a chce jen, aby se stav jeho aplikace dostal do databáze, a je mu jedno, jak? Ten chlap. A ukázalo se, že celá generace vývojářů. GraphQL - který nemá nic společného s databázemi grafů - ukládá váš objektový graf do podkladového úložiště dat. To vývojáře zbavuje starostí s tímto problémem.

Dřívější pokus o to byly objektově-relační mapovací nástroje nebo ORM, jako je Hibernate. Vzali objekt a v zásadě z něj udělali SQL na základě nastavení mapování objektu k tabulce. Mnoho z prvních několika generací bylo obtížné konfigurovat. Navíc jsme byli na křivce učení.

Většina implementací GraphQL pracuje s nástroji pro objektově-relační mapování, jako je Sequelize nebo TypeORM. Namísto úniku problému se správou stavu v celém kódu bude dobře strukturovaná implementace GraphQL a API zapisovat a vracet relevantní data, jakmile dojde ke změnám v grafu objektu. Komu na úrovni aplikace opravdu záleží na tom, jak jsou data uložena?

Jedním ze základů objektově orientovaných a NoSQL databází bylo, že si vývojář aplikace musel být vědom složitosti způsobu ukládání dat v databázi. Pro vývojáře to bylo přirozeně těžké zvládnout s novějšími technologiemi, ale už to není těžké. Protože GraphQL tuto obavu úplně odstraňuje.

Zadejte NewSQL nebo distribuovaný SQL

Google měl problém s databází a napsal článek a později implementaci nazvanou „Spanner“, která popisovala, jak bude fungovat globálně distribuovaná relační databáze. Spanner zažehl novou vlnu inovací v technologii relačních databází. Ve skutečnosti můžete mít relační databázi a nechat ji škálovat nejen pomocí střepů, ale v případě potřeby po celém světě. A mluvíme o měřítku v moderním smyslu, nikoli o často neuspokojivém a stále komplikovaném způsobu RAC / Streams / GoldenGate.

Takže premisa „ukládání objektů“ v relačním systému byla špatná. Co když hlavním problémem relačních databází byl back-end a ne front-end? To je myšlenka takzvaných „NewSQL“ nebo přesněji „distribuovaných SQL“ databází. Cílem je spojit znalosti úložiště NoSQL a myšlenky Google Spanner s vyspělým otevřeným zdrojovým rozhraním RDBMS jako PostgreSQL nebo MySQL / MariaDB.

Co to znamená? To znamená, že si můžete dát dort a sníst ho také. To znamená, že můžete mít více uzlů a horizontálně škálovat - včetně zón dostupnosti cloudu. To znamená, že můžete mít více datových center nebo cloudových geografických oblastí - s jednou databází. To znamená, že můžete mít skutečnou spolehlivost, databázový klastr, který nikdy neklesne, pokud jde o uživatele.

Mezitím celý ekosystém SQL stále funguje! Můžete to udělat, aniž byste museli znovu budovat celou svou IT infrastrukturu. I když možná nebudete hrát o „vytržení a nahrazení“ svých tradičních RDBMS, většina společností se nesnaží používat více Oracle. A co je nejlepší, stále můžete používat SQL a všechny své nástroje v cloudu i po celém světě.

$config[zx-auto] not found$config[zx-overlay] not found