Programovanie

Beyond NoSQL: The case for distributed SQL

Na začiatku boli súbory. Neskôr existovali navigačné databázy založené na štruktúrovaných súboroch. Potom to boli IMS a CODASYL a asi pred 40 rokmi sme mali jedny z prvých relačných databáz. Po väčšinu osemdesiatych a deväťdesiatych rokov pojem „databáza“ striktne znamenal „relačnú databázu“. Vládlo SQL.

Potom s rastúcou popularitou objektovo orientovaných programovacích jazykov si niektorí mysleli, že riešením „nesúladu impedancie“ objektovo orientovaných jazykov a relačných databáz bolo mapovanie objektov v databáze. Takto sme skončili s „objektovo orientovanými databázami“. Zábavné na databázach objektov bolo, že v mnohých prípadoch išlo v podstate o normálnu databázu so zabudovaným mapovačom objektov. Tieto klesali v popularite a ďalším skutočným pokusom o masový trh bol v deväťdesiatych rokoch 20. storočia „NoSQL“.

Útok na SQL

NoSQL zaútočil rovnako na relačné databázy aj na SQL. Hlavným problémom bolo tentoraz to, že internet zničil základný predpoklad 40-ročnej architektúry systému správy relačných databáz (RDBMS). Tieto databázy boli navrhnuté tak, aby šetrili vzácny priestor na disku a boli vertikálne zmenšené. Teraz bolo príliš veľa používateľov a príliš veľa na to, aby ich zvládol jeden tučný server. Databázy NoSQL uviedli, že ak máte databázu bez pripojení, bez štandardného dotazovacieho jazyka (pretože implementácia SQL si vyžaduje čas) a bez integrity dát, môžete horizontálne škálovať a zvládnuť tento zväzok. To vyriešilo otázku vertikálnej mierky, ale prinieslo nové problémy.

Paralelne s týmito systémami online spracovania transakcií (OLTP) bol vyvinutý ďalší typ hlavne relačnej databázy nazývaný systém online analytického spracovania (OLAP). Tieto databázy podporovali relačnú štruktúru, ale vykonávali dotazy s tým, že vrátia obrovské množstvo údajov. Podniky v 80. a 90. rokoch boli stále vo veľkej miere poháňané hromadným spracovaním. Systémy OLAP navyše vyvinuli schopnosť vývojárov a analytikov predstaviť si a ukladať údaje ako n-rozmerné kocky. Ak si predstavíte dvojrozmerné pole a vyhľadávania založené na dvoch indexoch, aby ste boli v zásade rovnako efektívni ako konštantný čas, potom si vezmite túto a pridajte ďalšiu alebo inú dimenziu, aby ste mohli robiť to, čo sú v podstate vyhľadávania troch alebo viacerých faktorov (povedzme ponuka, dopyt a počet konkurentov) - mohli by ste efektívnejšie analyzovať a predpovedať veci. Ich konštrukcia je však namáhavá a veľmi dávkovo zameraná.

Približne v rovnakom čase ako škálovateľný NoSQL sa objavili databázy grafov. Mnoho vecí nie je „relačných“ ako takých, alebo nie je založených na teórii množín a relačnej algebre, ale skôr na vzťahoch medzi rodičmi a deťmi alebo kamarátmi. Klasickým príkladom je rad produktov od značky produktu po model po komponenty v modeli. Ak chcete vedieť „čo je základná doska v mojom notebooku“, zistíte, že výrobcovia majú komplikované zdroje a značka alebo číslo modelu nemusí stačiť. Ak chcete vedieť, čo všetko sa základné dosky používajú v produktovej rade, v klasickom (non-CTE alebo Common Table Expression) SQL musíte prechádzať tabuľky a vydávať dotazy vo viacerých krokoch. Spočiatku sa väčšina databáz grafov vôbec nerozlišovala. V skutočnosti je možné vykonať mnoho typov grafových analýz bez toho, aby ste údaje skutočne ukladali ako graf.

Sľuby NoSQL boli dodržané a sľuby porušené

