Förbereder en MongoDB-server för produktion

Efter att ha utvecklat din applikation och databasmodell (när det är dags att flytta miljön till produktion) finns det ett par saker som måste göras först. Ofta misslyckas utvecklare med att ta hänsyn till ytterligare viktiga MongoDB-steg innan de distribuerar databasen i produktion. Följaktligen är det i produktionsläget de hamnar på underliggande bakslag som inte presenteras i utvecklingsläget. Ibland kan det vara för sent eller snarare skulle mycket data gå förlorade om en katastrof inträffar. Dessutom kommer några av stegen som diskuteras här att göra det möjligt för en att mäta databasens hälsa och därmed planera för nödvändiga åtgärder innan katastrofen inträffar.

Använd den aktuella versionen och de senaste drivrutinerna

Allmänt sett kommer de senaste versionerna av alla tekniker med förbättrade funktioner i förhållande till den underliggande funktionaliteten än deras föregångare. MongoDBs senaste versioner är mer robusta och förbättrade än sina föregångare när det gäller prestanda, skalbarhet och minneskapacitet. Detsamma gäller för de relaterade drivrutinerna eftersom de utvecklas av kärndatabasteknikerna och uppdateras oftare till och med än själva databasen.

Inbyggda tillägg installerade för ditt språk kan enkelt skapa en plattform för snabba och standardprocedurer för att testa, godkänna och uppgradera de nya drivrutinerna. Det finns också mjukvara för fordon som Ansible, Puppet, SaltStack och Chef som kan användas för enkel uppgradering av MongoDB i alla dina noder utan att behöva ta på dig professionella kostnader och tid.

Överväg att använda WiredTiger-lagringsmotorn eftersom den är den mest utvecklade med moderna funktioner som passar moderna databasförväntningar

Prenumerera på en MongoDB-e-postlista för att få den senaste informationen om ändringar av nya versioner och drivrutiner och buggfixar och håll dig därför uppdaterad.

Använd ett 64-bitarssystem för att köra MongoDB

I 32-bitarssystem är MongoDB-processer begränsade till cirka 2,5 GB data eftersom databasen använder minnesmappade filer för prestanda. Detta blir en begränsning för processer som kan överskrida gränsen som leder till en crush. Kärneffekten kommer att vara:vid ett fel kommer du inte att kunna starta om servern förrän du tar bort din data eller migrerar din databas till ett högre system som 64-bitars, vilket innebär en högre driftstopp för din applikation.

Om du måste fortsätta använda ett 32-bitarssystem måste din kodning vara mycket enkel för att minska antalet buggar och fördröjning för genomströmningsoperationer.

För kodkomplexiteter som aggregeringspipeline och geodata är det dock lämpligt att använda 64-bitarssystemet.

Se till att dokument är begränsade till 16 MB storlek

MongoDB-dokument är begränsade till storleken 16 MB men du behöver inte komma nära denna gräns eftersom det kommer att innebära en viss prestandaförsämring. I praktiken är dokumenten mestadels KB eller mindre i storlek. Dokumentstorleken är beroende av datamodelleringsstrategin mellan inbäddning och referens. Inbäddning är att föredra där dokumentstorleken inte förväntas växa mycket i storlek. Om du till exempel har en applikation för sociala medier där användare gör inlägg och den har kommentarer, är den bästa praxis att ha två samlingar, en för att hålla inläggsinformation.

  {

   _id:1,

   post: 'What is in your mind?',

   datePosted: '12-06-2019',

   postedBy:'xyz',

   likes: 10,

   comments: 30

}

och den andra för att hålla kommentarer för det inlägget.

     {

   _id: ObjectId('2434k23k4'),

   postId: 1,

   dateCommented: '12-06-2019',

   commentedBy:'ABCD',

   comment: 'When will we get better again',

}

Genom att ha sådana datamodeller kommer kommentarer att lagras i en annan samling än inlägget. Detta förhindrar att dokumentet i postinsamlingen växer ut ur bunden ifall det blir så många kommentarer. Se till att du undviker applikationsmönster som gör att dokument kan växa obegränsat.

Se till att arbetsuppsättningen passar i minnet

Databasen kan misslyckas med att läsa data från virtuellt minne (RAM) vilket kan leda till sidfel. Sidfel tvingar databasen att läsa data från en fysisk disk, vilket leder till ökad latens och följaktligen en fördröjning i den övergripande applikationens prestanda. Sidfel uppstår på grund av att man arbetar med en stor uppsättning som inte får plats i minnet. Detta kan bero på att vissa dokument har en obegränsad storlek eller dålig skärningsstrategi. Åtgärder för sidfel kommer att vara:

• Se till att dokument begränsas till storleken 16 MB.
• Säkerställa en bra skärningsstrategi genom att välja en optimal skärningsnyckel som begränsar antalet dokument som en genomströmningsoperation kommer att utsättas för.
• Öka storleken på MongoDB-instansen för att få plats med fler arbetsuppsättningar.

Se till att du har replikuppsättningar på plats

I databasvärlden är det inte idealiskt att förlita sig på en enda databas på grund av det faktum att en katastrof kan inträffa. Dessutom kan du förvänta dig en ökning av antalet användare till databasen och därför måste du säkerställa hög tillgänglighet av data. Replikering är ett avgörande tillvägagångssätt för att säkerställa hög tillgänglighet vid failover. MongoDB har förmågan att betjäna data geografiskt:vilket innebär att användare från olika platser kommer att betjänas av närmaste molnvärd som ett sätt att minska latensen för förfrågningar.

Om den primära noden misslyckas, kan de sekundära noderna välja en ny för att hänga med i skrivoperationer snarare än att applikationen har ett stillestånd under failover. Faktum är att vissa molnvärdsplattformar som är ganska omtänksamma med replikering inte stöder icke-replikerade MongoDB för produktionsmiljöer.

