Bruker konsistensmetoder i NoSQL-dummies

Egenskapen til en database i konsistensen betyr at Når data er skrevet til en database vellykket, kan spørringer som følger få tilgang til dataene og få en konsekvent visning av dataene. I praksis betyr dette at hvis du skriver en post til en database og umiddelbart ber om det, er du garantert å se den. Det er spesielt nyttig for ting som Amazon-ordrer og bankoverføringer.

Konsistens er imidlertid en glidende skala, og et emne for dypt å dekke her. Men i NoSQL-verdenen faller konsistensen generelt i en av to leire:

• ACID-konsistens (ACID står for atomitet, konsistens, isolasjon, holdbarhet): ACID betyr at når data er skrevet, har du full konsistens i leser.

• Eventuell konsistens (BASE): BASE betyr at når data er skrevet, vil det til slutt vises for lesing.

En kamp har blitt raser mellom folk som tror sterk konsistens i en database er ikke nødvendig, og de som tror det er absolutt kreves (oversetter folk til NoSQL selskaper 'markedsføring avdelinger! ).

Virkeligheten er et sted i mellom. Betyr det at en persons Facebook-innlegg ikke blir sett av alle vennene sine i fem minutter? Nei, sannsynligvis ikke. Endre "Facebook-post" til "milliard-dollar-finansiell transaksjon," skjønt, og din holdning endrer seg raskt! Hvilken konsistens tilnærming du velger, avhenger av situasjonen. I min erfaring er sterk konsistens imidlertid alltid valget i misjonskritiske virksomhetssystemssituasjoner.

ACID

ACID er et generelt sett med prinsipper for transaksjonssystemer, ikke noe som bare knytter seg til relasjonelle systemer, eller til og med bare databaser, så det er vel verdt å vite om. ACID betyr i utgangspunktet " Denne databasen har fasiliteter som hindrer deg i å ødelegge eller miste data, " som ikke er gitt for alle databaser. Faktisk gir det store flertallet av NoSQL-databaser ikke ACID-garantier.

Stiftelsen DB, MarkLogic og Neo4j er bemerkelsesverdige unntak. Noen NoSQL-databaser gir en lavere garanti som kalles Sjekk og sett som kontrollerer om noen andre har endret et dokument før en transaksjon er fullført. Denne oppførselen er vanligvis begrenset fordi den pleier å bli implementert på en enkelt rekordbase.

MongoDB er en bemerkelsesverdig database som gir kontroll og sett evner. Med MongoDB, kan en hel node-verdi av data låses under en oppdatering, og dermed forhindre alle lese og skrive alle operasjoner til operasjonen er fullført.Selskapet jobber med å fjerne denne begrensningen, skjønt.

BASE

BASE betyr at i stedet for å lage ACID-garantier, har databasen en tilpassbar balanse mellom konsistens og datatilgjengelighet. Dette er typisk tilfellet når noder i en gitt databasekluster fungerer som primære ledere for en del av databasen, og andre noder holder skrivebeskyttede kopier.

For å sikre at hver klient ser alle oppdateringer (det vil si at de har en konsistent visning av dataene), må en skrive til den primære noden som inneholder dataene, låses til alle lesereplikater er oppdatert. Dette kalles en to - faseforpligning - endringen gjøres lokalt, men brukes og bekreftes kun til klienten når alle andre noder er oppdatert.

BASE slapper av dette kravet, og krever bare en delmengde av noder som holder de samme dataene som skal oppdateres for at transaksjonen skal lykkes. Noen ganger etter at transaksjonen er forpliktet, oppdateres skrivebeskyttet kopi.

Fordelen med denne tilnærmingen er at transaksjoner er forpliktet raskere. Å ha lesbare livereplikater betyr også at du kan spre dataene dine, og leser raskere.

Ulempen er at klienter som kobler til noen av de lese replikene, kan se utdatert informasjon for en ubestemt periode. I noen scenarier er denne tilstanden fin. Hvis du legger inn en ny melding på Facebook, og noen av vennene dine ikke ser det for et par minutter, er det ikke et stort tap. Hvis du sender en betalingsordre til banken din, kan du kanskje ha en umiddelbar transaksjon.

En alternativ tilnærming til skrivebeskyttet kopi er å ha en delt - ingenting klynge der bare en node på en klynge alltid betjener en bestemt del av databasen.

Felt ingenting betyr ikke at du mister replikering, skjønt. Databaser som benytter denne metoden, gjentar vanligvis sine data til et sekundært område på en annen primærknutepunkt eller noder - men bare én knutepunkt er master for leser og skriver når som helst.

Delt-ingenting-klynger har fordelen av en enklere konsistensmodell, men krever en tofaset forpliktelse til å kopiere. Dette faktum betyr at transaksjonen låser mens alle replikene oppdateres. (En intern lås pluss låsing for andre noder gir deg to faser.)

Dette har vanligvis mindre innvirkning enn delte dataklynger med skrivebeskyttede kopier, men fordi ikke delte replikdataområder mottar ikke leseforespørsler for det del av databasen. Derfor er tofaseforpliktelser raskere på en delt-ingenting-klynge enn på en klynge med lesbare replikaer.

Velge syre eller base?

Som du kanskje forventer, er mye av argumentet fordi NoSQL-leverandører kan skille seg fra sine konkurrenter ved å kreve en annen, unik tilnærming. Det er interessant å merke seg imidlertid antall NoSQL-leverandører med ACID-overholdelse på deres veikart.

Noen NoSQL-databaser har ACID-overholdelse på deres veikart, selv om de er proponents of BASE, som viser hvordan relevante ACID-garantier er for enterprise, mission - critical -systemer.

Mange bedrifter benytter BASE-konsistensprodukter når de tester ideer fordi de er gratis, men deretter overgår til en ACID-kompatibel betalte database når de ønsker å gå live på et oppdragskritisk system.

Den enkleste måten å avgjøre om du trenger ACID, er å vurdere samspillet folk og andre systemer har med dataene dine. Hvis du for eksempel legger til eller oppdaterer data, er det viktig at den aller neste spørringen er i stand til å se endringen? Med andre ord, er viktige beslutninger som henger på databasenes nåværende tilstand? Vil du se litt utdaterte data betyr at disse beslutningene kan være dårlige feil?

I finansielle tjenester er behovet for konsistens åpenbart. Tenk på handelsmenn som kjøper aksjer. De må sjekke kontantbalansen før handel for å sikre at de har penger til å dekke handelen. Hvis de ikke ser den riktige balansen, bestemmer de seg for å bruke penger på en annen transaksjon. Hvis databasen de spør, er bare etter hvert konsekvent, kan de ikke se mangel på tilstrekkelige midler, og dermed utsette organisasjonen for økonomisk risiko.

Lignende tilfeller kan bygges for ACID over BASE i helse-, forsvars-, etterretnings- og andre sektorer. Alt dette koker ned til dataene, og betydningen av både aktualitet og datasikkerhet.