Databázy NoSQL sa škálovali oveľa, oveľa lepšie ako Oracle Database, DB2 alebo SQL Server, ktoré sú založené na 40 rokov starom dizajne. Každý typ databázy NoSQL mal však nové obmedzenia:

  • Obchody kľúč - hodnota: Neexistuje jednoduchšie vyhľadávanie ako db.get (kľúč). Väčšina svetových údajov a prípadov použitia však nemôže byť štruktúrovaná týmto spôsobom. Okrem toho skutočne hovoríme o kešovacej stratégii. Vyhľadania primárneho kľúča sú rýchle v akejkoľvek databáze; záleží iba na tom, čo je v pamäti. V lepšom prípade sa tieto mierky podobajú hašovacej mape. Ak však musíte vykonať 30 vyhľadávaní v databáze, aby ste svoje údaje spojili alebo vykonali akýkoľvek zložitý dotaz, nebude to fungovať. Tieto sa teraz častejšie implementujú ako vyrovnávacia pamäť pred ostatnými databázami. (Príklad: Redis.)
  • Databázy dokumentov: Tieto dosiahli svoju popularitu, pretože používajú súbory JSON a objekty sa dajú ľahko serializovať do formátu JSON. Prvé verzie týchto databáz sa nespájali a dostať celú svoju „entitu“ do jedného obrovského dokumentu malo svoje vlastné nevýhody. Bez záruk na transakcie ste mali tiež problémy s integritou údajov. Dnes niektoré databázy dokumentov podporujú menej robustnú formu transakcie, ale nejde o rovnakú úroveň záruky, na akú sú ľudia zvyknutí. Aj pri jednoduchých dotazoch sú často oneskorené, pokiaľ ide o latenciu, a to aj v prípade, že sú v celom rozsahu lepšie škálované. (Príklady: MongoDB, Amazon DocumentDB.)
  • Sklady stĺpcov: Sú také rýchle ako obchody kľúč-hodnota pre vyhľadávanie a môžu ukladať komplikovanejšie dátové štruktúry. Avšak robiť niečo, čo vyzerá ako spojenie medzi tromi tabuľkami (v jazyku RDBMS lingo) alebo tromi zbierkami (v jazyku MongoDB lingo), je prinajlepšom bolestivé. Sú naozaj vynikajúce pre údaje časových radov (dajte mi všetko, čo sa stalo medzi 13:00 a 14:00).

A existujú aj ďalšie, ezoterickejšie databázy NoSQL. Čo však majú všetky tieto databázy spoločné, je nedostatok podpory pre spoločné databázové idiómy a tendencia zameriavať sa na „špeciálny účel“. Niektoré populárne databázy NoSQL (napr. MongoDB) napísali vynikajúce databázové rozhrania a ekosystémové nástroje, vďaka ktorým si vývojári mohli skutočne ľahko osvojiť, avšak vo svojom úložnom jadre vytvorili vážne obmedzenia - nehovoriac o obmedzeniach odolnosti a škálovateľnosti.

Databázové štandardy sú stále dôležité

Jednou z vecí, vďaka ktorým boli relačné databázy dominantné, bolo to, že mali spoločný ekosystém nástrojov. Najprv to bolo SQL. Aj keď sa dialekty môžu líšiť - ako vývojár alebo analytik, ak ste prešli zo systému SQL Server 6.5 na Oracle 7, možno budete musieť opraviť svoje dotazy a na vonkajšie spojenia použiť znak „(+)“ - ale jednoduché veci fungovali a tvrdé veci boli primerane ľahké preložiť.

Po druhé, mali ste medzi inými ODBC a neskôr JDBC. Takmer akýkoľvek nástroj, ktorý sa mohol pripojiť k jednému RDBMS (pokiaľ nebol vyrobený špeciálne na správu tohto RDBMS), sa mohol pripojiť k akémukoľvek inému RDBMS. Existuje veľa ľudí, ktorí sa denne pripájajú k RDBMS a údaje nasávajú do programu Excel, aby ich mohli analyzovať. Nehovorím o Tableau ani o žiadnom zo stoviek ďalších nástrojov; Hovorím o „materskej lodi“, Exceli.