Aktivera journalföring

Så mycket som journalföring innebär en viss prestandaförsämring är det också viktigt. Journalföring förbättrar skrivning i förväg vilket innebär att om databasen misslyckas i processen att göra en uppdatering, skulle uppdateringen ha sparats någonstans och när den kommer till liv igen kan processen slutföras. Journalföring kan enkelt underlätta kraschåterställning och bör därför vara aktiverat som standard.

Se till att du ställer in en säkerhetskopieringsstrategi

Många företag misslyckas med att fortsätta efter dataförlust på grund av inga eller dåliga säkerhetskopieringssystem. Innan du distribuerar din databas i produktion, se till att du har använt någon av dessa säkerhetskopieringsstrategier:

• Mongodump :optimalt för små driftsättningar och vid tillverkning av säkerhetskopior filtrerade efter specifika behov.
• Kopiera underliggande :optimal för stora distributioner och effektiv metod för att ta fullständiga säkerhetskopior och återställa dem.
• MongoDB Management Service (MMS) :tillhandahåller kontinuerlig online backup för MongoDB som en helt hanterad tjänst. Optimalt för ett splittrat kluster och replikuppsättningar.

Säkerhetskopieringsfiler bör inte heller lagras i samma värdleverantör av databasen. Backup Ninja är en tjänst som kan användas för detta.

Var beredd på långsamma frågor

Det går knappt att inse långsamma frågor i utvecklingsmiljön på grund av det faktum att lite data är inblandade. Men det kanske inte är fallet i produktionen med tanke på att du kommer att ha många användare eller mycket data kommer att vara inblandade. Långsamma frågor kan uppstå om du misslyckades med att använda index eller använde en indexeringsnyckel som inte är optimal. Ändå bör vi hitta ett sätt som visar orsaken till långsamma frågor.

Vi beslutar därför att aktivera MongoDB Query Profiler. Så mycket som detta kan leda till prestandaförsämring, hjälper profileraren till att avslöja prestandaproblem. Innan du distribuerar din databas måste du aktivera profileraren för de samlingar som du misstänker kan ha långsamma frågor, särskilt de som involverar dokument med mycket inbäddning.

Anslut till ett övervakningsverktyg

Kapacitetsplanering är en mycket viktig uppgift i MongoDB. Du kommer också att behöva känna till hälsan hos din db vid varje given tidpunkt. För enkelhetens skull, genom att ansluta din databas till ett övervakningsverktyg sparar du lite tid på att inse vad du behöver förbättra din databas med tiden. Till exempel, en grafisk representation som indikerar långsam CPU-prestanda som ett resultat av ökade frågor kommer att leda dig att lägga till fler hårdvaruresurser till ditt system.

Övervakningsverktyg har också ett varningssystem via e-post eller korta meddelanden som bekvämt uppdaterar dig om vissa problem innan de hamnar i katastrof. Se därför till att din databas är ansluten till ett övervakningsverktyg i produktionen.

ClusterControl tillhandahåller gratis MongoDB-övervakning i Community Edition.

Implementera säkerhetsåtgärder

Databassäkerhet är en annan viktig funktion som måste beaktas strikt. Du måste skydda MongoDB-installationen i produktionen genom att se till att vissa säkerhetschecklistor före produktion följs. Några av övervägandena är:

• Konfigurera rollbaserad åtkomstkontroll
• Aktivera åtkomstkontroll och framtvinga autentisering
• Kryptering av inkommande och utgående anslutningar (TLS/SSL)
• Begränsa nätverksexponering
• Kryptera och skydda data
• Ha en spårplan för åtkomst och ändringar av databaskonfigurationer

Undvik externa injektioner genom att köra MongoDB med säkra konfigurationsalternativ. Till exempel att inaktivera skript på serversidan om du inte använder JavaScript-operationer på serversidan som mapReduce och $where. Använd JSON-validatorn för din insamlingsdata genom vissa moduler som mongoose för att säkerställa att alla lagrade dokument är i det giltiga BSON-formatet.

Tänk på maskinvara och programvara 

MongoDB har få hårdvaruförutsättningar, eftersom den är uttryckligen utformad med stor hänsyn till den nödvändiga hårdvaran. Följande är de viktigaste hårdvaruövervägandena för MongoDB som du måste överväga innan du distribuerar i produktion.

• Tilldela tillräckligt med  RAM och CPU
• Använd WiredTiger-lagringsmotorn. Designad för att använda filsystemcache och WiredTiger intern cache och därmed ökad prestanda. Till exempel, när du arbetar med ett system med 4 GB RAM använder WiredTiger-cachen 1,5 GB RAM ( 0,5 * (4 GB -1 GB) =1,5 GB) medan ett system med 1,2 GB RAM WiredTiger-cache bara använder 256 MB.
• NUMA hårdvara. Det finns många operativa problem som inkluderar långsam prestanda och hög systemprocessanvändning, därför bör man överväga att konfigurera en minnesinterfolieringspolicy.
• Disk och lagringssystem:Använd solid state-disk (SSD):MongoDB visar bättre  pris-prestanda-förhållande med SATA SSD

Slutsats

Databaser i produktionen är mycket avgörande för att säkerställa en smidig drift av ett företag och bör därför behandlas med många överväganden. Man bör fastställa några rutiner som kan bidra till att minska fel eller snarare ge ett enkelt sätt att hitta dessa fel. Dessutom är det tillrådligt att sätta upp ett varningssystem som visar databasens hälsa med tid för kapacitetsplanering och upptäckt av problem innan de minskar till katastrof.