Håndtering af partitioner i NoSQL - dummies

Ordpartitionen bruges til to forskellige begreber i NoSQL land. En datadeling er en mekanisme til at sikre, at data fordeles jævnt over en klynge. På den anden side forekommer en netværkspartition , når to dele af den samme databaseklynge ikke kan kommunikere.

På meget store grupperede systemer er det i stigende grad sandsynligt, at en fejl i et udstyr vil ske. Hvis et netværkskobling mellem servere i en klynge fejler, forekommer der et fænomen, der kaldes (i computerjargon) split hjerne . I dette tilfælde modtager enkelte servere stadig anmodninger, men de kan ikke kommunikere med hinanden.

Dette scenario kan føre til inkonsekvens af data eller simpelthen til reduceret kapacitet i datalagring, da netværkspartitionen med de mindste servere fjernes fra klyngen (eller "afstemt" i ægte Big Brother-mode).

Tolerere partitioner

Du har to valgmuligheder, når en netværkspartition sker:

• Fortsæt på et eller andet niveau for at servicere læsnings- og skriveoperationer.

• "Afstem" en del af partitionen og beslutter at rette dataene senere, når begge dele kan kommunikere. Dette involverer normalt klyngen at stemme en læseprice som den nye mester for hver manglende masterpartitionsknude.

Riak giver dig mulighed for at bestemme, hvor mange gange data replikeres (tre kopier, som standard - det vil sige n = 3) og hvor mange servere der skal forespørges for at en læsning skal lykkes. Dette betyder, at hvis de primære master af en nøgle er på den forkerte side af en netværkspartition, kan læsninger stadig lykkes, hvis de to andre servere er tilgængelige (det vil sige r = 2 læse tilgængelighed).

Riak håndtag skriver, når den primære partitionsserver går ned ved at bruge et system kaldet antydet handoff . Når data oprindeligt replikeres, skrives den første node for en bestemt nøglepartition til, sammen med (som standard) to af de følgende naboknudepunkter.

Hvis den primære ikke kan skrives til, skrives den næste knude i ringen til. Disse skrivninger afleveres effektivt til næste knudepunkt. Når den primære server kommer op igen, afspilles skrivningerne til den node, før den overtar primære skriveoperationer igen.

I begge disse operationer kan versionsmæssige inkonsekvenser ske, fordi forskellige replikaer kan være i forskellige versionslande, selvom det kun er få millisekunder.

Riak beskæftiger endnu et system kaldet aktiv anti - entropi for at afhjælpe dette problem. Dette system trawls gennem opdaterede værdier og sikrer, at replikaer opdateres på et tidspunkt, helst hurtigere end senere.Dette hjælper med at undgå læsekonflikter, samtidig med at der opretholdes en høj indtastningshastighed, hvilket undgår en tofaseforbrydelse, der anvendes af andre NoSQL-databaser med master-slave, understøttelse af delt-intet clustering.

Hvis der opstår konflikt med læsning, bruger Riak læs reparation for at forsøge at returnere kun de nyeste data. Til sidst, og afhængigt af de konsistens- og tilgængelighedsindstillinger, du bruger, kan klientprogrammet præsenteres med flere versioner og bliver bedt om at bestemme for sig selv.

I nogle situationer er denne bytte ønskelig, og mange applikationer kan intuitivt vide, baseret på de præsenterede data, hvilken version der skal bruges, og hvilken version der skal kasseres.

Sekundær indeksering

Sekundære indeks er indekser for specifikke data inden for en værdi. De fleste nøgletalbutikker forlader denne indeksering op til applikationen. Imidlertid er Riak anderledes, idet der anvendes en ordning kaldet dokument - baseret partitionering , der muliggør sekundær indeksering.

Dokumentbaseret partitionering forudsætter, at du skriver JSON-strukturer til Riak-databasen. Du kan derefter oprette indekser på bestemte navngivne egenskaber inden for denne JSON-struktur som vist:

