Klyngeimplementeringer er af stor betydning for at sikre den høje tilgængelighed af data samt beskytte dem. MongoDB forbedrer dette gennem replikering og sharding, hvorved replikering sikrer vertikal skalering gennem løfteredundans, mens sharding puster vandret skalering op.
Generelt forsøger begge tilgange at fordele arbejdsbyrden blandt medlemmerne og dermed reducere den arbejdsbyrde, som en enkelt node kan blive udsat for. Databaseydelsen kan så ses som hurtig til at betjene brugere med gennemløbsoperationer. Uden en prime klyngearkitektur kan du dog muligvis ikke se det samme niveau af resultater, selvom du prøver sharding og replikering.
Hvis replikasættets medlemmer er lige, så vil det være svært for medlemmerne at stemme og vælge til et nyt primærvalg, hvis det eksisterende mislykkes på et tidspunkt. I denne blog vil vi diskutere den standardimplementeringsarkitektur, man kan bruge, men denne kan variere i overensstemmelse med applikationskravene.
MongoDB-implementeringsstrategier
Arkitekturen af replikasæt er meget afgørende for MongoDB's kapacitet og kapacitet.
Et replikasæt med tre noder er standardklynge-implementeringen for MongoDB i ethvert produktionsmiljø, da det giver dataredundans og fejltolerance. Redundans er vigtig, især i databasegendannelse efter katastrofe. Et replikasæt med tre knudepunkter kan være den grundlæggende implementeringsarkitektur, men dette kan variere i henhold til applikationsspecifikationer og krav. Men gør det ikke for komplekst, da det kan føre dig til nogle større konfigurationsproblemer.
MongoDB-delingsstrategier
Sharding reducerer den arbejdsbyrde, som databasen skal arbejde på for en given forespørgsel, ved at reducere antallet af dokumenter, der skal reageres på. Det løfter derfor horisontal skalering, så databasen kan vokse ud over hardwaregrænserne for en enkelt server. Afhængigt af arbejdsbelastningsbehovet kan noder tilføjes eller fjernes fra klyngen, og MongoDB vil rebalancere dataene på en optimal måde uden operationsintervention.
Nogle af de bedste implementeringsstrategier for en sharded cluster inkluderer:
Sikring af Shard Keys er distribueret ensartet
Årsagen bag sharding er at skalere databasen horisontalt og reducere antallet af gennemløbsoperationer, som en enkelt instans kan blive udsat for. Hvis du ikke fordeler shard-nøglerne ensartet, kan du ende med et lille antal shards. Med få shards kan operationer være begrænset af kapaciteten af et enkelt shard, hvilket gør læse- og skriveoperationer langsomme.
Chunks skal være forhåndsopdelt og distribueret først
Shards har datastykker, der er grupperet efter nogle shard-nøglekriterier. Når du opretter en ny shard samling, før du indlæser den med data, bør du oprette tomme bidder og fordele dem jævnt på alle shards. Når du skal udfylde MongoDB med data, vil det være nemt at balancere belastningen på tværs af de involverede shards. Indstillingen numInitialChunks kan bruges til at gøre disse automatisk, hvis du bruger hash-baseret sharding. Heltalsværdien bør dog være mindre end 8192 pr. shard.
Antal Shards
To shards er ofte påkrævet som minimumsantal for at sharding-betydning opnås. Et enkelt shard er kun nyttigt, hvis du ønsker at lægge grundlaget for at muliggøre sharding i fremtiden og ikke er nødvendigt under implementeringstiden.
Foretrækker områdebaseret deling frem for hash-baseret deling
Rangebaseret sharding er fordelagtig, da det giver flere shards, derfor kan operationer dirigeres til de færreste shards, der er nødvendige og oftere et enkelt shard. Dette kan praktisk talt være svært, medmindre du har en god forståelse af de involverede data og forespørgselsmønstre. Hashed sharding forbedrer den ensartede fordeling af gennemløbsdrift på bekostning af at levere ringere rækkevidde-baserede operationer.
Brug Scatter-Gather-forespørgsler kun til store aggregeringsforespørgsler
Forespørgsler, der ikke kan dirigeres baseret på en shard-nøgle, bør udsendes til alle shards til evaluering, og da de involverer flere shards for hver anmodning, skaleres de ikke lineært, da flere shards tilføjes, hvilket medfører en overhead som forringer databasens ydeevne. Denne operation er kendt som scatter-gather og kan kun undgås, hvis du inkluderer shard-nøglen i din forespørgsel.
Fremgangsmåden er kun nyttig, når man har at gøre med store aggregeringsforespørgsler, hvor hver forespørgsel kan tillades at køre parallelt på alle shards.
MongoDB-replikeringsstrategier
Replikering forbedrer vertikal skalering i MongoDB, således at arbejdsbyrden fordeles mellem de involverede medlemmer. I produktionsmiljøet er det nogle af de overvejelser, man bør gøre sig for en optimal klyngearkitektur.
Antal noder
Det maksimale antal noder et replikasæt kan have er 50 med 7 stemmeberettigede medlemmer. Ethvert medlem efter den 7. anses for at være uden stemmeret. En god klynge bør derfor have 7 stemmeberettigede medlemmer for at gøre valgprocessen bekvem.
Indsæt et ulige antal stemmeberettigede medlemmer, og hvis du kun har mindre end 7, men lige antal medlemmer, skal du indsætte en dommer som et andet stemmeberettiget medlem. Voldgiftsdommere gemmer ikke en kopi af dataene og vil derfor kræve færre ressourcer at administrere. Desuden kan man udsætte dem for et miljø, man ikke kunne udsætte de andre medlemmer for.
Fejltoleranceovervejelser
Nogle gange kan nogle medlemmer blive utilgængelige som følge af faktorer som strømafbrydelser eller netværkstransienter og afbrydelser. Antallet af medlemmer, der forbliver i sættet og er i stand til at vælge en primær, skaber en situation kendt som fejltolerance. Det er derfor forskellen mellem det samlede antal replika-sætmedlemmer og flertallet af stemmeberettigede medlemmer, der skal til for at vælge et primærvalg. Fravær af en primær dikterer, at skriveoperationer ikke kan udføres.
Tabellen nedenfor viser et eksempel på forholdet mellem de tre.
| Samlet antal replikasætmedlemmer | Flertal påkrævet for at vælge ny primær | Fejltolerance |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
Forholdet er ikke så direkte ved, at hvis du tilføjer flere medlemmer til sættet, er det ikke givet, at fejltolerancen vil stige som set fra tabellen. Yderligere medlemmer yder support til dedikerede funktioner såsom sikkerhedskopiering og rapportering.
Kapacitetsplanlægning og belastningsbalancering for tunge læsninger
Du skal have en ledig kapacitet til din implementering ved at tilføje nye medlemmer, før den aktuelle efterspørgsel mætter kapaciteten af det eksisterende sæt.
For meget høj læsetrafik skal du distribuere gennemløbslæsningerne til de sekundære medlemmer, og når klyngen vokser, tilføje eller flytte medlemmer til alternative datacentre for at opnå redundans og øge datatilgængeligheden.
Du kan også bruge måloperationer med tagsæt til at målrette læsehandlinger til specifikke medlemmer eller ændre skriveproblemer for at anmode om bekræftelse fra specifikke medlemmer.
Knudepunkter bør distribueres geografisk
Datacentre kan også fejle på grund af en eller anden katastrofe. Man rådes derfor til at holde mindst et eller to medlemmer i et separat datacenter af databeskyttelsesformål. Hvis det er muligt, skal du bruge et ulige antal datacentre og vælge en distribution, der maksimerer sandsynligheden for, at selv med tab af et datacenter kan resterende replikasæt-medlemmer udgøre et flertal eller som minimum levere en kopi af dataene.
Anvend journalføring for uventede fejl
Som standard er dette aktiveret i MongoDB. Du bør sikre dig, at denne mulighed er aktiveret for at beskytte datatab i tilfælde af tjenesteafbrydelser, såsom pludselige genstarter og strømsvigt.
Implementeringsmønstre
Der er hovedsageligt to implementeringsmetoder, dvs.:
- Tre medlemsreplikasæt, som giver minimum anbefalet arkitektur for et replikasæt.
- Replikasæt fordelt på to eller flere datacentre for at beskytte mod facilitetsspecifikke fejl såsom strømafbrydelser.
Mønstrene er dog afhængige af applikationskrav, men hvis det er muligt, kan du kombinere funktionerne i disse to i din implementeringsarkitektur.
Værtsnavne og navngivning af replikasæt
Brug logisk DNS-værtsnavn i stedet for ip-adresse, når du konfigurerer replikasætmedlemmer eller sharded klyngemedlemmer. Dette er for at undgå smerten forbundet med konfigurationsændringer, du bliver nødt til at foretage som følge af ændrede ip-adresser.
I tilfælde af navngivning af replikasæt skal du bruge forskellige navne til sættene, da nogle drivere grupperer replikasætforbindelser efter replikasætnavn.
Konklusion
Arkitekturlayout for et replikasæt bestemmer kapaciteten og kapaciteten af din implementering. Databeskyttelse og systemydeevne er de centrale overvejelser ved opsætning af arkitekturen. Man bør overveje vitale faktorer såsom fejltolerance, antal replikasætmedlemmer, optimal sharding-nøgle og implementeringsmønstre for høj tilgængelighed og databeskyttelse. Geografisk fordeling af replikasættets noder kan adressere mange af disse faktorer ved at sikre redundans og give fejltolerance, hvis et af datacentrene er fraværende.