Vanliga funktioner hos NoSQL-dummies

NoSQL böcker och bloggar erbjuder olika åsikter om vad en NoSQL-databas är. Fyra kärnfunktioner i NoSQL, som visas i följande lista, gäller för de flesta NoSQL-databaser. Listan jämför NoSQL med traditionell relationell DBMS:

• Schema agnostic: Ett databasschema är beskrivningen av alla möjliga data och datastrukturer i en relationsdatabas. Med en NoSQL-databas krävs inte ett schema, vilket ger dig friheten att lagra information utan att göra en schemaläggning på framsidan.

• Nonrelational: Relationer i en databas upprätta förbindelser mellan datatabeller. Till exempel kan en lista med transaktionsdetaljer kopplas till en separat lista över leveransdetaljer. Med en NoSQL-databas lagras denna information som ett aggregat - en enda post med allt om transaktionen, inklusive leveransadressen.

• Varuhårdvara: Vissa databaser är utformade för att fungera bäst (eller bara) med specialiserad lagrings- och processhårdvara. Med en NoSQL-databas kan man använda billiga hylla-servrar. Att lägga till fler av dessa billiga servrar gör det möjligt för NoSQL-databaser att skala för att hantera mer data.

• Högfördelningsbar: Distribuerade databaser kan lagra och bearbeta en uppsättning information på mer än en enhet. Med en NoSQL-databas kan ett kluster av servrar användas för att hålla en enda stor databas.

Schema agnostic

NoSQL databaser är schema agnostiska. Du behöver inte göra mycket frontdesign innan du kan lagra data i NoSQL-databaser. Du kan börja kodning och lagra och hämta data utan att veta hur databasen lagrar och fungerar internt. (Om och när du behöver avancerad funktionalitet kan du manuellt lägga till ytterligare index eller tweak datalagringsstrukturer.) Schema agnosticism kan vara den viktigaste skillnaden mellan NoSQL och relationsdatabaser.

Den stora fördelen med en schema agnostisk databas är att utvecklingstiden förkortas. Denna fördel ökar när du går igenom flera utvecklingsutgåvor och behöver ändra de interna datastrukturerna i databasen.

Till exempel, i en traditionell RDBMS, går du igenom en process med schemaläggning. Schemat instruerar databasen om vilken data som ska förväntas. Ändra data som lagrats, eller strukturer, och du måste omstrukturera databasen med ett modifierat schema. Om du skulle göra en förändring, skulle du behöva spendera mycket tid på att bestämma hur du ska bygga om befintliga data. I NoSQL databaser lagrar du helt enkelt en annan datastruktur. Det finns ingen anledning att berätta för databasen på förhand.

Det kan hända att du måste ändra dina frågor i enlighet med detta, kanske lägga till enstaka specifika index (t.ex. ett heltalsindex för att tillåta mindre än och större än specifika frågor för datatypen), men hela processen är mycket mindre smärtsamt än det är med en RDBMS.

RDBMS tog av sig på grund av sin flexibilitet och för att, med hjälp av SQL, det sped upp att ändra en fråga. NoSQL-databaser ger denna flexibilitet för att ändra både schemat och frågan, vilket är en av de viktigaste orsakerna till att de kommer att antas alltmer över tiden.

Även om du är intresserad av en fråga, behöver du inte oroa dig för att veta schemaändringarna. Tänk på ett index över ett fältkontonummer, där kontonummer kan placeras var som helst i ett dokument som lagras i en NoSQL-databas. Du kan ändra strukturen och flytta där kontonummer lagras, och om elementet har samma namn på annat håll i dokumentet, är det fortfarande tillgängligt för fråga utan ändringar i din sökmekanism.

Observera att inte alla NoSQL-databaser är fullständigt schemalagda agnostiska. Vissa, till exempel HBase, kräver att du stoppar databasen för att ändra kolumndefinitioner. De betraktas fortfarande som NoSQL-databaser eftersom inte alla definierade fält (kolumner i det här fallet) krävs för att vara kända i förväg för varje post - bara kolumnfamiljerna.

RDBMS tillåter att enskilda fält i poster identifieras som null -värden. Problemet med en RDBMS är att lagrad datastorlek och prestanda påverkas negativt när lagringen är reserverad för nollvärden bara om posten kan vid en viss framtid ha ett värde i den kolumnen. I Cassandra tillhandahåller du helt enkelt inte den kolonnens data, som löser problemet.

Nonrelational

Relationsdatabashanteringssystem har varit den dominerande sätten att lagra applikationsdata i mer än 20 år. En hel del matematiskt arbete gjordes för att bevisa den teori som ligger till grund för dem.

Detta underlag beskriver hur tabeller relaterar till varandra. En enda ordningsrad kan relatera till många leveransadressrader, men varje leveransadressrad avser också flera orderrader. Detta är en många - till - många relationer .

