Vanlige funksjoner i NoSQL-dummies

NoSQL bøker og blogger gir forskjellige meninger om hva en NoSQL-database er. Fire kjernefunksjoner i NoSQL, vist i følgende liste, gjelder for de fleste NoSQL-databaser. Listen sammenligner NoSQL med tradisjonelle relasjonelle DBMS:

• Schema agnostic: Et databaseskjema er beskrivelsen av alle mulige data og datastrukturer i en relasjonsdatabase. Med en NoSQL-database er det ikke nødvendig med et skjema, noe som gir deg friheten til å lagre informasjon uten å gjøre opp-skjema-design.

• Ikke-relasjonelle: Forhold i en database etablerer sammenhenger mellom datatabeller. For eksempel kan en liste over transaksjonsdetaljer kobles til en separat liste over leveringsdetaljer. Med en NoSQL-database lagres denne informasjonen som et aggregat - en enkelt post med alt om transaksjonen, inkludert leveringsadressen.

• Commodity hardware: Noen databaser er designet for å fungere best (eller bare) med spesialisert lagrings- og behandlingsmaskinvare. Med en NoSQL-database kan du bruke billige servere som ikke er tilgjengelig. Hvis du legger til flere av disse billige serverne, kan NoSQL-databaser i skala for å håndtere flere data.

• Høyt fordelt: Distribuerte databaser kan lagre og behandle et sett med informasjon på mer enn én enhet. Med en NoSQL-database kan en klynge av servere brukes til å holde en enkelt stor database.

Schema agnostic

NoSQL databaser er skjema agnostisk. Du er ikke pålagt å gjøre mye foran konstruksjonsarbeid før du kan lagre data i NoSQL-databaser. Du kan starte koding og lagre og hente data uten å vite hvordan databasen lagrer og fungerer internt. (Hvis og når du trenger avansert funksjonalitet, kan du manuelt legge til flere indekser eller justere datalagringsstrukturer.) Schema-agnostisisme kan være den mest signifikante forskjellen mellom NoSQL og relationsdatabaser.

Den store fordelen med en schema agnostisk database er at utviklingstiden er forkortet. Denne fordelen øker når du går gjennom flere utviklingsutgivelser og må endre de interne datastrukturene i databasen.

For eksempel, i en tradisjonell RDBMS, går du gjennom en prosess med skjemautforming. Skjemaet instruerer databasen om hvilke data som kan forventes. Endre dataene som er lagret eller strukturer, og du må gjenoppbygge databasen ved hjelp av et endret skjema. Hvis du skulle gjøre en endring, må du bruke mye tid på å bestemme hvordan du skal arkivere eksisterende data. I NoSQL-databaser lagrer du bare en annen datastruktur. Det er ikke nødvendig å fortelle databasen på forhånd.

Det kan hende du må endre dine forespørsler tilsvarende, kanskje legge til en og annen spesifikk indeks (for eksempel en helhetsintervall for å tillate mindre enn og større enn datatypespesifikke søk), men hele prosessen er mye mindre smertefull enn det er med en RDBMS.

RDBMS tok av på grunn av sin fleksibilitet, og fordi det ved å bruke SQL, spedte det på å endre en forespørsel. NoSQL databaser gir denne fleksibiliteten for å endre både skjemaet og spørringen, noe som er en av hovedårsakene til at de vil bli vedtatt i stigende grad over tid.

Selv om du har spørsmål, trenger du ikke å bekymre deg for mye om å kjenne skjemaendringene. Vurder en indeks over et feltkontonummer hvor kontonummer kan plasseres hvor som helst i et dokument som er lagret i en NoSQL-database. Du kan endre strukturen og flytte hvor kontonummer er lagret, og hvis elementet har samme navn andre steder i dokumentet, er det fortsatt tilgjengelig for forespørsel uten endringer i spørringsmekanismen.

Merk at ikke alle NoSQL-databaser er fullt schema-agnostiske. Noen, som for eksempel HBase, krever at du stopper databasen for å endre kolonnedefinisjoner. De betraktes fortsatt som NoSQL-databaser fordi ikke alle definerte felt (kolonner i dette tilfellet) kreves å være kjent på forhånd for hver post - bare kolonnefamiliene.

RDBMS tillater enkeltfelt i poster å bli identifisert som null -verdier. Problemet med en RDBMS er at lagret datastørrelse og ytelse blir negativt påvirket når lagring er reservert for nullverdier bare hvis posten kan på en viss fremtidig tid ha en verdi i den kolonnen. I Cassandra oppgir du ikke bare kolonnens data, som løser problemet.

Ikke-relasjonelle

Relasjonsdatabasebehandlingssystemer har vært den dominerende måten å lagre søknadsdata på i mer enn 20 år. En stor del matematisk arbeid ble gjort for å bevise teorien som støtter dem.

Dette underlaget beskriver hvordan tabeller relaterer seg til hverandre. En enkelt Ordre rad kan forholde seg til mange Leveringsadresse-rader, men hver Leveringsadresse-rad gjelder også flere rekkeordre. Dette er en mange - til - mange forhold .

