Et af de mest grundlæggende valg, der skal træffes, når man udvikler en applikation, er, om man skal bruge en SQL- eller NoSQL-database til at gemme dataene. Konventionelle SQL (dvs. relationelle) databaser er produktet af årtier med teknologiudvikling, god praksis og stresstest i den virkelige verden. De er designet til pålidelige transaktioner og ad hoc-forespørgsler, hæfteklammerne til forretningsapplikationer. Men de er også belastet med begrænsninger - såsom stift skema - der gør dem mindre egnede til andre slags apps.
NoSQL-databaser opstod som svar på disse begrænsninger. NoSQL-systemer lagrer og administrerer data på måder, der giver mulighed for høj driftshastighed og stor fleksibilitet hos udviklerne. Mange blev udviklet af virksomheder som Google, Amazon, Yahoo og Facebook, der søgte bedre måder at gemme indhold eller behandle data til massive websteder. I modsætning til SQL-databaser kan mange NoSQL-databaser skaleres vandret på tværs af hundreder eller tusinder af servere.
Fordelene ved NoSQL kommer dog ikke uden omkostninger. NoSQL-systemer leverer generelt ikke det samme niveau af datakonsistens som SQL-databaser. Faktisk, mens SQL-databaser traditionelt har ofret ydeevne og skalerbarhed for ACID-egenskaberne bag pålidelige transaktioner, har NoSQL-databaser stort set fjernet disse ACID-garantier for hastighed og skalerbarhed.
Kort sagt, SQL- og NoSQL-databaser tilbyder forskellige kompromiser. Mens de måske konkurrerer i sammenhæng med et bestemt projekt - som i, at vælge det her ansøgning eller at anvendelse - de er komplementære i det større billede. Hver er velegnet til forskellige brugssager. Beslutningen er ikke så meget et tilfælde af enten / eller som det er et spørgsmål om, hvilket værktøj der passer til jobbet.
NoSQL vs. SQL
Den grundlæggende forskel mellem SQL og NoSQL er ikke så kompliceret. Hver har en anden filosofi for, hvordan data skal lagres og hentes.
Med SQL-databaser har alle data en iboende struktur. En konventionel database som Microsoft SQL Server, MySQL eller Oracle Database bruger en skema—En formel definition af, hvordan data indsat i databasen vil blive sammensat. For eksempel kan en given kolonne i en tabel kun være begrænset til heltal. Som et resultat vil de data, der er optaget i kolonnen, have en høj grad af normalisering. En SQL-databases stive skema gør det også relativt let at udføre aggregeringer på dataene, for eksempel ved hjælp af JOINs.
Med NoSQL kan data gemmes skematisk eller i fri form. Alle data kan gemmes i enhver post. Blandt NoSQL-databaser finder du fire almindelige modeller til lagring af data, hvilket fører til fire almindelige typer NoSQL-systemer:
- Dokumentdatabaser (f.eks. CouchDB, MongoDB). Indsatte data gemmes i form af friformede JSON-strukturer eller "dokumenter", hvor dataene kan være alt fra heltal til strenge til friformet tekst. Der er ikke noget iboende behov for at specificere, hvilke felter et dokument vil indeholde.
- Nøgleværdibutikker (fx Redis, Riak). Friformværdier - fra enkle heltal eller strenge til komplekse JSON-dokumenter - fås i databasen ved hjælp af nøgler.
- Brede søjleforretninger (fx HBase, Cassandra). Data lagres i kolonner i stedet for rækker som i et konventionelt SQL-system. Ethvert antal kolonner (og derfor mange forskellige datatyper) kan grupperes eller aggregeres efter behov til forespørgsler eller datavisninger.
- Grafdatabaser (fx Neo4j). Data er repræsenteret som et netværk eller en graf over enheder og deres forhold, hvor hver node i grafen er en del af data i fri form.
Skemafri datalagring er nyttig i følgende scenarier:
- Du vil have hurtig adgang til dataene, og du er mere bekymret over hastighed og enkelhed i adgang end pålidelige transaktioner eller konsistens.
- Du gemmer en stor mængde data, og du vil ikke låse dig selv ind i et skema, da ændring af skemaet senere kan være langsomt og smertefuldt.
- Du modtager ustrukturerede data fra en eller flere kilder, der producerer dem, og du vil beholde dataene i deres oprindelige form for maksimal fleksibilitet.
- Du vil gemme data i en hierarkisk struktur, men du vil have, at disse hierarkier skal beskrives af selve dataene, ikke et eksternt skema. NoSQL gør det muligt for data at være tilfældigt selvhenvisende på måder, der er mere komplekse for SQL-databaser at efterligne.
Forespørgsel på NoSQL-databaser
Det strukturerede forespørgselssprog, der bruges af traditionelle databaser, giver en ensartet måde at kommunikere med serveren, når de lagrer og henter data. SQL-syntaks er meget standardiseret, så selvom individuelle databaser kan håndtere bestemte operationer forskelligt (f.eks. Vinduesfunktioner), forbliver det grundlæggende det samme.
Derimod har hver NoSQL-database tendens til at have sin egen syntaks til forespørgsel og styring af dataene. CouchDB bruger for eksempel anmodninger i form af JSON, sendt via HTTP, til at oprette eller hente dokumenter fra sin database. MongoDB sender JSON-objekter over en binær protokol ved hjælp af en kommandolinjegrænseflade eller et sprogbibliotek.
Nogle NoSQL-produkter kan bruge SQL-lignende syntaks til at arbejde med data, men kun i begrænset omfang. For eksempel har Apache Cassandra, en kolonnebutikdatabase, sit eget SQL-lignende sprog, Cassandra Query Language eller CQL. Nogle af CQL-syntaksen er lige ud af SQL-playbogen, ligesom SELECT- eller INSERT-nøgleordene. Men der er ingen måde at udføre en JOIN eller underforespørgsel i Cassandra, og de relaterede nøgleord findes derfor ikke i CQL.
Delt intet arkitektur
Et designvalg, der er fælles for NoSQL-systemer, er en "delt intet" -arkitektur. I et delt-intet design fungerer hver serverknude i klyngen uafhængigt af hver anden knude. Systemet behøver ikke at få konsensus fra hver enkelt node for at returnere et stykke data til en klient. Forespørgsler er hurtige, fordi de kan returneres fra den node, der er tættest eller mest bekvem.
En anden fordel ved delt intet er fleksibilitet og udskalering. Skalering af klyngen er lige så let som at spinde nye noder i klyngen og vente på, at de synkroniseres med de andre. Hvis en NoSQL-node går ned, vil de andre servere i klyngen fortsætte med at chugge sammen. Alle data forbliver tilgængelige, selvom der er færre noder tilgængelige til at betjene anmodninger.
Bemærk, at et delt-intet design ikke er eksklusiv til NoSQL-databaser. Mange konventionelle SQL-systemer kan indstilles på en delt-intet måde, selvom det typisk indebærer at ofre konsistens på tværs af klyngen for ydeevne.
NoSQL begrænsninger
Hvis NoSQL giver så meget frihed og fleksibilitet, hvorfor så ikke opgive SQL helt? Det enkle svar: Mange applikationer kræver stadig den slags begrænsninger, konsistens og garantier, som SQL-databaser giver. I disse tilfælde kan nogle “fordele” ved NoSQL blive til ulemper. Andre begrænsninger skyldes, at NoSQL-systemer er relativt nye.
Intet skema
Selvom du tager data i fri form, skal du næsten altid pålægge dem begrænsninger for at gøre det nyttigt. Med NoSQL indebærer indførelse af begrænsninger at flytte ansvaret fra databasen til applikationsudvikleren. For eksempel kunne udvikleren pålægge struktur gennem et objektrelationskortlægningssystem eller ORM. Men hvis du vil have skemaet til at leve med selve dataene, NoSQL gør det typisk ikke.
Nogle NoSQL-løsninger leverer valgfri datatypning og valideringsmekanismer til data. Apache Cassandra har for eksempel en række indfødte datatyper, der minder om dem, der findes i konventionel SQL.
Eventuel konsistens
NoSQL-systemer handler stærk eller øjeblikkelig konsistens for bedre tilgængelighed og ydeevne. Konventionelle databaser sikrer, at operationer er atomar (alle dele af en transaktion lykkes, eller ingen gør), konsekvent (alle brugere har samme visning af dataene), isoleret (transaktioner konkurrerer ikke), og holdbar (når de er færdige, vil de overleve en serverfejl).
Disse fire egenskaber, samlet kaldet ACID, håndteres forskelligt i de fleste NoSQL-systemer. I stedet for øjeblikkelig konsistens på tværs af klyngen har du det eventuelt konsistens på grund af den nødvendige tid til at kopiere opdateringer til andre noder i klyngen. Data indsat i klyngen er til sidst tilgængelige overalt, men du kan ikke garantere hvornår.
Transaktionssemantik, som i et SQL-system garanterer, at alle trin i en transaktion (f.eks. Udførelse af et salg og reducerende beholdning) er enten afsluttet eller rullet tilbage, er ikke typisk tilgængelige i NoSQL. For ethvert system, hvor der skal være en "enkelt kilde til sandhed", såsom en bank, fungerer NoSQL-metoden ikke godt. Du ønsker ikke, at din banksaldo skal være forskellig, afhængigt af hvilken pengeautomat, du går til; du vil have det rapporteret som det samme overalt.
Nogle NoSQL-databaser har delvise mekanismer til at omgå dette. For eksempel har MongoDB konsistensgarantier for individuelle operationer, men ikke for databasen som helhed. Microsoft Azure CosmosDB giver dig mulighed for at vælge et niveau af konsistens pr. Anmodning, så du kan vælge den adfærd, der passer til din brugssag. Men med NoSQL, forvent eventuel konsistens som standardadfærd.
NoSQL-låsning
De fleste NoSQL-systemer er konceptuelt ligner, men er implementeret meget anderledes. Hver har tendens til at have sine egne metaforer og mekanismer til, hvordan data spørges og styres.
En bivirkning af dette er en potentielt høj grad af kobling mellem applikationslogikken og databasen. Dette er ikke så slemt, hvis du vælger et NoSQL-system og holder fast ved det, men det kan blive en snublesten, hvis du skifter system nede ad vejen.
Hvis du migrerer fra f.eks. MongoDB til CouchDB (eller omvendt), skal du gøre mere end bare at migrere data. Du skal også navigere i forskellene i dataadgang og programmatiske metaforer - med andre ord skal du omskrive de dele af din applikation, der får adgang til databasen.
NoSQL færdigheder
En anden ulempe ved NoSQL er den relative mangel på ekspertise. Hvor markedet for konventionelt SQL-talent stadig er ret stort, er markedet for NoSQL-færdigheder begyndende.
Som reference rapporterer Indeed.com, at ved udgangen af 2017 forbliver mængden af joblister for konventionelle SQL-databaser - MySQL, Microsoft SQL Server, Oracle Database osv. - højere i de sidste tre år end mængden af job. til MongoDB, Couchbase og Cassandra. Efterspørgslen efter NoSQL-ekspertise vokser, men det er stadig en brøkdel af markedet for konventionel SQL.
Fletning af SQL og NoSQL
Vi kan forvente, at nogle af forskellene mellem SQL- og NoSQL-systemer forsvinder over tid. Allerede i mange SQL-databaser accepteres nu JSON-dokumenter som en indfødt datatype og kan udføre forespørgsler mod disse data. Nogle har endda indfødte måder at pålægge JSON-data begrænsninger på, så de håndteres med de samme vanskeligheder som konventionelle række- og kolonnedata.
På bagsiden tilføjer NoSQL-databaser ikke kun SQL-lignende forespørgselssprog, men andre funktioner i traditionelle SQL-databaser. For eksempel lover mindst to dokumentdatabaser - MarkLogic og RavenDB - at være ACID-kompatible.
Her og der er tegn på, at fremtidige generationer af databaser vil strække paradigmerne og tilbyde både NoSQL- og SQL-funktionalitet. Microsofts Azure Cosmos DB bruger for eksempel et sæt primitiver under emhætten til ombytteligt at gengive adfærd fra begge slags systemer. Google Cloud Spanner er en SQL-database, der kombinerer stærk konsistens med den vandrette skalerbarhed af NoSQL-systemer.
Alligevel vil rene SQL og rene NoSQL-systemer have deres plads i mange år fremover. Se til NoSQL for hurtig, meget skalerbar adgang til data i fri form. Dette kommer med et par omkostninger, som konsistens af læsninger og andre sikkerhedsforanstaltninger, der er fælles for SQL-databaser. Men for mange applikationer kan disse sikkerhedsforanstaltninger meget vel være værd at handle for, hvad NoSQL tilbyder.
