Na začetku so bile datoteke. Kasneje so obstajale navigacijske zbirke podatkov, ki temeljijo na strukturiranih datotekah. Potem sta obstajala IMS in CODASYL, pred približno 40 leti pa smo imeli nekaj prvih relacijskih baz podatkov. Skozi večji del osemdesetih in devetdesetih let je "baza podatkov" strogo pomenila "relacijsko bazo podatkov". Pravilo SQL.
Nato so z naraščajočo priljubljenostjo objektno usmerjenih programskih jezikov nekateri menili, da je rešitev za »neskladje impedance« objektno usmerjenih jezikov in relacijskih baz podatkov preslikava predmetov v zbirko podatkov. Tako smo končali z "objektno usmerjenimi bazami podatkov." Smešno pri podatkovnih bazah predmetov je bilo, da so bile v bistvu v bistvu običajne baze podatkov z vgrajenim preslikavnikom objektov. Ti so popustili in priljubljenost je bila naslednja resnična poskus množičnega trga v letu 2010 "NoSQL".
Napad na SQL
NoSQL je napadel tako relacijske baze podatkov kot SQL v isti smeri. Tokrat je bila glavna težava ta, da je internet uničil osnovno izhodišče 40-letne arhitekture sistema upravljanja relacijskih baz podatkov (RDBMS). Te zbirke podatkov so bile zasnovane tako, da prihranijo dragoceni prostor na disku in se navpično merijo. Zdaj je bilo preveč uporabnikov in preveč za en debel strežnik. Podatkovne zbirke NoSQL so povedale, da če imate bazo podatkov brez združevanja, brez standardnega jezika poizvedb (ker izvajanje SQL zahteva čas) in brez celovitosti podatkov, lahko letalite vodoravno in ravnate s to količino. To je rešilo vprašanje vertikalne lestvice, vendar je povzročilo nove težave.
Vzporedno s temi spletnimi sistemi za obdelavo transakcij (OLTP) je bila razvita še ena vrsta v glavnem relacijske baze podatkov, imenovana spletni analitični sistem za obdelavo (OLAP). Te zbirke podatkov so podpirale relacijsko strukturo, vendar so izvajale poizvedbe z razumevanjem, da bodo vrnile velike količine podatkov. Podjetja v osemdesetih in devetdesetih letih so bila še vedno v veliki meri usmerjena v serijsko predelavo. Poleg tega so sistemi OLAP razvili sposobnost razvijalcev in analitikov, da si predstavljajo in shranjujejo podatke kot n-dimenzionalne kocke. Če si predstavljate dvodimenzionalno matriko in poizvedbe, ki temeljijo na dveh indeksih, tako da ste v osnovi tako učinkoviti kot konstanten čas, potem pa vzamete to in dodate drugo ali drugo dimenzijo, da lahko opravite tisto, kar je v bistvu iskanje treh ali več dejavnikov (recimo ponudba, povpraševanje in število konkurentov) - stvari bi lahko učinkoviteje analizirali in napovedovali. Gradnja le-teh pa je mukotrpen in zelo usmerjen napor.
Približno istočasno z razširitvijo NoSQL so se pojavile grafične baze podatkov. Mnoge stvari same po sebi niso "relacijske" ali pa ne temeljijo na teoriji nizov in relacijski algebri, temveč na odnosih med starši in otroki ali prijatelji-prijatelji. Klasičen primer je linija izdelkov do blagovne znamke izdelka do modela do komponent v modelu. Če želite vedeti, »kaj je matična plošča v mojem prenosniku«, ugotovite, da imajo proizvajalci zapletene vire in številka znamke ali modela morda ne bo dovolj. Če želite vedeti, katere vse matične plošče se uporabljajo v liniji izdelkov, morate v klasičnem (ne CTE ali Common Table Expression) SQL sprehajati tabele in izdajati poizvedbe v več korakih. Sprva večina podatkovnih baz grafov sploh ni bila razdrobljena. V resnici je mogoče veliko vrst analiz grafov opraviti, ne da bi podatke dejansko shranili v obliki grafa.
NoSQL obljube so bile izpolnjene in obljube prekršene
Podatkovne baze NoSQL so se veliko, veliko bolje kot Oracle Database, DB2 ali SQL Server, ki vse temeljijo na 40-letni zasnovi. Vendar pa je imela vsaka vrsta zbirke podatkov NoSQL nove omejitve:
- Shrambe ključ-vrednost: preprostejšega iskanja kot db.get (ključ) ni. Vendar veliko svetovnih podatkov in primerov uporabe ni mogoče strukturirati na ta način. Poleg tega resnično govorimo o strategiji predpomnjenja. Iskanje primarnega ključa je hitro v kateri koli bazi podatkov; pomembno je zgolj tisto, kar je v spominu. V najboljšem primeru so te lestvice kot hash map. Če pa morate narediti 30 potovanj zbirke podatkov, da znova sestavite podatke, ali narediti kakršno koli zapleteno poizvedbo - to ne bo šlo. Te se zdaj pogosteje izvajajo kot predpomnilniki pred drugimi bazami podatkov. (Primer: Redis.)
- Podatkovne baze dokumentov: Te so dosegle svojo priljubljenost, ker uporabljajo JSON, predmete pa je enostavno serializirati v JSON. Prve različice teh baz podatkov niso imele nobenega združevanja in to, da je bil celoten vaš "entitet" v enem velikanskem dokumentu, je imel svoje pomanjkljivosti. Brez garancij za transakcije ste imeli tudi težave s celovitostjo podatkov. Danes nekatere podatkovne zbirke dokumentov podpirajo manj robustno obliko transakcij, vendar to ni enaka raven garancije, ki jo je večina ljudi vajena. Tudi pri enostavnih poizvedbah so te pogosto počasne glede na zakasnitev - četudi so v celotnem obsegu boljše. (Primeri: MongoDB, Amazon DocumentDB.)
- Shrambe stolpcev: te so tako hitre kot shrambe ključnih vrednosti za iskanje in lahko shranijo bolj zapletene podatkovne strukture. Vendar je početje nečesa, kar je videti kot združevanje v treh tabelah (v jeziku RDBMS) ali treh zbirkah (v jeziku MongoDB), v najboljšem primeru boleče. Ti so res odlični za podatke o časovnih vrstah (povejte mi vse, kar se je zgodilo med 13:00 in 14:00).
Obstajajo pa tudi druge, bolj ezoterične baze podatkov NoSQL. Vsem tem bazam podatkov pa je skupno pomanjkanje podpore skupnim idiomom baz podatkov in težnja po osredotočanju na "poseben namen". Nekatere priljubljene zbirke podatkov NoSQL (npr. MongoDB) so napisale odlične front-end baze podatkov in ekosistemska orodja, ki so razvijalcem olajšala sprejemanje, vendar so v svojem mehanizmu za shranjevanje oblikovale resne omejitve - da ne omenjamo omejitev glede odpornosti in razširljivosti.
Standardi zbirk podatkov so še vedno pomembni
Ena izmed stvari, zaradi katerih so bile relacijske baze podatkov prevladujoče, je bila, da imajo skupen ekosistem orodij. Najprej je bil SQL. Čeprav so narečja lahko drugačna - kot razvijalec ali analitik, če bi prešli s SQL Server 6.5 na Oracle 7, boste morda morali popraviti svoje poizvedbe in uporabiti »(+)« za zunanja združevanja, vendar so preproste stvari delovale in trde stvari so bile dokaj enostavne prevesti.
Drugič, med drugim ste imeli ODBC in kasneje še JDBC. Skoraj vsako orodje, ki bi se lahko povezalo z enim RDBMS (razen če je bilo izdelano posebej za upravljanje tega RDBMS), se lahko poveže s katerim koli drugim RDBMS. Veliko ljudi se vsak dan poveže z RDBMS in podatke vpije v Excel, da jih analizira. Ne mislim na Tableau ali katero koli od sto drugih orodij; Govorim o "materinstvu", Excelu.
NoSQL je odpravil standarde. MongoDB ne uporablja SQL kot primarnega jezika. Ko je najbližji konkurent MongoDB Couchbase iskal poizvedbeni jezik, ki bi nadomestil njihov ogrodje mapreduce, ki temelji na Javi, so ustvarili svoje narečje SQL.
Standardi so pomembni ne glede na to, ali gre za podporo ekosistemu orodij ali ker veliko ljudi, ki iščejo zbirke podatkov, niso razvijalci - in poznajo SQL.
GraphQL in vzpon upravljanja države
Veste, kdo ima dva palca in samo želi, da se stanje njegove aplikacije prebije v bazo podatkov, in ga ne zanima, kako? Ta tip. In izkaže se, da gre za celotno generacijo razvijalcev. GraphQL - ki nima nič skupnega z bazami grafov - shrani vaš objektni graf v osnovno shrambo podatkov. Razvijalca osvobaja skrbi glede te težave.
Prejšnji poskus tega so bila objektno-relacijska orodja za preslikavo ali ORM-ji, kot je hibernacija. Vzeli so objekt in ga v osnovi spremenili v SQL na podlagi nastavitve preslikave objekt-tabela. Mnogo prvih nekaj generacij tega je bilo težko konfigurirati. Poleg tega smo bili na krivulji učenja.
Večina implementacij GraphQL-a deluje z objektno-relacijskimi orodji za preslikavo, kot sta Sequelize ali TypeORM. Namesto da bi v vaši kodi izpustili skrb za upravljanje države, bosta dobro strukturirana izvedba GraphQL in API zapisala in vrnila ustrezne podatke, ko se bodo spremembe zgodile na vašem grafu objektov. Koga na ravni aplikacije zanima, kako se podatki shranjujejo?
Eden od temeljev objektno usmerjenih baz podatkov in NoSQL je bil, da se je moral razvijalec aplikacij zavedati zapletenosti shranjevanja podatkov v zbirki podatkov. Seveda je bilo to razvijalcem težko obvladati z novejšimi tehnologijami, vendar ni več težko. Ker GraphQL to skrb popolnoma odstrani.
Vnesite NewSQL ali porazdeljeni SQL
Google je imel težave z bazo podatkov in je napisal članek in kasneje izvedbo z imenom »Spanner«, ki je opisal, kako bo delovala globalno distribuirana relacijska baza podatkov. Spanner je sprožil nov val inovacij v tehnologiji relacijskih baz podatkov. Pravzaprav bi lahko imeli relacijsko bazo podatkov in jo po potrebi merili ne le z drobci, ampak po vsem svetu. In govorimo o obsegu v sodobnem smislu, ne o pogosto razočaranem in vedno zapletenem načinu RAC / Streams / GoldenGate.
Torej je bila predpostavka »shranjevanja predmetov« v relacijskem sistemu napačna. Kaj pa, če je bila glavna težava relacijskih baz podatkov zadnji del in ne prednji del? To je ideja tako imenovanih baz podatkov "NewSQL" ali bolj pravilno "porazdeljenih SQL". Zamisel je združiti učenje shranjevanja NoSQL in Googlovo idejo Spanner z zrelim, odprtokodnim RDBMS čelnim koncem, kot sta PostgreSQL ali MySQL / MariaDB.
Kaj to pomeni? To pomeni, da lahko svojo torto pojeste in tudi jeste. To pomeni, da imate lahko več vozlišč in jih prilagodite vodoravno - vključno med območji razpoložljivosti v oblaku. To pomeni, da lahko imate več podatkovnih centrov ali geografskih regij v oblaku - z eno bazo podatkov. To pomeni, da lahko imate resnično zanesljivost, grozd baz podatkov, ki se nikoli ne zmanjša, kar zadeva uporabnike.
Medtem celoten ekosistem SQL še vedno deluje! To lahko storite brez obnove celotne IT infrastrukture. Čeprav morda niste igra, ki bi "raztrgala in zamenjala" vaše tradicionalne RDBMS, večina podjetij ne poskuša uporabiti več Oracla. In kar je najboljše, še vedno lahko uporabljate SQL in vsa svoja orodja tako v oblaku kot po vsem svetu.
