Håndtering av partisjoner i NoSQL-dummies

Ordpartisjonen brukes til to forskjellige begreper i NoSQL-land. En datadeling er en mekanisme for å sikre at dataene blir jevnt fordelt over en klynge. På den annen side oppstår en nettverkspartisjon når to deler av den samme databaseklyngen ikke kan kommunisere.

På svært store klyngesystemer er det stadig mer sannsynlig at en feil på ett utstyr vil skje. Hvis en nettverksbryter mellom servere i en klynge feiler, oppstår et fenomen som kalles (i datarjargong) delt hjerne . I dette tilfellet mottar enkelte servere fortsatt forespørsler, men de kan ikke kommunisere med hverandre.

Dette scenariet kan føre til inkonsekvens av data eller bare til redusert kapasitet i datalagring, da nettverkspartisjonen med de minste serverne fjernes fra klyngen (eller "avstemt av" i sann Big Brother-mote).

Tolerere partisjoner

Du har to valg når en nettverkspartisjon skjer:

• Fortsett på noe nivå for å betjene lese- og skriveoperasjoner.

• "Stem av" en del av partisjonen og bestem deg for å fikse dataene senere når begge delene kan kommunisere. Dette innebærer vanligvis at klyngen stemmer med en lese-kopi som den nye masteren for hver manglende hovedpartisjonskode.

Riak gir deg mulighet til å bestemme hvor mange ganger dataene blir replikert (tre kopier, som standard - det vil si n = 3) og hvor mange servere som skal forespørres for at en leser skal lykkes. Dette betyr at hvis primærmasteren til en nøkkel er på feil side av en nettverkspartisjon, kan lesoperasjoner fortsatt lykkes hvis de to andre serverne er tilgjengelige (det vil si r = 2 lese tilgjengelighet).

Riak-håndtak skriver når den primære partisjonsserveren går ned ved å bruke et system kalt antydet handoff . Når data repliseres opprinnelig, skrives den første noden for en bestemt nøkkelpartisjon til, sammen med (som standard) to av de følgende nabo noder.

Hvis primæren ikke kan skrives til, skrives neste knutepunkt i ringen til. Disse skrivene leveres effektivt til neste knutepunkt. Når den primære serveren kommer opp igjen, blir skrivene gjengitt til den noden før den tar over primære skriveoperasjoner igjen.

I begge disse operasjonene kan versjonsforstyrrelser forekomme fordi forskjellige replikas kan være i forskjellige versjonstilstander, selv om det bare er noen få millisekunder.

Riak benytter enda et system kalt aktiv anti - entropi for å lindre dette problemet. Dette systemet trawls gjennom oppdaterte verdier og sikrer at replikas oppdateres på et tidspunkt, helst raskere enn senere.Dette bidrar til å unngå konflikter i å lese mens du opprettholder en høy inntakshastighet, noe som unngår en tofasetilførsel brukt av andre NoSQL-databaser med master-slave, delt-ingenting-klyngerstøtte.

Hvis en konflikt på lesing skjer, bruker Riak lese reparasjon for å forsøke å returnere bare de nyeste dataene. Til slutt, og avhengig av konsistens- og tilgjengelighetsinnstillingene du bruker, kan klientprogrammet bli presentert med flere versjoner og bedt om å bestemme seg selv.

I noen situasjoner er denne avviket ønskelig, og mange applikasjoner kan intuitivt vite, basert på dataene som presenteres, hvilken versjon som skal brukes og hvilken versjon som skal kasseres.

Sekundær indeksering

Sekundære indekser er indekser på spesifikke data innenfor en verdi. De fleste nøkkelverdier lagrer denne indekseringen opp til applikasjonen. Imidlertid er Riak annerledes, og bruker en ordning kalt dokument - basert partisjonering som tillater sekundær indeksering.

Dokumentbasert partisjonering forutsetter at du skriver JSON-strukturer til Riak-databasen. Du kan deretter sette opp indekser på bestemte navngitte egenskaper i denne JSON-strukturen, som vist:

