Programmering

Beyond NoSQL: Sagen til distribueret SQL

I starten var der filer. Senere var der navigationsdatabaser baseret på strukturerede filer. Så var der IMS og CODASYL, og for omkring 40 år siden havde vi nogle af de første relationsdatabaser. Gennem meget af 1980'erne og 1990'erne betød "database" strengt taget "relationsdatabase." SQL styrede.

Derefter med den stigende popularitet af objektorienterede programmeringssprog, troede nogle, at løsningen på "impedansmatchen" mellem objektorienterede sprog og relationsdatabaser var at kortlægge objekter i databasen. Således endte vi med "objektorienterede databaser." Det sjove ved objektdatabaser var, at de i mange tilfælde dybest set var en normal database med en indbygget objektmapper. Disse aftog i popularitet, og det næste rigtige massemarkedsforsøg var "NoSQL" i 2010'erne.

Angrebet på SQL

NoSQL angreb begge relationsdatabaser og SQL i samme retning. Hovedproblemet denne gang var, at Internettet havde ødelagt den underliggende forudsætning for den 40-årige RDBMS-arkitektur (relationsdatabasehåndteringssystem). Disse databaser er designet til at spare dyrebar diskplads og skalere lodret. Der var nu alt for mange brugere og alt for meget til, at en fed server kunne håndtere. NoSQL-databaser sagde, at hvis du havde en database uden sammenføjninger, intet standardforespørgselssprog (fordi implementering af SQL tager tid) og ingen dataintegritet, så kunne du skalere vandret og håndtere dette volumen. Dette løste spørgsmålet om lodret skala, men introducerede nye problemer.

Udviklet parallelt med disse online transaktionsbehandlingssystemer (OLTP) var en anden type hovedsagelig relationsdatabase kaldet et online analytisk behandlingssystem (OLAP). Disse databaser understøttede den relationelle struktur, men udførte forespørgsler med den forståelse, at de ville returnere enorme mængder data. Virksomheder i 1980'erne og 1990'erne blev stadig stort set drevet af batchbehandling. Derudover udviklede OLAP-systemer evnen for udviklere og analytikere til at forestille sig og gemme data som n-dimensionelle terninger. Hvis du forestiller dig et todimensionelt array og opslag baseret på to indekser, så du stort set er lige så effektiv som konstant tid, men tag det og tilføj en anden dimension eller en anden, så du kan gøre det, der i det væsentlige er opslag af tre eller flere faktorer (siger udbud, efterspørgsel og antallet af konkurrenter) - du kunne mere effektivt analysere og forudsige ting. At konstruere disse er imidlertid besværlig og en meget batchorienteret indsats.

Omkring samme tid som NoSQL udskaledes, opstod grafdatabaser. Mange ting er ikke ”relationelle” i sig selv eller ikke baseret på sætteori og relationel algebra, men i stedet på forhold mellem forældre-barn eller ven-til-en-ven. Et klassisk eksempel er produktlinje til produktmærke til model til komponenter i modellen. Hvis du vil vide "hvilket bundkort der er i min bærbare computer", finder du ud af, at producenterne har kompliceret sourcing, og at mærke eller modelnummer muligvis ikke er nok. Hvis du vil vide, hvilke bundkort der bruges i en produktlinje, skal du i klassisk (ikke-CTE eller Common Table Expression) SQL gå tabeller og udstede forespørgsler i flere trin. Oprindeligt splittedes de fleste grafdatabaser overhovedet ikke. I virkeligheden kan mange typer grafanalyse udføres uden faktisk at lagre dataene som en graf.

NoSQL løfter holdes og løfter brudt

NoSQL-databaser skaleres meget, meget bedre end Oracle Database, DB2 eller SQL Server, som alle er baseret på et 40-årigt design. Imidlertid havde hver type NoSQL-database nye begrænsninger:

  • Key-value-butikker: Der er ingen enklere opslag end db.get (key). Imidlertid kan meget af verdens data og brugssager ikke struktureres på denne måde. Desuden taler vi virkelig om en cachestrategi. Primære nøgleopslag er hurtige i enhver database; det er kun det, der er i hukommelsen, der betyder noget. I bedste fald skaleres disse som et hash-kort. Men hvis du skal lave 30 databaseture for at samle dine data sammen eller foretage nogen form for kompliceret forespørgsel - dette fungerer ikke. Disse implementeres nu oftere som cacher foran andre databaser. (Eksempel: Redis.)
  • Dokumentdatabaser: Disse opnåede deres popularitet, fordi de bruger JSON, og objekter er lette at serieisere til JSON. De første versioner af disse databaser havde ingen sammenføjninger, og at få hele din "enhed" til et kæmpe dokument havde sine egne ulemper. Uden transaktionsgarantier havde du også problemer med dataintegritet. I dag understøtter nogle dokumentdatabaser en mindre robust form for transaktion, men det er ikke det samme niveau af garanti, som de fleste er vant til. Selv for enkle forespørgsler er disse ofte langsomme med hensyn til latenstid - selvom de skaleres bedre med hensyn til hele tiden. (Eksempler: MongoDB, Amazon DocumentDB.)
  • Kolonneforretninger: Disse er lige så hurtige som nøgleværdibutikker til opslag, og de kan gemme mere komplicerede datastrukturer. At gøre noget, der ligner en sammenføjning på tværs af tre tabeller (i RDBMS lingo) eller tre samlinger (i MongoDB lingo) er i bedste fald dog smertefuldt. Disse er virkelig gode til tidsseriedata (giv mig alt, hvad der skete mellem 13:00 og 14:00).