NoSQL databaser har ikke dette konseptet av relasjoner mellom deres poster. De deformaliserer i stedet data. Dette innebærer at i en NoSQL-database vil det være en ordrestruktur med leveringsadressen som er innebygd. Dette betyr at leveringsadressen dupliseres i hver ordningsrad som bruker den. Denne tilnærmingen har fordelen av at det ikke kreves komplisert spørringstid på tvers av flere datastrukturer (tabeller) skjønt.

NoSQL-databaser lagrer ikke informasjon om hvordan individuelle poster relaterer seg til andre poster i databasen, noe som kan høres ut som en begrensning. NoSQL-databaser er imidlertid mer fleksible når det gjelder datastrukturer du kan lagre.

Vurder en bestilling fra en nettbutikk. Ordren kan inneholde produktkoder, mengder, varepriser og varebeskrivelser, samt informasjon om personens bestilling, for eksempel leveringsadresse og betalingsinformasjon.

I stedet for å sette inn ti rader i en rekke tabeller i en relasjonsdatabase, kan du i stedet lagre en enkelt struktur for all denne bestillingsinformasjonen - si som et JSON- eller XML-dokument.

I relasjonsdatabase teori er målet å normalisere dataene dine (det vil si å organisere feltene og tabellene for å fjerne dupliserte data). I NoSQL-databaser - spesielt dokument- eller aggregatdatabaser - deformaliseres du ofte med bevissthet, lagrer noen data flere ganger.

Du kan for eksempel lagre "Kundeleveringsadresse" flere ganger på mange bestillinger som en kunde lager over tid, i stedet for å lagre den en gang og referere til den i flere bestillinger. Å gjøre det krever ekstra lagringsplass, og litt fortanke i håndtering i søknaden din. Så hvorfor gjør det?

Det er to fordeler med å lagre data flere ganger:

• Enkel lagring og gjenfinning: Bare lagre og hent en enkelt plate.

• Spørringshastighet: I relasjonsdatabaser går du med informasjon og legger til begrensninger på tvers av tabeller på forespørselstid. Dette kan kreve at databasemotoren vurderer mange tabeller. Jo flere søksbegrensninger du har på tvers av forskjellige tabeller, desto mer reduserer du søkefrekvensen. (Dette er grunnen til at en RDBMS har forhåndsdefinerte visninger.) I en NoSQL-database er all informasjon du trenger for å evaluere søket ditt, i et enkelt dokument. Derfor kan du raskt bestemme listen over samsvarende dokumenter.

Relasjonsvinkler og NoSQL-deformaliseringer er forskjellige tilnærminger til problemet med dataspredning på tvers av poster. I NoSQL må du kanskje opprettholde flere deformaliseringer som representerer forskjellige visninger av de samme dataene. Denne tilnærmingen øker kostnadene ved lagring, men gir deg mye bedre søketid.

På grunn av de stadig reduserte kostnadene for lagring og økt hastighet på utvikling og spørring, er deormaliserte dataene (aka materialiserte visninger ) ikke en dårligere grunn til å redusere NoSQL-løsninger. Det er bare en annen måte å nærme seg det samme problemet, med sine egne fordeler og ulemper.

NoSQL er svært distribusjonsbar og bruker råvarehardware

I mange NoSQL-databaser er en nøkkeldesignbeslutning å bruke flere datamaskiner til å lagre data for en enkelt database, i stedet for å ha hele databasen på en enkelt server.

Det er vanskelig å lagre data på tvers av flere maskiner og tillate det å bli forespurt. Du må sende spørringen til alle serverne og vente på et svar. Forhåpentligvis setter du opp maskinene slik at de er raske nok til å snakke med hverandre for å håndtere distribuerte søk!

Den største fordelen med denne tilnærmingen er når det gjelder svært store datasett, fordi det for enkelte lagringsbehov ikke er mulig å lagre eller behandle alle dataene du trenger, selv om den største tilgjengelige enkeltserveren ikke er tilgjengelig. Vurder alle meldingene på Twitter og Facebook. Du trenger en distribuert mekanisme for å effektivt administrere alle dataene, selv om det for det meste handler om hva folk hadde til frokost og søte kattevideoer.

En fordel ved å distribuere databasen er at du kan bruke billigere servere, kalt vare servere .Selv for mindre datasett kan det være billigere å kjøpe tre vare servere i stedet for en enkelt, høyere drevet server.

En annen viktig fordel er at å legge til høy tilgjengelighet er enklere; Du er allerede halvveis der ved å distribuere dataene dine. Hvis du kopierer dataene dine en eller to ganger over andre servere i klyngen, vil dataene dine fortsatt være tilgjengelige, selv om en av serverne krasjer, brenner og dør.

Ikke alle open source-databaser støtter høy tilgjengelighet, med mindre du kjøper den støttede, betalte versjonen av databasen fra firmaet som utvikler den.

Et unntak fra den høyt fordelbare regelen er grafdatabaser. For å kunne effektivt svare på visse grafiske spørsmål i tide, må data lagres på en enkelt server. Ingen har løst dette problemet enda.

Vurder nøye om du trenger en trippelbutikk eller en grafbutikk. Tremobutikker er generelt fordelbare, mens grafbutikker ikke er. Hvilken du trenger avhenger av spørsmålene du må støtte.