Klusterdistributioner är av stor betydelse för att säkerställa hög tillgänglighet av data samt skydda den. MongoDB förbättrar detta genom replikering och skärning, varvid replikering säkerställer vertikal skalning genom att lyfta redundans medan skärning blåser upp horisontell skalning.
I allmänhet försöker båda tillvägagångssätten fördela arbetsbelastningen mellan medlemmarna och därmed minska den arbetsbelastning som en enskild nod kan utsättas för. Databasens prestanda kan då ses som snabb för att betjäna användare med genomströmningsoperationer. Men utan en prime klusterarkitektur kanske du inte ser samma resultatnivå, även om du försöker skärpa och replikera.
Om replikuppsättningens medlemmar är jämna, kommer det att vara svårt för medlemmarna att rösta och välja till en ny primär om den befintliga misslyckas någon gång. I den här bloggen kommer vi att diskutera standardinstallationsarkitekturen man kan använda, men den kan variera beroende på applikationskrav.
MongoDB-distributionsstrategier
Arkitekturen för replikuppsättningar är mycket avgörande för kapaciteten och förmågan hos MongoDB.
En replikuppsättning med tre noder är standardklusterdistributionen för MongoDB i alla produktionsmiljöer eftersom den ger dataredundans och feltolerans. Redundans är viktigt, särskilt vid databasåterställning efter en katastrof. En replikuppsättning med tre noder kan vara den grundläggande implementeringsarkitekturen, men detta kan variera beroende på applikationsspecifikationer och krav. Men gör det inte för komplicerat eftersom det kan leda till större konfigurationsproblem.
MongoDB Sharding Strategies
Sharding minskar den arbetsbelastning som databasen ska arbeta med för en given fråga genom att minska antalet dokument som måste åtgärdas. Det lyfter därför horisontell skalning så att databasen kan växa bortom hårdvarugränserna för en enskild server. Beroende på efterfrågan på arbetsbelastningen kan noder läggas till eller tas bort från klustret och MongoDB kommer att balansera om data på ett optimalt sätt utan operationsingrepp.
Några av de bästa distributionsstrategierna för ett fragmenterat kluster inkluderar:
Se till att Shard-nycklar distribueras enhetligt
Anledningen till sharding är att skala databasen horisontellt och minska antalet genomströmningsoperationer som en enskild instans kan utsättas för. Om du inte fördelar shard-nycklarna enhetligt kan du få ett litet antal shards. Med få skärvor kan operationer begränsas av kapaciteten hos en enda skärva, vilket gör läs- och skrivoperationer långsamma.
Bunkar bör fördelas och distribueras först
Shards har databitar som är grupperade enligt vissa shard-nyckelkriterier. När du skapar en ny fragmenterad samling, innan du laddar den med data, bör du skapa tomma bitar och fördela dem jämnt på alla shards. När du kommer att fylla MongoDB med data blir det lätt att balansera belastningen över de inblandade skärvorna. Alternativet numInitialChunks kan användas för att göra dessa automatiskt om du använder hash-baserad sharding. Heltalsvärdet bör dock vara mindre än 8192 per skärva.
Antal skärvor
Två skärvor krävs ofta som det minsta antalet för att skärvningsbetydelsen ska uppnås. En enskild shard är bara användbar om du vill lägga grunden för att möjliggöra sharding i framtiden och inte behövs under driftsättningstiden.
Föredrar intervallbaserad delning framför hashbaserad delning
Räckviddsbaserad skärning är fördelaktig eftersom den ger fler skärvor, därför kan operationer dirigeras till det minsta antal skärvor som behövs och oftare en enda skärva. Praktiskt taget kan detta vara svårt om du inte har en god förståelse för data och frågemönster som är involverade. Hashed skärning förbättrar den enhetliga fördelningen av genomströmningsdrift på bekostnad av att tillhandahålla sämre räckviddsbaserade operationer.
Använd Scatter-Gather-frågor för endast stora aggregeringsfrågor
Frågor som inte kan dirigeras baserat på en shardnyckel bör sändas till alla shards för utvärdering och eftersom de involverar flera shards för varje begäran, skalas de inte linjärt eftersom fler shards läggs till, vilket leder till en overhead som försämrar databasens prestanda. Denna operation är känd som scatter-gather och kan bara undvikas om du inkluderar shard-nyckeln i din fråga.
Tillvägagångssättet är bara användbart när man hanterar stora aggregeringsfrågor, där varje fråga kan tillåtas att köras parallellt på alla skärvor.
MongoDB-replikeringsstrategier
Replikering förbättrar vertikal skalning i MongoDB så att arbetsbelastningen fördelas mellan de inblandade medlemmarna. I produktionsmiljön är detta några av de överväganden man bör göra för en optimal klusterarkitektur.
Antal noder
Det maximala antalet noder som en replikuppsättning kan ha är 50 med 7 röstberättigade medlemmar. Varje medlem efter den 7 anses vara röstlös. Ett bra kluster bör därför ha 7 röstberättigade medlemmar för att göra valprocessen bekväm.
Distribuera ett udda antal röstande medlemmar och om du bara har färre än 7 men jämnt antal medlemmar, måste du sätta in en domare som en annan röstande medlem. Skiljedomarna lagrar inte en kopia av data och kommer därför att kräva färre resurser att hantera. Dessutom kan man utsätta dem för en miljö som du inte kunde utsätta de andra medlemmarna.
Feltoleransöverväganden
Ibland kan vissa medlemmar bli otillgängliga på grund av faktorer som strömavbrott eller nätverkstransienter och frånkopplingar. Antalet medlemmar som finns kvar i setet och som kan välja en primär skapar en situation som kallas Feltolerans. Det är därför skillnaden mellan det totala antalet replikuppsättningsmedlemmar och majoriteten av röstberättigade medlemmar som behövs för att välja ett primärval. Frånvaron av ett primärt dikterar att skrivoperationer inte kan utföras.
Tabell nedan visar ett exempel på förhållandet mellan de tre.
| Totalt antal replikuppsättningsmedlemmar | Majoritet krävs för att välja ny primär | Feltolerans |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
Släktskapet är inte så direkt i och med att om du lägger till fler medlemmar till setet är det inte givet att feltoleransen kommer att öka sett från tabellen. Ytterligare medlemmar ger stöd för dedikerade funktioner som säkerhetskopiering och rapportering.
Kapacitetsplanering och lastbalansering för tunga läsningar
Du måste ha en ledig kapacitet för din distribution genom att lägga till nya medlemmar innan den nuvarande efterfrågan mättar kapaciteten för den befintliga uppsättningen.
För mycket hög lästrafik, distribuera genomströmningsläsningarna till de sekundära medlemmarna och närhelst klustret växer, lägg till eller flytta medlemmar till alternativa datacenter för att uppnå redundans och öka datatillgängligheten.
Du kan också använda måloperationer med tagguppsättningar för att rikta läsoperationer till specifika medlemmar eller ändra skrivproblem för att begära bekräftelse från specifika medlemmar.
Noder bör distribueras geografiskt
Datacenter kan också misslyckas på grund av någon katastrof . Man rekommenderas därför att hålla minst en eller två medlemmar i ett separat datacenter i dataskyddssyfte. Om möjligt, använd ett udda antal datacenter och välj en distribution som maximerar sannolikheten att även om ett datacenter förloras, kan återstående replikuppsättningsmedlemmar bilda en majoritet eller åtminstone tillhandahålla en kopia av data.
Använd journalföring för oväntade fel
Som standard är detta aktiverat i MongoDB. Du bör se till att det här alternativet är aktiverat för att skydda dataförlust i händelse av serviceavbrott som plötsliga omstarter och strömavbrott.
Isättningsmönster
Det finns huvudsakligen två distributionsmetoder som är:
- Tre medlemsreplikuppsättningar som ger minsta rekommenderade arkitektur för en replikuppsättning.
- Replika uppsättning distribuerad över två eller flera datacenter för att skydda mot anläggningsspecifika fel som strömavbrott.
Mönstren är dock beroende av applikationskrav, men om möjligt kan du kombinera funktionerna hos dessa två i din implementeringsarkitektur.
Värdnamn och namngivning av replikuppsättningar
Använd logiskt DNS-värdnamn snarare än IP-adress när du konfigurerar replikuppsättningsmedlemmar eller delade klustermedlemmar. Detta för att undvika smärtan i samband med konfigurationsändringar som du måste göra som ett resultat av ändrade IP-adresser.
I fallet med namngivning av replikuppsättningar, använd distinkta namn för uppsättningarna eftersom vissa drivrutiner grupperar replikuppsättningsanslutningar efter replikuppsättningsnamn.
Slutsats
Arkitekturlayout för en replikuppsättning avgör kapaciteten och kapaciteten för din distribution. Dataskydd och systemprestanda är de viktigaste övervägandena när du ställer in arkitekturen. Man bör överväga viktiga faktorer som feltolerans, antal replikuppsättningsmedlemmar, optimal skärningsnyckel och distributionsmönster för hög tillgänglighet och dataskydd. Geografisk fördelning av replikuppsättningsnoderna kan ta itu med många av dessa faktorer genom att säkerställa redundans och tillhandahålla feltolerans om ett av datacentren är frånvarande.