Fælles funktioner i NoSQL - dummies

NoSQL bøger og blogs tilbyder forskellige meninger om, hvad en NoSQL database er. Fire grundlæggende funktioner i NoSQL, der vises i den følgende liste, gælder for de fleste NoSQL-databaser. Listen sammenligner NoSQL med traditionelle relationelle DBMS:

• Schema agnostic: Et databaseskema er beskrivelsen af ​​alle mulige data og datastrukturer i en relationsdatabase. Med en NoSQL-database er et skema ikke påkrævet, hvilket giver dig frihed til at gemme information uden at lave opadgående skema-design.

• Ikke-relational: Relationer i en database etablerer forbindelser mellem data-tabeller. For eksempel kan en liste over transaktionsoplysninger forbindes til en separat liste over leveringsoplysninger. Med en NoSQL-database gemmes disse oplysninger som et aggregat - en enkelt post med alt om transaktionen, herunder leveringsadressen.

• Commodity hardware: Nogle databaser er designet til at fungere bedst (eller kun) med specialiseret lagrings- og proceshardware. Med en NoSQL-database kan der anvendes billige hylde-servere. Tilføjelse af flere af disse billige servere gør det muligt for NoSQL-databaser at skalere til at håndtere flere data.

• Kan distribueres: Distribuerede databaser kan gemme og behandle et sæt informationer på mere end en enhed. Med en NoSQL database kan en klynge af servere bruges til at holde en enkelt stor database.

Schema agnostic

NoSQL databaser er schema agnostic. Du er ikke forpligtet til at lave en masse front-front design arbejde, før du kan gemme data i NoSQL databaser. Du kan starte kodning og gemme og hente data uden at vide, hvordan databasen opbevarer og arbejder internt. (Hvis og når du har brug for avanceret funktionalitet, kan du manuelt tilføje yderligere indekser eller justere datalagringsstrukturer.) Schema agnosticisme kan være den væsentligste forskel mellem NoSQL og relationsdatabaser.

Den store fordel ved en schema agnostisk database er, at udviklingstiden er forkortet. Denne fordel øges, når du går gennem flere udviklingsudgivelser og skal ændre de interne datastrukturer i databasen.

I en traditionel RDBMS, for eksempel, går du igennem en proces med skema-redesign. Skemaet instruerer databasen om, hvilke data der skal forventes. Skift de lagrede data eller strukturer, og du skal genopbygge databasen ved hjælp af et ændret skema. Hvis du skulle foretage en forandring, skal du bruge meget tid på at bestemme, hvordan du re-arkiverer de eksisterende data. I NoSQL databaser gemmer du simpelthen en anden datastruktur. Der er ikke behov for at fortælle databasen på forhånd.

Du skal muligvis ændre dine forespørgsler i overensstemmelse hermed, måske tilføj det lejlighedsvise specifikke indeks (f.eks. Et heltalsindeks for at tillade mindre end og større end datatype specifikke forespørgsler), men hele processen er meget mindre smertefuldt end det er med en RDBMS.

RDBMS tog afsted på grund af sin fleksibilitet, og fordi den ved at bruge SQL, spedte op med at ændre en forespørgsel. NoSQL databaser giver denne fleksibilitet til at ændre både skemaet og forespørgslen, hvilket er en af ​​hovedårsagerne til, at de i stigende grad vil blive vedtaget over tid.

Selv ved forespørgsel behøver du ikke at bekymre dig for meget om at kende skemaændringer. Overvej et indeks over et feltkontonummer, hvor Kontonummer kan placeres hvor som helst i et dokument, der er gemt i en NoSQL database. Du kan ændre strukturen og flytte hvor kontonummer er gemt, og hvis elementet har samme navn andetsteds i dokumentet, er det stadig tilgængeligt for forespørgsel uden ændringer i din forespørgselsmekanisme.

Bemærk at ikke alle NoSQL-databaser er fuldt schema-agnostiske. Nogle, som f.eks. HBase, kræver, at du stopper databasen for at ændre kolonnedefinitioner. De betragtes stadig som NoSQL databaser, fordi ikke alle definerede felter (kolonner i dette tilfælde) skal være kendt på forhånd for hver post - bare kolonnefamilierne.

RDBMS gør det muligt at identificere individuelle felter i poster som null værdier. Problemet med en RDBMS er, at lagret datastørrelse og ydeevne påvirkes negativt, når lagringen er reserveret til nullværdier, bare hvis posten på et senere tidspunkt kan have en værdi i den kolonne. I Cassandra giver du simpelthen ikke kolonnenes data, som løser problemet.

Ikke-relational

Relationelle databasestyringssystemer har været den dominerende måde at lagre applikationsdata på i mere end 20 år. En stor del matematisk arbejde blev gjort for at bevise den teori, der understøtter dem.

Dette underlag beskriver, hvordan tabeller relaterer til hinanden. En enkelt Ordre række kan vedrøre mange Leveringsadresse rækker, men hver Leveringsadresse række vedrører også flere Ordre rækker. Dette er en mange - til - mange forhold .

