Vad är NoSQL? Databaser för en molnskala framtid

Ett av de mest grundläggande valen att göra när man utvecklar en applikation är om man ska använda en SQL- eller NoSQL-databas för att lagra data. Konventionella SQL-databaser (dvs. relationella) databaser är en produkt av decennier av teknikutveckling, god praxis och stresstestning i verkligheten. De är utformade för pålitliga transaktioner och ad hoc-frågor, häftklamrarna för affärsapplikationer. Men de är också belastade med restriktioner - som ett styvt schema - som gör dem mindre lämpliga för andra typer av appar.

NoSQL-databaser uppstod som svar på dessa begränsningar. NoSQL-system lagrar och hanterar data på sätt som möjliggör hög operativ hastighet och stor flexibilitet hos utvecklarna. Många utvecklades av företag som Google, Amazon, Yahoo och Facebook som sökte bättre sätt att lagra innehåll eller bearbeta data för massiva webbplatser. Till skillnad från SQL-databaser kan många NoSQL-databaser skalas horisontellt över hundratals eller tusentals servrar.

Fördelarna med NoSQL kommer dock inte utan kostnad. NoSQL-system ger vanligtvis inte samma nivå av datakonsistens som SQL-databaser. I själva verket, även om SQL-databaser traditionellt har offrat prestanda och skalbarhet för ACID-egenskaperna bakom tillförlitliga transaktioner, har NoSQL-databaser till stor del avskaffat dessa ACID-garantier för hastighet och skalbarhet.

Kort sagt, SQL- och NoSQL-databaser erbjuder olika avvägningar. Även om de kan tävla inom ramen för ett specifikt projekt - som i, att välja för den här applikationen eller den applikationen - är de kompletterande i den större bilden. Var och en är lämplig för olika användningsfall. Beslutet handlar inte så mycket om antingen / eller eftersom det är en fråga om vilket verktyg som är rätt för jobbet.

NoSQL kontra SQL

Den grundläggande skillnaden mellan SQL och NoSQL är inte så komplicerad. Var och en har en annan filosofi för hur data ska lagras och hämtas.

Med SQL-databaser har all data en inneboende struktur. En konventionell databas som Microsoft SQL Server, MySQL eller Oracle Database använder ett schema - en formell definition av hur data som sätts in i databasen kommer att komponeras. Till exempel kan en viss kolumn i en tabell begränsas till endast heltal. Som ett resultat kommer de data som registreras i kolumnen att ha en hög grad av normalisering. En SQL-databas styva schema gör det också relativt enkelt att utföra aggregeringar på data, till exempel genom JOINs.

Med NoSQL kan data lagras på ett schemalöst eller fritt format. Alla data kan lagras i vilken post som helst. Bland NoSQL-databaserna hittar du fyra vanliga modeller för lagring av data, vilket leder till fyra vanliga typer av NoSQL-system:

  1. Dokumentdatabaser (t.ex. CouchDB, MongoDB). Insatta data lagras i form av friformade JSON-strukturer eller ”dokument”, där data kan vara allt från heltal till strängar till friformstext. Det finns inget inneboende behov av att ange vilka fält, om några, ett dokument kommer att innehålla.
  2. Viktiga butiker (t.ex. Redis, Riak). Friformsvärden - från enkla heltal eller strängar till komplexa JSON-dokument - nås i databasen med hjälp av nycklar.
  3. Breda kolumnbutiker (t.ex. HBase, Cassandra). Data lagras i kolumner istället för rader som i ett konventionellt SQL-system. Valfritt antal kolumner (och därför många olika typer av data) kan grupperas eller sammanställas efter behov för frågor eller datavyer.
  4. Grafdatabaser (t.ex. Neo4j). Data representeras som ett nätverk eller diagram över enheter och deras förhållanden, med varje nod i diagrammet en fritt form bit av data.

