I begynnelsen var det filer. Senere var det navigasjonsdatabaser basert på strukturerte filer. Så var det IMS og CODASYL, og for rundt 40 år siden hadde vi noen av de første relasjonsdatabasene. Gjennom store deler av 1980- og 1990-tallet betydde "database" strengt tatt "relasjonsdatabase." SQL styrte.
Så med den økende populariteten til objektorienterte programmeringsspråk, trodde noen at løsningen på "impedansmatchen" mellom objektorienterte språk og relasjonsdatabaser var å kartlegge objekter i databasen. Dermed endte vi opp med "objektorienterte databaser." Det morsomme med objektdatabaser var at de i mange tilfeller i utgangspunktet var en normal database med en innebygd kartlegger. Disse avtok i popularitet, og det neste virkelige massemarkedsforsøket var “NoSQL” på 2010-tallet.
Angrepet på SQL
NoSQL angrep både relasjonsdatabaser og SQL i samme retning. Hovedproblemet denne gangen var at Internett hadde ødelagt den underliggende forutsetningen for den 40 år gamle RDBMS-arkitekturen (relationsdatabasehåndteringssystem). Disse databasene ble designet for å spare dyrebar diskplass og skalere vertikalt. Det var nå altfor mange brukere og altfor mye for en fet server å håndtere. NoSQL-databaser sa at hvis du hadde en database uten tilknytning, ikke noe standard spørrespråk (fordi implementering av SQL tar tid), og ingen dataintegritet, kan du skalere horisontalt og håndtere det volumet. Dette løste problemet med vertikal skala, men introduserte nye problemer.
Utviklet parallelt med disse online transaksjonsbehandlingssystemene (OLTP) var en annen type hovedsakelig relasjonsdatabase kalt et online analytisk behandlingssystem (OLAP). Disse databasene støttet relasjonsstrukturen, men utførte spørsmål med den forståelse at de ville returnere enorme mengder data. Bedrifter på 1980- og 1990-tallet ble fremdeles i stor grad drevet av batchbehandling. I tillegg utviklet OLAP-systemer muligheten for utviklere og analytikere til å forestille seg og lagre data som n-dimensjonale kuber. Hvis du forestiller deg en todimensjonal matrise og oppslag basert på to indekser, slik at du i utgangspunktet er like effektiv som konstant tid, men tar det og legger til en annen dimensjon eller en annen slik at du kan gjøre det som egentlig er oppslag av tre eller flere faktorer (si tilbud, etterspørsel og antall konkurrenter) - du kan mer effektivt analysere og forutsi ting. Å konstruere disse er imidlertid arbeidskrevende og en veldig batch-orientert innsats.
Rundt samme tid som NoSQL ble utskalert, dukket grafdatabaser opp. Mange ting er ikke ”relasjonelle” i seg selv, eller ikke basert på mengdeteori og relasjonsalgebra, men i stedet på foreldre-barn eller venn-til-en-venn-forhold. Et klassisk eksempel er produktlinje til produktmerke til modell til komponenter i modellen. Hvis du vil vite "hvilket hovedkort det er i den bærbare datamaskinen min", finner du ut at produsenter har kompliserte innkjøp, og at merke- eller modellnummeret kanskje ikke er nok. Hvis du vil vite hvilke hovedkort som brukes i en produktlinje, må du i klassisk (ikke-CTE eller Common Table Expression) SQL gå tabeller og utføre spørsmål i flere trinn. I utgangspunktet skjæres de fleste grafdatabaser ikke i det hele tatt. I sannhet kan mange typer grafanalyser gjøres uten å lagre dataene som en graf.
NoSQL-løfter holdes og løftene brytes
NoSQL-databaser skalerte mye, mye bedre enn Oracle Database, DB2 eller SQL Server, som alle er basert på en 40 år gammel design. Hver type NoSQL-database hadde imidlertid nye begrensninger:
- Nøkkelverdibutikker: Det er ingen enklere oppslag enn db.get (nøkkel). Mye av verdens data og brukssaker kan imidlertid ikke struktureres på denne måten. Videre snakker vi virkelig om en cachingstrategi. Primære nøkkeloppslag er raske i enhver database; det er bare det som er i minnet som betyr noe. I beste fall skaleres disse som et hash-kart. Men hvis du må gjøre 30 databaseturer for å sette sammen dataene dine eller gjøre noen form for kompliserte spørsmål - dette fungerer ikke. Disse implementeres nå oftere som cacher foran andre databaser. (Eksempel: Redis.)
- Dokumentdatabaser: Disse oppnådde sin popularitet fordi de bruker JSON og objekter er enkle å serieisere til JSON. De første versjonene av disse databasene hadde ingen tilknytning, og å få hele din "enhet" til ett gigantisk dokument hadde sine egne ulemper. Uten transaksjonsgarantier hadde du også problemer med dataintegritet. I dag støtter noen dokumentdatabaser en mindre robust form for transaksjon, men det er ikke det samme nivået på garanti folk flest er vant til. Også for enkle spørsmål er disse ofte sakte når det gjelder ventetid - selv om de skalerer bedre når det gjelder hele. (Eksempler: MongoDB, Amazon DocumentDB.)
- Kolonnebutikker: Disse er like raske som nøkkelverdibutikker for oppslag, og de kan lagre mer kompliserte datastrukturer. Imidlertid er det i beste fall smertefullt å gjøre noe som ser ut som en sammenføyning på tvers av tre tabeller (i RDBMS lingo) eller tre samlinger (i MongoDB lingo). Dette er veldig bra for tidsseriedata (gi meg alt som skjedde mellom 13:00 og 14:00).
Og det er andre, mer esoteriske NoSQL-databaser. Det som alle disse databasene har hatt til felles, er imidlertid mangel på støtte for vanlige databaseidiomer og en tendens til å fokusere på et "spesielt formål." Noen populære NoSQL-databaser (f.eks. MongoDB) skrev flotte databaser og økosystemverktøy som gjorde det veldig enkelt for utviklere å ta i bruk, men konstruerte alvorlige begrensninger i lagringsmotoren - for ikke å nevne begrensninger i motstandsdyktighet og skalerbarhet.
Databasestandarder er fortsatt viktig
Noe av det som gjorde relasjonsdatabaser dominerende var at de hadde et felles økosystem med verktøy. Først var det SQL. Selv om dialekter kan være forskjellige - som utvikler eller analytiker hvis du gikk fra SQL Server 6.5 til Oracle 7, må du kanskje fikse spørsmålene dine og bruke “(+)” for ytre sammenføyninger - men enkle ting fungerte og harde ting var rimelig enkelt å oversette.
For det andre hadde du blant annet ODBC og senere JDBC. Nesten ethvert verktøy som kan koble til en RDBMS (med mindre det ble laget spesielt for å administrere den RDBMS), kunne koble seg til andre RDBMS. Det er mange mennesker som kobler seg til en RDBMS hver dag, og suger dataene inn i Excel for å analysere dem. Jeg refererer ikke til Tableau eller noe av hundrevis av andre verktøy; Jeg snakker om "morsskipet", Excel.
NoSQL gjorde unna standarder. MongoDB bruker ikke SQL som hovedspråk. Da MongoDBs nærmeste konkurrent Couchbase lette etter et spørrespråk for å erstatte deres Java-baserte kartreduserende rammeverk, opprettet de sin egen SQL-dialekt.
Standarder er viktige enten det er å støtte økosystemet til verktøy, eller fordi mange mennesker som spør etter databaser ikke er utviklere - og de kjenner SQL.
GraphQL og fremveksten av statlig ledelse
Du vet hvem som har to tommelen og bare vil at appens tilstand skal komme seg inn i databasen, og bryr seg ikke hvordan? Denne fyren. Og det viser seg at en hel generasjon utviklere. GraphQL - som ikke har noe å gjøre med grafdatabaser - lagrer objektgrafen din i en underliggende datalager. Det frigjør utvikleren fra å bekymre seg for dette problemet.
Et tidligere forsøk på dette var objektrelasjonelle kartleggingsverktøy, eller ORM, som dvalemodus. De tok et objekt og gjorde i utgangspunktet det til SQL basert på et objekt-til-bord-kartoppsett. Mange av de første generasjonene av dette var vanskelige å konfigurere. Videre var vi på en læringskurve.
De fleste GraphQL-implementeringer fungerer med objektrelasjonelle kartleggingsverktøy som Sequelize eller TypeORM. I stedet for å lekker tilstandsadministrasjonsproblemet gjennom hele koden din, vil en godt strukturert GraphQL-implementering og API skrive og returnere relevante data når det skjer endringer i objektgrafen. Hvem, på applikasjonsnivå, bryr seg hvordan dataene lagres, egentlig?
En av grunnene til objektorienterte og NoSQL-databaser var at applikasjonsutvikleren måtte være klar over komplikasjonene i hvordan data lagres i databasen. Naturligvis var dette vanskelig for utviklere å mestre med nyere teknologier, men det er ikke vanskelig lenger. Fordi GraphQL fjerner denne bekymringen helt.
Skriv inn NewSQL eller distribuert SQL
Google hadde et databaseproblem og skrev et papir og senere en implementering kalt "Spanner", som beskrev hvordan en globalt distribuert relationsdatabase ville fungere. Spanner utløste en ny bølge av innovasjon innen relasjonell databaseteknologi. Du kan faktisk ha en relasjonsdatabase og få den til å skalere ikke bare med skjær, men over hele verden hvis nødvendig. Og vi snakker skala i moderne forstand, ikke den ofte skuffende og stadig kompliserte RAC / Streams / GoldenGate-måten.
Så forutsetningen om å "lagre objekter" i et relasjonssystem var feil. Hva om hovedproblemet med relasjonsdatabaser var bakenden og ikke frontenden? Dette er ideen bak såkalte "NewSQL" eller mer riktig "distribuerte SQL" -databaser. Ideen er å kombinere læring av NoSQL-lagring og Googles Spanner-idé med en moden, åpen kildekode, RDBMS-frontend som PostgreSQL eller MySQL / MariaDB.
Hva betyr det? Det betyr at du kan få kaken din og spise den også. Det betyr at du kan ha flere noder og skalere horisontalt - inkludert på tvers av skytilgjengelighetssoner. Det betyr at du kan ha flere datasentre eller geografiske skyområder - med en database. Det betyr at du kan ha ekte pålitelighet, en databaseklynge som aldri går ned for brukerne.
I mellomtiden fungerer hele SQL-økosystemet fortsatt! Du kan gjøre dette uten å gjenoppbygge hele IT-infrastrukturen. Selv om du kanskje ikke er et spill for å "rive og erstatte" din tradisjonelle RDBMS, prøver de fleste selskaper ikke å bruke mer Oracle. Og best av alt, du kan fortsatt bruke SQL og alle verktøyene dine både i skyen og over hele kloden.