NoSQL databaser har ikke dette koncept af forhold mellem deres optegnelser. De deformaliserer i stedet data. Dette betyder, at i en NoSQL database ville have en Ordre struktur med leveringsadresse indlejret. Det betyder, at leveringsadressen er dupliceret i hver ordre række, der bruger den. Denne fremgangsmåde har den fordel, at det ikke kræver komplekse forespørgsels tid på tværs af flere datastrukturer (tabeller).

NoSQL-databaser lagrer ikke oplysninger om, hvordan individuelle poster vedrører andre poster i databasen, hvilket måske lyder som en begrænsning. NoSQL databaser er dog mere fleksible med hensyn til de datastrukturer, du kan gemme.

Overvej en ordre fra en onlineforhandler. Ordren kan indeholde produktkoder, mængder, varepriser og varebeskrivelser samt oplysninger om den person, der bestiller, såsom leveringsadresse og betalingsoplysninger.

I stedet for at indsætte ti rækker i en række forskellige tabeller i en relationsdatabase, kan du i stedet gemme en enkelt struktur for alle disse ordreoplysninger - sig som et JSON- eller XML-dokument.

I relationskatalogteori er målet at normalisere dine data (det vil sige at organisere felterne og tabellerne for at fjerne dubletter). I NoSQL-databaser - specielt Dokument eller Aggregate-databaser - formår du ofte bevidst data og lagrer nogle data flere gange.

Du kan f.eks. Gemme "Customer Delivery Address" flere gange på tværs af mange ordrer, som en kunde laver over tid, snarere end at gemme den en gang og henvise til den i flere ordrer. Det kræver ekstra opbevaringsplads, og lidt forankring i håndtering i din ansøgning. Så hvorfor gør det?

Der er to fordele ved lagring af data flere gange:

• Nem opbevaring og hentning: Gem bare og hent en enkelt post.

• Forespørgselshastighed: I relationelle databaser deltager du i oplysninger og tilføjer begrænsninger på tværs af tabeller på forespørgsels tid. Dette kan kræve, at databasemotoren vurderer mange tabeller. Jo flere forespørgselsbegrænsninger du har på tværs af forskellige tabeller, desto mere reducerer du forespørgselshastigheden. (Derfor har en RDBMS foruddrevne visninger.) I en NoSQL-database er al den information, du har brug for til at evaluere din forespørgsel, i et enkelt dokument. Derfor kan du hurtigt bestemme listen over matchende dokumenter.

Relational visninger og NoSQL denormalizations er forskellige tilgange til problemet med dataspredning på tværs af poster. I NoSQL må du muligvis opretholde flere deformaliseringer, der repræsenterer forskellige visninger af de samme data. Denne tilgang øger omkostningerne ved opbevaring, men giver dig meget bedre forespørgselstid.

I betragtning af de stadigt reducerende omkostninger ved opbevaring og den øgede hastighed på udvikling og forespørgsel er denormaliserede data (aka materialiserede visninger ) ikke en killer grund til at rabat NoSQL-løsninger. Det er bare en anden måde at nærme sig det samme problem med sine egne fordele og ulemper.

NoSQL er meget distribueret og bruger råvarehardware

I mange NoSQL-databaser er en nøgleudformningsbeslutning at bruge flere computere til at gemme data for en enkelt database, snarere end at have hele databasen på en enkelt server.

Det er svært at gemme data på tværs af flere maskiner og give det mulighed for at blive forespurgt. Du skal sende forespørgslen til alle servere og vente på et svar. Forhåbentlig sætter du maskinerne op, så de er hurtige nok til at snakke med hinanden for at håndtere distribuerede forespørgsler!

Den største fordel ved denne tilgang er i tilfælde af meget store datasæt, fordi for nogle lagerkrav, kunne selv den største tilgængelige enkeltserver ikke lagre eller behandle alle de data, du har brug for. Overvej alle meddelelser på Twitter og Facebook. Du har brug for en distribueret mekanisme til effektivt at håndtere alle disse data, selv om det for det meste handler om, hvad folk havde til morgenmad og søde kat videoer.

En fordel ved at distribuere din database er, at du kan bruge billigere servere, kaldet vare servere .Selv for mindre datasæt kan det være billigere at købe tre råvareservere i stedet for en enkelt, højere server.

En anden vigtig fordel er, at det er lettere at tilføje høj tilgængelighed. Du er allerede halvvejs ved at distribuere dine data. Hvis du replikerer dine data en eller to gange på tværs af andre servere i klyngen, er dine data stadig tilgængelige, selvom en af ​​serverne styrter, brænder og dør.

Ikke alle open source-databaser understøtter høj tilgængelighed, medmindre du køber den understøttede, betalte version af databasen fra firmaet, der udvikler den.

En undtagelse fra den højtfordelbare regel er den for grafdatabaser. For effektivt at kunne besvare visse grafiske forespørgsler rettidigt skal data gemmes på en enkelt server. Ingen har løst dette særlige problem endnu.

Overvej omhyggeligt, om du har brug for en trippelbutik eller en grafbutik. Triple butikker er generelt fordelbare, mens grafbutikker ikke er. Hvilket du har brug for afhænger af de spørgsmål, du skal støtte.