Databasesystemer er afgørende komponenter i cyklussen af enhver succesfuld kørende applikation. Enhver organisation, der involverer dem, har derfor mandatet til at sikre en jævn ydelse af disse DBM'er gennem konsekvent overvågning og håndtering af mindre tilbageslag, før de eskalerer til enorme komplikationer, der kan resultere i nedetid for applikationer eller langsom ydeevne.
Du kan spørge, hvordan kan du vide, om databasen virkelig vil have et problem, mens den fungerer normalt? Nå, det er det, vi skal diskutere i denne artikel, og vi betegner det som benchmarking. Benchmarking er dybest set at køre nogle sæt forespørgsler med nogle testdata sammen med nogle ressourcebestemmelser for at afgøre, om disse parametre opfylder det forventede ydeevneniveau.
MongoDB har ikke en standard benchmarking-metodologi, og derfor skal vi løse i testforespørgsler på egen hardware. Så meget som du også kan få imponerende tal fra benchmark-processen, skal du være forsigtig, da dette kan være et andet tilfælde, når du kører din database med rigtige forespørgsler.
Ideen bag benchmarking er at få en generel idé om, hvordan forskellige konfigurationsmuligheder påvirker ydeevnen, hvordan du kan justere nogle af disse konfigurationer for at få maksimal ydeevne og estimere omkostningerne ved at forbedre denne implementering. Desuden vokser applikationer med tiden med hensyn til brugere, og sandsynligvis skal mængden af data, der skal betjenes, lave en vis kapacitetsplanlægning inden dette tidspunkt. Efter at have indset en stigende datatendens, er du nødt til at lave nogle benchmarking på, hvordan du vil opfylde kravene til disse enormt voksende data.
Overvejelser i Benchmarking MongoDB
- Vælg arbejdsbelastninger, der er en typisk repræsentation af nutidens moderne applikationer. Moderne applikationer bliver mere komplekse for hver dag, og dette overføres ned til datastrukturerne. Det vil sige, at datapræsentationen også har ændret sig med tiden, for eksempel ved at lagre simple felter til objekter og arrays. Det er ikke helt let at arbejde med disse data med standard eller rettere substandard databasekonfigurationer, da det kan eskalere til problemer som dårlig latency og dårlige gennemløbsoperationer, der involverer komplekse data. Når du kører et benchmark, bør du derfor bruge data, som er en klar præsentation af din applikation.
- Dobbelttjek på skrivninger. Sørg altid for, at alle dataskrivninger blev udført på en måde, der ikke tillod datatab. Dette er for at forbedre dataintegriteten ved at sikre, at dataene er konsistente og er mest anvendelige, især i produktionsmiljøet.
- Anvend datamængder, der er en repræsentation af "big data"-datasæt, som helt sikkert vil overstige RAM-kapaciteten for en individuel node. Når test-arbejdsbyrden er stor, vil det hjælpe dig med at forudsige fremtidige forventninger til din databaseydeevne, og derfor starte noget kapacitetsplanlægning tidligt nok.
Metode
Vores benchmark-test vil involvere nogle store lokationsdata, som kan downloades herfra, og vi vil bruge Robo3t-software til at manipulere vores data og indsamle de oplysninger, vi har brug for. Filen har mere end 500 dokumenter, som er ganske nok til vores test. Vi bruger MongoDB version 4.0 på en Ubuntu Linux 12.04 Intel Xeon-SandyBridge E3-1270-Quadcore 3.4GHz dedikeret server med 32GB RAM, Western Digital WD Caviar RE4 1TB roterende disk og Smart XceedIOPS 256GB SSD. Vi indsatte de første 500 dokumenter.
Vi kørte indsæt-kommandoerne nedenfor
db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:0})
db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:1})Skriv bekymring
Skrivebekymring beskriver det bekræftelsesniveau, der er anmodet om fra MongoDB for skriveoperationer i dette tilfælde til en selvstændig MongoDB. For en høj gennemløbsoperation, hvis denne værdi er sat til lav, vil skriveopkaldene være så hurtige, og dermed reducere forsinkelsen af anmodningen. På den anden side, hvis værdien er sat højt, så er skrivekaldene langsomme og øges følgelig på forespørgselsforsinkelsen. En simpel forklaring på dette er, at når værdien er lav, så er du ikke bekymret for muligheden for at miste nogle skrivninger i tilfælde af mongod crash, netværksfejl eller anonym systemfejl. En begrænsning i dette tilfælde vil være, du vil ikke være sikker på, om disse skrivninger lykkedes. På den anden side, hvis skrivebekymringen er høj, er der en fejlhåndteringsprompt, og dermed vil skrivningerne blive kvitteret. En bekræftelse er blot en kvittering for, at serveren har accepteret skrivningen til behandling.
Når skriveproblemet er sat højt 
Når skriveproblemet er sat lavt I vores test resulterede skrivebekymringen sat til lav i, at forespørgslen blev udført i min på 0,013 ms og maks. 0,017 ms. I dette tilfælde er den grundlæggende bekræftelse af skrivning deaktiveret, men man kan stadig få oplysninger om socket-undtagelser og enhver netværksfejl, der kan være blevet udløst.
Når skrivebekymringen er sat højt, tager det næsten dobbelt så lang tid at vende tilbage med udførelsestiden på 0,027 ms min og 0,031 ms max. Bekræftelsen i dette tilfælde er garanteret, men den har ikke 100 % nået diskjournalen. I dette tilfælde er chancerne for et skrivetab således 50 % på grund af vinduet på 100 ms, hvor journalen muligvis ikke tømmes til disken.
Journalist
Dette er en teknik, der sikrer, at data ikke tabes ved at give holdbarhed i tilfælde af fejl. Dette opnås gennem en fremskrivningslogning til journalfiler på disken. Det er mest effektivt, når skrivebekymringen er sat højt.
For en roterende disk er udførelsestiden med journalføring aktiveret en smule høj, for eksempel i vores test var den omkring 0,251 ms for samme operation ovenfor.
Udførelsestiden for en SSD er dog en smule lavere for den samme kommando. I vores test var det omkring 0,207 ms, men afhængigt af arten af data kunne dette nogle gange være 3 gange hurtigere end en roterende disk.
Når journalføring er aktiveret, bekræfter det, at der er skrevet til journalen og sikrer dermed dataholdbarhed. Følgelig vil skriveoperationen overleve en mongod nedlukning og sikrer, at skriveoperationen er holdbar.
For en operation med høj gennemstrømning kan du halve forespørgsler ved at indstille w=0. Ellers, hvis du har brug for at være sikker på, at data er blevet registreret eller rettere vil være i tilfælde af en tilbage-til-livet efter fejl, så skal du indstille w=1.
Severalnines Bliv en MongoDB DBA - Bring MongoDB to ProductionFå flere oplysninger om, hvad du skal vide for at implementere, overvåge, administrere og skala MongoDBDownload gratis Replikering
Anerkendelse af et skriveproblem kan aktiveres for mere end én node, der er den primære og en anden sekundær inden for et replikasæt. Dette vil være karakteriseret ved, hvilket heltal der er værdisat til skriveparameteren. For eksempel, hvis w =3, skal Mongod sikre, at forespørgslen modtager en bekræftelse fra hovedknuden og 2 slaver. Hvis du forsøger at indstille en værdi større end én, og noden endnu ikke er replikeret, vil det give en fejl om, at værten skal replikeres.
Replikering kommer med et tilbageslag i ventetiden, således at eksekveringstiden øges. For den simple forespørgsel ovenfor, hvis w=3, så stiger den gennemsnitlige udførelsestid til 270ms. En drivende faktor for dette er intervallet i responstid mellem noder påvirket af netværksforsinkelse, kommunikationsoverhead mellem de 3 noder og overbelastning. Desuden venter alle tre noder på, at hinanden er færdige, før de returnerer resultatet. I en produktionsimplementering skal du derfor ikke involvere så mange noder, hvis du vil forbedre ydeevnen. MongoDB er ansvarlig for at vælge, hvilke noder der skal godkendes, medmindre der er en specifikation i konfigurationsfilen ved hjælp af tags.
Snurrende disk vs Solid State Disk
Som nævnt ovenfor er SSD-disk ret hurtig end roterende disk afhængigt af de involverede data. Nogle gange kan det være 3 gange hurtigere og derfor værd at betale for, hvis det er nødvendigt. Det vil dog være dyrere at bruge en SSD, især når man har med store data at gøre. MongoDB har den fortjeneste, at den understøtter lagring af databaser i mapper, som kan monteres og dermed en chance for at bruge en SSD. At bruge en SSD og aktivere journalføring er en fantastisk optimering.
Konklusion
Eksperimentet var sikker på, at deaktiveret skrivebekymring resulterer i reduceret eksekveringstid af en forespørgsel på bekostning af chancerne for tab af data. På den anden side, når skriveproblemet er aktiveret, er udførelsestiden næsten 2 gange, når den er deaktiveret, men der er sikkerhed for, at data ikke går tabt. Desuden er vi i stand til at retfærdiggøre, at SSD er hurtigere end en roterende disk. Men for at sikre data holdbarhed i tilfælde af systemfejl, er det tilrådeligt at aktivere skriveproblemet. Når du aktiverer skrivebekymringen for et replikasæt, skal du ikke indstille tallet for stort, så det kan resultere i en vis forringet ydeevne fra applikationens ende.