Schemalös datalagring är användbar i följande scenarier:

  1. Du vill ha snabb åtkomst till data, och du är mer intresserad av snabbhet och enkel åtkomst än pålitliga transaktioner eller konsekvens.
  2. Du lagrar en stor datamängd och du vill inte låsa dig in i ett schema, eftersom det kan vara långsamt och smärtsamt att ändra schemat senare.
  3. Du tar in ostrukturerad data från en eller flera källor som producerar den och du vill behålla informationen i sin ursprungliga form för maximal flexibilitet.
  4. Du vill lagra data i en hierarkisk struktur, men du vill att dessa hierarkier ska beskrivas av själva data, inte ett externt schema. NoSQL tillåter data att vara avslappnad självreferens på sätt som är mer komplexa för SQL-databaser att emulera.

Fråga efter NoSQL-databaser

Structured Query Language som används av traditionella databaser ger ett enhetligt sätt att kommunicera med servern när man lagrar och hämtar data. SQL-syntax är mycket standardiserad, så även om enskilda databaser kan hantera vissa operationer på olika sätt (t.ex. fönsterfunktioner), förblir grunderna desamma.

Däremot tenderar varje NoSQL-databas att ha sin egen syntax för att fråga och hantera data. CouchDB använder till exempel förfrågningar i form av JSON, skickade via HTTP, för att skapa eller hämta dokument från sin databas. MongoDB skickar JSON-objekt över ett binärt protokoll, via ett kommandoradsgränssnitt eller ett språkbibliotek.

Vissa NoSQL-produkter kan använda SQL-liknande syntax för att arbeta med data, men bara i begränsad omfattning. Till exempel har Apache Cassandra, en kolumnbutikdatabas, sitt eget SQL-liknande språk, Cassandra Query Language eller CQL. En del av CQL-syntaxen är direkt ur SQL-spelboken, som SELECT- eller INSERT-nyckelorden. Men det finns inget sätt att utföra en JOIN eller underfråga i Cassandra, och därmed finns de relaterade nyckelorden inte i CQL.

Delad-ingenting arkitektur

Ett designval som är gemensamt för NoSQL-system är en "shared-nothing" -arkitektur. I en design med delad ingenting fungerar varje servernod i klustret oberoende av alla andra noder. Systemet behöver inte få konsensus från varje nod för att returnera en bit data till en klient. Frågor är snabba eftersom de kan returneras från vilken nod som helst eller närmast.

En annan fördel med delad ingenting är flexibilitet och utskalning. Att skala ut klustret är lika enkelt som att snurra upp nya noder i klustret och vänta på att de ska synkroniseras med de andra. Om en NoSQL-nod går ner kommer de andra servrarna i klustret att fortsätta chugge med. All data förblir tillgänglig, även om färre noder är tillgängliga för att betjäna förfrågningar.

Observera att en delad-ingenting-design inte är exklusiv för NoSQL-databaser. Många konventionella SQL-system kan ställas in på ett delat-ingenting-sätt, även om det vanligtvis innebär att offra konsekvens över hela klustret för prestanda.

NoSQL-begränsningar

Om NoSQL ger så mycket frihet och flexibilitet, varför inte överge SQL helt? Det enkla svaret: Många applikationer kräver fortfarande de slags begränsningar, konsistens och skydd som SQL-databaser tillhandahåller. I sådana fall kan vissa "fördelar" med NoSQL vända sig till nackdelar. Andra begränsningar härrör från det faktum att NoSQL-system är relativt nya. 

Inget schema

Även om du tar in data i fri form behöver du nästan alltid införa begränsningar för att göra det användbart. Med NoSQL innebär införandet av begränsningar att ansvaret flyttas från databasen till applikationsutvecklaren. Till exempel kan utvecklaren införa struktur genom ett objektrelationskartläggningssystem eller ORM. Men om du vill att schemat ska leva med själva data , gör NoSQL vanligtvis inte det.

Vissa NoSQL-lösningar tillhandahåller valfri datatypning och valideringsmekanismer för data. Apache Cassandra har till exempel en massa inbyggda datatyper som påminner om de som finns i konventionell SQL.

Eventuell konsistens

NoSQL-system byter stark eller omedelbar konsistens för bättre tillgänglighet och prestanda. Konventionella databaser säkerställer att operationerna är atomära (alla delar av en transaktion lyckas eller ingen gör det), konsekventa (alla användare har samma syn på data), isolerade (transaktioner tävlar inte) och hållbara (när de är klara kommer de att överleva ett serverfel).

