Att distribuera en klustrad databas är en sak, men hur du underhåller din DBM medan du är i klustret kan vara en stor uppgift för en konsekvent servering av dina applikationer. Man bör ha en ofta uppdaterad status för databasen, särskilt de mest avgörande måtten för att få en aning om vad man ska uppgradera eller snarare ändra för att förhindra eventuella flaskhalsar som kan uppstå.
Det finns många överväganden angående MongoDB som man bör ta hänsyn till, särskilt det faktum att det är ganska lätt att installera och köra, och chansen att försumma grundläggande databashanteringsmetoder är höga.
Många ibland misslyckas utvecklare med att ta hänsyn till framtida tillväxt och ökad användning av databasen, vilket resulterar i att applikationer eller data kraschar med vissa integritetsproblem förutom att de är inkonsekventa.
I den här artikeln kommer vi att diskutera några av de bästa metoderna man bör använda för MongoDB-kluster för effektiv prestanda för dina applikationer. Några av de faktorer man bör överväga inkluderar...
- Uppgraderar till senaste version
- Lämplig lagringsmotor
- Tilldelning av maskinvaruresurser
- Replikering och sönderdelning
- Ändra aldrig serverns konfigurationsfil
- Bra säkerhetsstrategi
Uppgraderar till senaste version
Jag har arbetat med MongoDB från versioner före 3.2 och om jag ska vara ärlig så var det inte lätt på den tiden. Med fantastiska utvecklingar, fixade buggar och nyligen introducerade funktioner kommer jag att råda dig att alltid uppgradera din databas till den senaste versionen. Till exempel hade införandet av aggregeringsramverket en bättre prestandaeffekt snarare än att förlita sig på Map-Reduce-konceptet som redan fanns. Med den senaste versionen 4.0 har man nu möjlighet att använda funktionen för multidokumenttransaktioner som generellt förbättrar genomströmningsoperationer. Den senaste versionen har också några ytterligare nya typer av konverteringsoperatorer som $toInt, $toString, $trim och $toBool. Dessa operatörer kommer till stor hjälp vid valideringen av data och skapar därför en viss känsla av datakonsistens. När du uppgraderar vänligen se dokumenten så att du kan undvika att göra mindre misstag som kan eskalera till att vara felaktiga.
Välj en lämplig lagringsmotor
MongoDB stöder 3 lagringsmotorer som nu, det vill säga:WiredTiger, In-Memory och MMAPv1 lagringsmotorer. Var och en av dessa lagringsmotorer har fördelar och begränsningar framför den andra, men ditt val beror på din applikationsspecifikation och motorns kärnfunktionalitet. Men personligen föredrar jag WiredTiger-lagringsmotorn och jag skulle rekommendera denna för en som inte är säker på vilken man ska använda. WiredTiger-lagringsmotorn är väl lämpad för de flesta arbetsbelastningar, ger en samtidighetsmodell på dokumentnivå, kontrollpunkter och komprimering.
Några av övervägandena när det gäller val av lagringsmotor är beroende av dessa aspekter:
- Transaktioner och atomicitet: tillhandahållande av data under en infogning eller uppdatering som utförs endast när alla villkor och steg i tillämpningen har utförts framgångsrikt. Verksamheten buntas därför ihop i en oföränderlig enhet. Med detta på plats kan transaktioner med flera dokument stödjas, vilket framgår av den senaste versionen av MongoDB för WiredTiger-lagringsmotorn.
- Låsningstyp: det är en kontrollstrategi för åtkomst eller uppdatering av information. Under låstiden kan ingen annan operation ändra data för det valda objektet förrän den aktuella operationen har utförts. Följaktligen påverkas frågor just nu och därför är det viktigt att övervaka dem och minska huvuddelen av låsmekanismen genom att se till att du väljer den lämpligaste lagringsmotorn för dina data.
- Indexering: Lagringsmotorer i MongoDB tillhandahåller olika indexeringsstrategier beroende på vilka datatyper du lagrar. Effektiviteten av den datastrukturen bör vara ganska vänlig med din arbetsbelastning och man kan avgöra detta genom att betrakta varje extra index som att ha en viss prestandaoverhead. Skrivoptimerade datastrukturer har lägre overhead för varje index i en applikationsmiljö med hög insättning än icke-skrivoptimerade datastrukturer. Detta kommer att vara ett stort bakslag, särskilt när ett stort antal index är inblandade och val av en olämplig lagringsmotor. Att välja en lämplig lagringsmotor kan därför få en dramatisk inverkan.
Tilldelning av maskinvara
När nya användare loggar in på din applikation växer databasen med tiden och nya skärvor kommer att introduceras. Du kan dock inte lita på de hårdvaruresurser du hade etablerat under distributionsstadiet. Det kommer att ske en motsvarande ökning av arbetsbelastningen och kräver därför fler bearbetningsresurser som CPU och RAM för att stödja dina stora datakluster. Detta hänvisas ofta till kapacitetsplanering i MongoDB. De bästa metoderna kring kapacitetsplanering inkluderar:
- Övervaka din databas konstant och justera efter förväntningarna. Som nämnts tidigare kommer en ökning av antalet användare att utlösa fler frågor hädanefter med en ökad arbetsbelastning, särskilt om du använder index. Du kan börja uppleva denna påverkan på applikationsänden när den börjar registrera en förändring i procentandelen skrivningar kontra läsningar med tiden. Du måste därför konfigurera om dina hårdvarukonfigurationer för att lösa detta problem. Använd mongoperf och MMS-verktyg för att upptäcka ändringar i systemprestandaparametrar.
- Dokumentera alla dina prestationskrav i förväg. När du stöter på samma problem har du åtminstone en referenspunkt som sparar tid. Din inspelning bör omfatta storleken på data du vill lagra, analys av frågor i termer av latens och hur mycket data du vill komma åt vid en given tidpunkt. I produktionsmiljön måste du bestämma hur många förfrågningar du ska hantera per sekund och slutligen hur mycket latens du kommer att tolerera.
- Iscenesätt ett bevis på konceptet. Utför schema/indexdesign och förstå frågemönstren och förfina sedan din uppskattning av arbetsuppsättningens storlek. Anteckna den här konfigurationen som en referenspunkt för testning med successiva revisioner av programmet.
- Gör dina tester med verklig arbetsbelastning. Efter att ha genomfört stadiet av beviskonceptet, implementera endast efter att ha genomfört en omfattande testning med verkliga data- och prestandakrav.
Replikering och delning
Dessa är de två huvudkoncepten för att säkerställa hög tillgänglighet av data respektive ökad horisontell skalbarhet i MongoDB-klustret.
Sharding delar i princip upp data över servrar i små delar som kallas shards. Balansering av data mellan skärvor sker automatiskt, skärvor kan läggas till eller tas bort utan att nödvändigtvis ta databasen offline.
Replikering i andra änden upprätthåller flera redundanta kopior av data för hög tillgänglighet. Det är en inbyggd funktion i MongoDB och fungerar över ett stort nätverk utan behov av specialiserade nätverk. För en klusterinstallation rekommenderar jag att du har minst 2+ mongos, 3 konfigurationsservrar, 1 shard och säkerställer anslutning mellan maskiner som är inblandade i sharded klustret. Använd ett DNS-namn istället för IP-adresser i konfigurationen.
För produktionsmiljöer använd en replikuppsättning med minst 3 medlemmar och kom ihåg att fylla i fler konfigurationsvariabler som oplogstorlek.
När du startar dina mongod-instanser för dina medlemmar, använd samma nyckelfil.
Några av övervägandena för din shardkey bör inkludera:
- Nyckel och värde är oföränderliga
- Överväg alltid att använda index i en delad samling
- Uppdatera drivrutinskommandot bör innehålla en shard-nyckel
- Unika begränsningar som ska underhållas av shard-nyckeln.
- En shard-nyckel kan inte innehålla speciella indextyper och får inte överstiga 512 byte.
Ändra aldrig serverkonfigurationsfil
Efter att ha gjort din första distribution är det tillrådligt att inte ändra många parametrar i konfigurationsfilen, annars kan du hamna i problem, särskilt med skärvor. Den svagaste länken med sharding är konfigurationsservrarna. Det vill säga att alla mongod-instanser måste köras för att sharding ska fungera.
Bra säkerhetsstrategi
MongoDB har varit sårbart för externa attacker under de senaste åren, vilket är ett viktigt åtagande för din databas att ha vissa säkerhetsprotokoll. Förutom att köra processerna i olika portar, bör man åtminstone använda ett av de 5 olika sätten att säkra MongoDB-databaser. Du kan överväga plattformar som MongoDB Atlas som säkrar databaser som standard genom kryptering av data både under transport och i vila. Du kan använda strategier som TLS/SSL för alla inkommande och utgående anslutningar.
Slutsats
MongoDB klusterkontroll är inte en lätt uppgift och det innebär många lösningar. Databaser växer som ett resultat av fler användare och därmed ökad arbetsbelastning. On har därför ett mandat att säkerställa att DBM:s prestanda är i linje med detta ökade antal användare. De bästa metoderna går utöver att öka hårdvaruresurserna och tillämpa vissa MongoDB-koncept som sharding, replikering och indexering. Men många av de olägenheter som kan uppstå åtgärdas väl genom att uppgradera din MongoDB-version. Oftare har de senaste versionerna buggar fixade, nya funktionsförfrågningar integrerade och nästan ingen negativ inverkan på uppgradering även med stora revisionsnummer.