{"order-id": 5001, "kunde-id": 1429857, "order-date": "2014-09-24 "," Total ": 134. 24}

Hvis du har en ansøgning, der viser en kundes ordrer for den foregående måned, vil du søge alle poster som vist, hvor kundens id er en fast værdi (1429857) og bestillingsdatoen er inden for et bestemt interval (begyndelsen og slutningen af ​​måneden).

I de fleste nøgletalbutikker opretter du en anden buket, hvis nøgle er det kombinerede kundenummer og måneden, og værdien er en liste over ordreindstillinger. Men i Riak tilføjer du simpelthen et sekundært indeks på både kunde-id (heltal) og ordre-dato (dato), hvilket giver ekstra lagerplads, men har den fordel at være transparent for applikationsudvikleren.

Disse indekser opdateres også live - hvilket betyder, at der ikke er nogen forsinkelse mellem at opdatere en dokumentværdi i Riak og indekserne er opdaterede. Denne levende adgang til data er vanskeligere at trække ud end det ser ud til. Når alt kommer til alt, hvis indekserne er inkonsekvente, finder du aldrig de konsekvent lagrede data!

Evaluering af Riak

Basho, den kommercielle enhed bag Riak, siger, at dens kommende version 2. 0 NoSQL-database altid har stærk konsistens, et krav, som andre NoSQL-leverandører gør. Anprisningen fra NoSQL-leverandører til altid at have stærk konsistens er som at hævde at være en stærk vegetarisk … undtagen om søndagen, når du har roastbiff.

Riak er ikke en ACID-kompatibel database. Dens konfiguration kan ikke ændres, så den kører i ACID-compliance-tilstand. Kunder kan få inkonsekvente data under normale operationer eller under netværkspartitioner. Riak handler absolut konsistens for øget tilgængelighed og partitionstolerance.

Running Riak i stærk konsistenstilstand betyder, at dens læste replikaer opdateres samtidig med den primære master. Dette indebærer en tofaset forplig - i princippet skriver hovednoden til de andre knuder, inden den bekræfter, at skrivningen er færdig.

Riaks stærke konsistenttilstand understøtter ikke sekundære indekser eller komplekse datatyper (f.eks. JSON). Forhåbentlig vil Basho løse dette problem i kommende udgivelser af databasen.

Riak Search (en rebranded og integreret Apache Solr søgemaskine bruger en til sidst konsistent opdateringsmodel) kan frembringe falske positive ved brug af stærk konsistens. Denne situation opstår, fordi data kan skrives, og derefter overgives transaktionen, men dataene bruges stadig til indeksering - efterlader et "falskt positivt" søgeresultat - resultatet er faktisk ikke længere gyldigt for søgeforespørgslen.

Riak bruger også en separat sentinel proces for at bestemme hvilken node bliver en mester i failover-forhold. Denne proces er imidlertid ikke meget tilgængelig, hvilket betyder at i et par sekunder er det muligt, at mens en ny kopi af sentinel-processen bliver bragt online, kan en ny node ikke tilføjes eller en ny mester valgt. Du er nødt til at være opmærksom på denne mulighed i overordnede stressoverføringsforhold.

Riak har nogle gode funktioner til applikationsudviklere, som sekundær indeksering og indbygget JSON-værdistøtte. Databasereplikation til katastrofegendannelse til andre datacentre er kun tilgængelig i den betalte version, hvis pris kan findes på deres hjemmeside (de viste lejepriser, de løbende licenspriser, der kun gives på ansøgningen).

Riak Control-klyngeovervågningsværktøjet betragtes heller ikke højt på grund af dets forsinket tid, når overvågning af klynger. Riak har mange løfter, og hvis Basho vil tilføje flere enterprise - niveau klyngestyringsfaciliteter i fremtidige versioner, bliver det et bedste produkt.