{"bestillings-id": 5001, "kunde-ID": 1429857, "bestillingsdato": "2014-09-24 "," Totalt ": 134. 24}

Hvis du har et program som viser kundens ordre for den forrige måneden, vil du spørre alle postene, som vist, hvor kundens ID er en fast verdi (1429857) og bestillingsdatoen er innenfor et bestemt område (begynnelsen og slutten av måneden).

I de fleste nøkkelverdibutikker lager du en annen bøtte, hvis nøkkel er det kombinerte kundenummeret og måneden, og verdien er en liste over ordreinnstillinger. Men i Riak legger du ganske enkelt til en sekundær indeks på både kunde-id (heltall) og ordre-dato (dato), som tar opp ekstra lagringsplass, men har fordelen av å være transparent for applikasjonsutvikleren.

Disse indeksene oppdateres også live - noe som betyr at det ikke er noe lag mellom å oppdatere en dokumentverdi i Riak og indeksene er oppdaterte. Denne levende tilgangen til data er vanskeligere å trekke av enn det virker. Tross alt, hvis indeksene er inkonsekvente, vil du aldri finne de konsekvent lagrede dataene!

Evaluering av Riak

Basho, den kommersielle enheten bak Riak, sier at den kommende versjonen 2. 0 NoSQL-databasen alltid har sterk konsistens, et krav som andre NoSQL-leverandører gjør. Påstand fra NoSQL-leverandører til å alltid ha sterk konsistens er som å hevde å være en sterk vegetarianer … unntatt på søndager når du har roastbiff.

Riak er ikke en ACID-kompatibel database. Dens konfigurasjon kan ikke endres slik at den går i ACID-kompatibilitetsmodus. Klienter kan få inkonsekvente data under normale operasjoner eller under nettverkspartisjoner. Riak handler absolutt konsistens for økt tilgjengelighet og partisjonstoleranse.

Running Riak i sterk konsistensmodus betyr at dets lesereplikater oppdateres samtidig med primærmasteren. Dette innebærer en tofase-forpliktelse - i utgangspunktet skriver hovednoden til de andre noderne før den bekrefter at skrivingen er fullført.

På tidspunktet for denne skrivingen støtter ikke Riaks sterke konsistensmodus sekundære indekser eller komplekse datatyper (for eksempel JSON). Forhåpentligvis vil Basho fikse dette problemet i kommende utgivelser av databasen.

Riak Search (en rebranded og integrert Apache Solr søkemotor bruker en slutt konsistent oppdateringsmodell) kan gi falske positiver når du bruker sterk konsistens. Denne situasjonen oppstår fordi data kan skrives og transaksjonen forlates, men dataene brukes fortsatt til indeksering - etterlater et "falskt positivt" søkeresultat - resultatet er faktisk ikke lenger gyldig for søket.

Riak bruker også en separat sentinelprosess for å bestemme hvilken node som blir en mester i failover-forhold. Denne prosessen er imidlertid ikke tilgjengelig, noe som betyr at det i noen sekunder er mulig at en ny kopi av sentinelprosessen blir hentet på nettet, ikke kan legges til en ny node eller en ny mestervalgt. Du må være oppmerksom på denne muligheten i høyspenningsfeilforhold.

Riak har noen fine funksjoner for applikasjonsutviklere, for eksempel sekundær indeksering og innebygd JSON-verdi støtte. Databasereplikasjon for katastrofegjenoppretting til andre datacentre er bare tilgjengelig i den betalt for versjonen, hvis pris kan bli funnet på deres hjemmeside (utleiepriser vist, evigvarende lisenspriser gitt kun på søknad).

Riak Control-klyngen overvåking verktøyet er heller ikke høyt ansett på grunn av sin lagringstid når overvåking av klynger. Riak har mye løfte, og hvis Basho vil legge til flere enterprise - nivå klyngestyringsfasiliteter i fremtidige versjoner, blir det et førsteklasses produkt.