Og der er andre, mere esoteriske NoSQL-databaser. Det, som alle disse databaser har haft til fælles, er imidlertid manglende støtte til almindelige database-idiomer og en tendens til at fokusere på et "specielt formål." Nogle populære NoSQL-databaser (f.eks. MongoDB) skrev fantastiske database front-ender og økosystemværktøjer, der gjorde det virkelig nemt for udviklere at vedtage, men konstruerede alvorlige begrænsninger i deres lagermotor - for ikke at nævne begrænsninger i modstandsdygtighed og skalerbarhed.

Databasestandarder er stadig vigtige

En af de ting, der gjorde relationsdatabaser dominerende, var at de havde et fælles økosystem med værktøjer. Først var der SQL. Selvom dialekter kunne være forskellige - som udvikler eller analytiker, hvis du gik fra SQL Server 6.5 til Oracle 7, skal du muligvis rette dine forespørgsler og bruge “(+)” til ydre sammenføjninger - men enkle ting fungerede, og hårde ting var rimeligt lette at oversætte.

For det andet havde du blandt andet ODBC og senere JDBC. Næsten ethvert værktøj, der kunne oprette forbindelse til en RDBMS (medmindre det blev lavet specifikt til at styre den RDBMS) kunne oprette forbindelse til andre RDBMS. Der er mange mennesker, der dagligt opretter forbindelse til en RDBMS og suger dataene ind i Excel for at analysere dem. Jeg henviser ikke til Tableau eller noget af hundreder af andre værktøjer; Jeg taler om "moderskibet", Excel.

NoSQL fjernede standarder. MongoDB bruger ikke SQL som et primært sprog. Da MongoDBs nærmeste konkurrent Couchbase ledte efter et forespørgselssprog for at erstatte deres Java-baserede mapreduce-ramme, skabte de deres egen SQL-dialekt.

Standarder er vigtige, uanset om det er at understøtte værktøjets økosystem, eller fordi mange mennesker, der spørger efter databaser, ikke er udviklere - og de kender SQL.

GraphQL og stigningen i statsstyring

Du ved, hvem der har to tommelfingre og bare vil have tilstanden for hans app til at komme ind i databasen og er ligeglad med hvordan? Denne fyr. Og det viser sig, at en hel generation af udviklere. GraphQL - som ikke har noget at gøre med grafdatabaser - gemmer din objektgraf i en underliggende datalager. Det frigør udvikleren fra at bekymre sig om dette problem.

Et tidligere forsøg på dette var objektrelationelle kortlægningsværktøjer eller ORM'er som f.eks. Dvale. De tog et objekt og forvandlede det grundlæggende til SQL baseret på en opsætning af kortlægning fra objekt til tabel. Mange af de første par generationer af dette var vanskelige at konfigurere. Desuden var vi på en indlæringskurve.

De fleste GraphQL-implementeringer arbejder med objektrelationelle kortlægningsværktøjer som Sequelize eller TypeORM. I stedet for at lække statsadministrationsproblemet i hele din kode, vil en velstruktureret GraphQL-implementering og API skrive og returnere de relevante data, når der sker ændringer i din objektgraf. Hvem, på applikationsniveau, er ligeglad med, hvordan dataene gemmes, egentlig?

En af grundene til objektorienterede og NoSQL-databaser var, at applikationsudvikleren skulle være opmærksom på, hvor kompliceret det er, hvordan data lagres i databasen. Naturligvis var det svært for udviklere at mestre med nyere teknologier, men det er ikke svært længere. Fordi GraphQL fjerner denne bekymring helt.

Indtast NewSQL eller distribueret SQL

Google havde et databaseproblem og skrev et papir og senere en implementering kaldet "Spanner", som beskrev, hvordan en globalt distribueret relationsdatabase ville fungere. Spanner udløste en ny bølge af innovation inden for relationel databaseteknologi. Du kan faktisk have en relationsdatabase og få den til at skalere ikke kun med skår, men overalt i verden, hvis det er nødvendigt. Og vi taler skala i moderne forstand, ikke den ofte skuffende og stadigt komplicerede RAC / Streams / GoldenGate-måde.

Så forudsætningen om at "opbevare objekter" i et relationelt system var forkert. Hvad hvis hovedproblemet med relationsdatabaser var backend og ikke frontend? Dette er ideen bag såkaldte “NewSQL” eller mere korrekt “distribuerede SQL” -databaser. Ideen er at kombinere læring af NoSQL-lagring og Googles Spanner-idé med en moden, open source, RDBMS-frontend som PostgreSQL eller MySQL / MariaDB.

Hvad betyder det? Det betyder, at du kan få din kage og spise den også. Det betyder, at du kan have flere noder og skalere vandret - inklusive på tværs af zoner med skytilgængelighed. Det betyder, at du kan have flere datacentre eller geografiske skyområder - med en database. Det betyder, at du kan have ægte pålidelighed, en databaseklynge, der aldrig går ned for brugerne.

I mellemtiden fungerer hele SQL-økosystemet stadig! Du kan gøre dette uden at genopbygge hele din it-infrastruktur. Selvom du muligvis ikke er spil til at "rippe og erstatte" din traditionelle RDBMS, prøver de fleste virksomheder ikke at bruge mere Oracle. Og bedst af alt kan du stadig bruge SQL og alle dine værktøjer både i skyen og over hele kloden.