NoSQL-databaser har inte det här begreppet relationer mellan sina poster. De deformaliserar istället data. Det betyder att i en NoSQL-databas skulle ha en orderstruktur med leveransadressen inbäddad. Det betyder att leveransadressen dupliceras i varje Ordningsrad som använder den. Detta tillvägagångssätt har fördelen att det inte krävs komplexa frågetider på flera datastrukturer (tabeller).

NoSQL-databaser lagrar inte information om hur enskilda poster relaterar till andra poster i databasen, vilket kan låta som en begränsning. NoSQL-databaser är dock mer flexibla när det gäller datastrukturerna du kan lagra.

Överväg en order från en online-återförsäljare. Ordern kan innehålla produktkoder, kvantiteter, varupriser och produktbeskrivningar, samt information om beställningen av person, såsom leveransadress och betalningsinformation.

Istället för att lägga in tio rader i en rad olika tabeller i en relationsdatabas kan du istället lagra en enda struktur för all denna orderinformation - säg som ett JSON- eller XML-dokument.

I relationell databasteori är målet att normalisera dina data (det vill säga att organisera fälten och tabellerna för att ta bort dubbla data). I NoSQL-databaser - i synnerhet dokument eller aggregatdatabaser - deformaliseras du medvetet data, lagrar data flera gånger.

Du kan exempelvis lagra "Kundleveransadress" flera gånger över många beställningar en kund gör över tiden, istället för att lagra den en gång och hänvisa till den i flera beställningar. Att göra det kräver extra lagringsutrymme, och lite förtänkt att hantera i din ansökan. Så varför gör det?

Det finns två fördelar med att lagra data flera gånger:

• Enkel lagring och hämtning: Spara bara och skaffa en enskild post.

• Sökhastighet: I relationsdatabaser sammanfogar du information och lägger till begränsningar över tabeller vid förfrågningstid. Detta kan kräva att databasmotorn utvärderar många tabeller. Ju fler frågeställningar du har på olika tabeller, desto mer minskar du sökfrågan. (Det är därför en RDBMS har precomputed visningar.) I en NoSQL-databas är all information du behöver för att utvärdera din fråga i ett enda dokument. Därför kan du snabbt bestämma listan över matchande dokument.

Relationsvyer och NoSQL-denormaliseringar är olika metoder för problem med dataspridning över poster. I NoSQL kan du behöva behålla flera deformaliseringar som representerar olika synpunkter på samma data. Detta tillvägagångssätt ökar kostnaderna för lagring men ger dig mycket bättre frågestundstid.

Med tanke på den ständigt minskade kostnaden för lagring och den ökade hastigheten på utveckling och förfrågan är denormaliserade data (aka materialiserade visningar ) inte en dödlig anledning att rabatt NoSQL-lösningar. Det är bara ett annat sätt att närma sig samma problem, med sina egna fördelar och nackdelar.

NoSQL är mycket fördelningsbar och använder råvaruhårdvara

I många NoSQL-databaser är ett nyckeldesignbeslut att använda flera datorer för att lagra data för en enda databas, istället för att ha hela databasen på en enda server.

Det är svårt att lagra data över flera maskiner och låta den bli frågad. Du måste skicka frågan till alla servrar och vänta på ett svar. Förhoppningsvis ställer du upp maskinerna så att de är tillräckligt snabba för att prata med varandra för att hantera distribuerade frågor!

Den största fördelen med detta tillvägagångssätt är vid mycket stora dataset, eftersom det för vissa lagringsbehov inte ens kunde vara den största tillgängliga enskilda servern att lagra eller bearbeta all data du behöver. Tänk på alla meddelanden på Twitter och Facebook. Du behöver en distribuerad mekanism för att effektivt hantera all den data, även om det mest handlar om vad folk hade för frukost och söta kattvideor.

En fördel med att distribuera din databas är att du kan använda billigare servrar, kallade varuservrar .Även för mindre dataset kan det vara billigare att köpa tre råvareservrar istället för en enda högre server.

En annan viktig fördel är att lägga till hög tillgänglighet är lättare; Du är redan halvvägs där genom att distribuera dina data. Om du kopierar dina data en eller två gånger över andra servrar i klustret kommer dina data fortfarande att vara tillgängliga, även om en av servrarna kraschar, bränner och dör.

Inte alla öppna källdatabaser stöder hög tillgänglighet om du inte köper den stödda, betalda versionen av databasen från företaget som utvecklar det.

Ett undantag till den högutdelningsbara regeln är den för grafdatabaser. För att effektivt kunna svara på vissa graffrågor i tid måste data lagras på en enda server. Ingen har löst det här problemet ännu.

Tänk noggrant om du behöver en trippelbutik eller en grafaffär. Trippelaffärer är i allmänhet utdelbara, medan grafaffärer inte är. Vilken du behöver beror på de frågor du måste stödja.