NoSQL sa zbavil štandardov. MongoDB nepoužíva SQL ako primárny jazyk. Keď Couchbase, najbližší konkurent MongoDB, hľadal dotazovací jazyk, ktorý by nahradil ich rámec mapreduce založený na Jave, vytvorili si vlastný dialekt SQL.

Normy sú dôležité, či už je to podpora ekosystému nástrojov, alebo preto, že veľa ľudí, ktorí vyhľadávajú databázy, nie sú vývojári - a vedia SQL.

GraphQL a nárast riadenia štátu

Viete, kto má dva palce a chce iba, aby sa stav jeho aplikácie dostal do databázy, a je mu jedno ako? Tento chalan. A ukazuje sa, že celá generácia vývojárov. GraphQL - ktorý nemá nič spoločné s databázami grafov - ukladá objektový graf do podkladového dátového skladu. To vývojára zbavuje starostí s týmto problémom.

Predchádzajúcim pokusom o to boli nástroje objektovo-relačného mapovania alebo ORM, ako napríklad Hibernate. Vzali objekt a v podstate ho premenili na SQL na základe nastavenia mapovania objektu k tabuľke. Mnoho z prvých niekoľkých generácií tohto modulu bolo ťažko konfigurovateľných. Navyše sme boli na krivke učenia sa.

Väčšina implementácií GraphQL pracuje s objektovo-relačnými mapovacími nástrojmi, ako sú Sequelize alebo TypeORM. Namiesto úniku problémov so správou stavu v celom vašom kóde, dobre štruktúrovaná implementácia GraphQL a API zapíšu a vrátia príslušné údaje, keď dôjde k zmenám v grafe objektu. Komu na úrovni aplikácie naozaj záleží na tom, ako sú údaje uložené?

Jednou z podpôr objektovo orientovaných databáz a databáz NoSQL bolo, že vývojár aplikácie musel poznať zložitosť spôsobu ukladania údajov v databáze. Pre vývojárov to bolo samozrejme ťažké zvládnuť novšie technológie, ale už to nie je ťažké. Pretože GraphQL túto obavu úplne odstraňuje.

Zadajte NewSQL alebo distribuovaný SQL

Google mal problém s databázou a napísal príspevok a neskôr implementáciu s názvom „Spanner“, ktorá popisovala, ako bude fungovať globálne distribuovaná relačná databáza. Spoločnosť Spanner podnietila novú vlnu inovácií v oblasti technológie relačných databáz. Reálne by ste mohli mať relačnú databázu, ktorú môžete v prípade potreby rozšíriť nielen pomocou črepov, ale aj po celom svete. A hovoríme o mierke v modernom zmysle, nie o často sklamanom a stále komplikovanom spôsobe RAC / Streams / GoldenGate.

Takže predpoklad „ukladania objektov“ do relačného systému bol nesprávny. Čo ak bol hlavným problémom relačných databáz back-end a nie frontend? Toto je myšlienka takzvaných „NewSQL“ alebo presnejšie „distribuovaných SQL“ databáz. Cieľom je spojiť poznatky o úložisku NoSQL a nápad spoločnosti Google Spanner s vyspelým otvoreným rozhraním front-end RDBMS, ako je PostgreSQL alebo MySQL / MariaDB.

Čo to znamená? Znamená to, že si môžete dať koláč a zjesť ho tiež. To znamená, že môžete mať viac uzlov a horizontálne ich škálovať - ​​vrátane zón dostupnosti cloudov. To znamená, že môžete mať viac dátových centier alebo cloudových geografických oblastí - s jednou databázou. To znamená, že môžete mať skutočnú spoľahlivosť, databázový klaster, ktorý nikdy neklesne, pokiaľ ide o používateľov.

Medzitým stále funguje celý ekosystém SQL! Môžete to urobiť bez prebudovania celej svojej IT infraštruktúry. Aj keď možno nebudete hrať za to, aby ste svoje tradičné RDBMS „vytrhli a nahradili“, väčšina spoločností sa nepokúša používať viac Oracle. A čo je najlepšie, stále môžete používať SQL a všetky svoje nástroje v cloude aj na celom svete.

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