Dessa fyra egenskaper, gemensamt benämnda ACID, hanteras olika i de flesta NoSQL-system. Istället för omedelbar konsistens över klustret har du slutligen konsekvens på grund av den tid som krävs för att kopiera uppdateringar till andra noder i klustret. Data som sätts in i klustret är så småningom tillgängliga överallt, men du kan inte garantera när.

Transaktionssemantik, som i ett SQL-system garanterar att alla steg i en transaktion (t.ex. att utföra en försäljning och minska lager) antingen är slutförda eller rullade tillbaka, är vanligtvis inte tillgängliga i NoSQL. För alla system där det måste finnas en "enda källa till sanning", till exempel en bank, fungerar NoSQL-metoden inte bra. Du vill inte att ditt banksaldo ska vara annorlunda beroende på vilken bankomat du går till; du vill att det ska rapporteras som samma sak överallt.

Vissa NoSQL-databaser har partiella mekanismer för att kringgå detta. MongoDB har till exempel konsekvensgarantier för enskilda operationer, men inte för databasen som helhet. Microsoft Azure CosmosDB låter dig välja en konsistensnivå per begäran, så att du kan välja det beteende som passar ditt användningsfall. Men med NoSQL, förvänta dig eventuell konsistens som standardbeteende.

NoSQL-låsning

De flesta NoSQL-system är begreppsmässigt lika, men implementeras väldigt annorlunda. Var och en tenderar att ha sina egna metaforer och mekanismer för hur data ifrågasätts och hanteras.

En bieffekt av detta är en potentiellt hög grad av koppling mellan applikationslogiken och databasen. Det här är inte så dåligt om du väljer ett NoSQL-system och håller fast vid det, men det kan bli en stötesten om du byter system på vägen.

Om du migrerar från, till exempel, MongoDB till CouchDB (eller vice versa), måste du göra mer än bara migrera data. Du måste också navigera i skillnaderna i datatillgång och programmatiska metaforer - med andra ord måste du skriva om de delar av din applikation som får åtkomst till databasen.

NoSQL färdigheter

En annan nackdel med NoSQL är den relativa bristen på expertis. Där marknaden för konventionell SQL-talang fortfarande är ganska stor är marknaden för NoSQL-färdigheter växande.

Som referens rapporterar Indeed.com att vid slutet av 2017 förblir volymen jobbannonser för konventionella SQL-databaser - MySQL, Microsoft SQL Server, Oracle Database och så vidare - högre under de senaste tre åren än volymen jobb. för MongoDB, Couchbase och Cassandra. Efterfrågan på NoSQL-expertis växer, men det är fortfarande en bråkdel av marknaden för konventionell SQL.

Sammanfoga SQL och NoSQL

Vi kan förvänta oss att några av skillnaderna mellan SQL- och NoSQL-system försvinner med tiden. Redan många SQL-databaser accepterar nu JSON-dokument som en inbyggd datatyp och kan utföra frågor mot den informationen. Vissa har till och med infödda sätt att införa begränsningar för JSON-data, så att de hanteras med samma svårigheter som konventionella rad- och kolumndata.

På baksidan lägger NoSQL-databaser inte bara till SQL-liknande frågespråk utan också andra funktioner i traditionella SQL-databaser. Till exempel lovar minst två dokumentdatabaser - MarkLogic och RavenDB - att vara ACID-kompatibla.

Här och där finns tecken på att kommande generationer av databaser kommer att sträcka sig över paradigmerna och erbjuda både NoSQL- och SQL-funktionalitet. Microsofts Azure Cosmos DB, till exempel, använder en uppsättning primitiva under huven för att utbytbart reproducera beteenden hos båda typerna av system. Google Cloud Spanner är en SQL-databas som kombinerar stark konsistens med den horisontella skalbarheten hos NoSQL-system.

Fortfarande kommer rena SQL och rena NoSQL-system att ha sin plats under många år framöver. Se till NoSQL för snabb, mycket skalbar åtkomst till data i fri form. Detta kommer med några kostnader, som konsistens av läsningar och andra skydd som är gemensamma för SQL-databaser. Men för många applikationer kan dessa skydd verkligen vara värda att handla för vad NoSQL erbjuder.