sql >> Database teknologi >  >> NoSQL >> MongoDB

Hvordan benchmarker man MongoDB med YCSB?

Mens de taler om systemydelseskarakteristika, begrænser de fleste DBaaS-udbydere sig til at give information om den hardware, som deres systemer er klargjort på. Det er faktisk svært at tale præcist om de faktiske gennemløbs-/latenskarakteristika for en cloud-baseret implementering givet antallet af variabler i et sådant system. Virtualiserede miljøer, uforudsigelige arbejdsbelastninger, netværksforsinkelser, forskellige geografier er kun nogle af overvejelserne.

Det er dog en god idé at have en rimelig forståelse af den faktiske ydeevne af din MongoDB-implementering:så du kan klargøre nøjagtigt baseret på dine applikationsbehov; så du rent faktisk kan sammenligne forskellige DBaaS-udbydere for at sikre, at du får mest muligt "bang for the buck".

Denne blog er en primer om at køre nogle grundlæggende ydeevnebenchmarks på din MongoDB-klynge. Det går i detaljer om, hvordan man konfigurerer og kører YCSB benchmarks-tests og fortolker resultaterne. Inspirationen til det kom fra den nylige MongoDB-blog om præstationsforbedringer i MongoDB 3.0.

YCSB er en populær Java open source specifikation og programpakke udviklet hos Yahoo! at sammenligne den relative ydeevne af forskellige NoSQL-databaser. Dens arbejdsbelastninger bruges i forskellige komparative undersøgelser af NoSQL-databaser.

Opsætning af YCSB

Dette og senere afsnit vil guide dig gennem en trin-for-trin-proces for at opsætte, konfigurere og køre YCSB-test på dit foretrukne DBaaS-udbydersystem.

For at køre arbejdsbelastningstest skal du bruge en klientmaskine, helst på samme geografiske placering som din MongoDB-klynge for at undgå forsinkelser over internettet. Vælg en konfiguration, der har en anstændig mængde juice til at køre flere tråde for at indlæse din Mongo-klynge korrekt. Maskinen skal have en nyere version af Java, Maven og git installeret.

Trin:

  • Hvis Java, Maven eller git ikke allerede er installeret på dit system, så installer dem. Se den tilgængelige dokumentation for dit specifikke OS. Sørg for, at du installerer en Maven-version, der er kompatibel med din Java-version. Test, at alle afhængigheder fungerer korrekt. For f.eks.
$ javac -version
javac 1.8.0_25
$ mvn -version
Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c; 2015-03-14T01:40:27+05:30)
Maven home: /usr/local/Cellar/maven/3.3.1/libexec
Java version: 1.8.0_25, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.10.2", arch: "x86_64", family: "mac"
$ git --version
git version 1.9.5 (Apple Git-50.3)
  • Som foreslået af Github-siden på YCSB kunne du få YCSB's tar-arkiv. Men vi anbefaler at bygge det fra kilden. Trin er dokumenteret i MongoDB README af YCSB. Dette vil hjælpe os med at aktivere MongoDB-godkendelse for din cloud-udbyder senere.
git clone git://github.com/brianfrankcooper/YCSB.git
cd YCSB
mvn clean package
  • Bemærk:Hvis din `mvn clean package` eller `mvn clean install` kommandoen mislykkes på grund af fejl i at lokalisere "mapkeeper"-pakken, slet eller kommenter de 2 forekomster af "mapkeeper"-posterne i pom.xml på rodniveau. Se dette Github-problem for mere information.
  • Når buildet er vellykket, er du nu klar til at køre YCSB-test!

Aktivering af godkendelse

De fleste MongoDB-udbydere leverer MongoDB-godkendelse som standard, og der er ingen måde at deaktivere den på. Desværre understøtter YCSB i øjeblikket ikke MongoDB-godkendelse. Selve klientimplementeringen bruger for det meste, nu, forældede API-kald. For at imødekomme vores behov har vi tilføjet en ny MongoDB-specifik YCSB-ejendom, 'mongodb.auth' sammen med et par linjer kode til at understøtte det. Ændringerne er meget enkle, og en forskel kan findes her. Standard MongoDB-specifikke YCSB-egenskaber er angivet her.

Byg pakken igen ved hjælp af mvn igen, når ændringerne er gennemført. Se afsnittet ovenfor om, hvordan man bygger YCSB ved hjælp af Maven.

Kørsel af testene

Denne sektion af YCSB-wikien viser næste og efterfølgende aktiviteter i detaljer. Vi vil beskrive dem kort her sammen med andre pointer.

  • Det næste trin er at vælge den type arbejdsbyrde, du vil køre. Tag dig tid til at læse og forstå afsnittet Core Workloads på YCSB-wikien. De er opsummeret her:
    • Arbejdsbelastning A:Opdater tung arbejdsbyrde:50/50 % blanding af læsninger/skrivninger
    • Arbejdsbelastning B:Læser hovedsagelig arbejdsmængde:95/5 % blanding af læsninger/skrivninger
    • Workload C:Skrivebeskyttet:100 % læser
    • Arbejdsbelastning D:Læs den seneste arbejdsbyrde:Mere trafik på de seneste indlæg
    • Workload E:Short ranges:Short range-baserede forespørgsler
    • Workload F:Read-modify-write:Læs, modificer og opdater eksisterende poster
  • Det er klart, at de individuelle arbejdsbelastninger kan justeres ved hjælp af kerneegenskaber. Du vil måske vælge en arbejdsbelastning og tilpasse egenskaberne, så de matcher noget, der matcher din applikations egenskaber. (Denne sammenlignende undersøgelse valgte en masse interessante "tweakede" arbejdsbelastninger). Se også MongoDB-bloggen, vi nævnte i det første afsnit. (Vores test vil opfange Workload A med standard læse/opdateringsforhold).
  • Vælg antallet af operationer (Egenskab 'operationcount'), så selve testen kører i et passende tidsrum. Tests, der afsluttes inden for 30 minutter, kan ikke være gode indikatorer for systemets generelle ydeevne.
  • Vælg det passende antal tråde, som YCSB skal køre. Dette afhænger virkelig af, hvor gode dine klientmaskiner er, hvor meget belastning din MongoDB-klynge kan tage, og hvor repræsentativ den er for din faktiske applikation. Vi vil køre vores benchmark-test mod en række tråde.
  • Kør indlæsningsfasen. Vælg en registreringsantal (Ejendom 'recordcount') til at indsætte i databasen, der er tæt på antallet af operationer, du har til hensigt at køre på den. Vælg et passende antal tråde, så indsættelsen ikke tager for lang tid. For f.eks.
    ./bin/ycsb load mongodb -s -P workloads/workloada -p recordcount=10000000 -threads 16 -p
     mongodb.url="mongodb://user:[email protected]:9999,server2.example.com:9999/dbname" -p 
    mongodb.auth="true"
    
    • load ' flag angiver, at dette er en indlæsningskørsel.
    • s ' flag udskriver status med 10 sekunders intervaller
    • recordcount ' er sat til 10 mio.
    • threads ' indstiller antallet af klienttråde til 16.
    • mongodb.auth ' er den egenskab, som vi skrev for at aktivere MongoDB-godkendelse.
  • Husk at
    • Omdiriger stdout'en til en fil.
    • Brug 'screen ’ eller en tilsvarende metode, så din session ikke går tabt, mens du kører disse operationer
  • Når dataindlæsningsfasen er afsluttet, er du klar til at køre dine arbejdsbelastninger. For f.eks.
./bin/ycsb run mongodb -s -P workloads/workloada -p 
mongodb.url="mongodb://user:[email protected]:9999,server2.example.com:9999/dbname" -p
 mongodb.auth="true" -p operationcount=10000000 -threads 2
  • Gentag kørslerne med forskellige antal tråde. Husk at omdirigere resultaterne, så du kan sammenligne dem senere. For f.eks. vi gentog vores test for 2, 4, 8, 16 og 32 tråde.

Analyse af resultater

Den sidste sektion af denne YCSB-wikiside taler om at analysere resultater. De mest interessante informationer er den overordnede gennemstrømning og 95/99 % Percentile Latencies. Sædvanligvis øger antallet af tråde gennemløbet, indtil det tidspunkt, hvor gevinsterne flades ud, og latenserne bliver uacceptable. For f.eks. her er et plot af gennemløb og ventetid versus # af tråde for et testsystem, vi forsøgte at benchmarke. Den valgte arbejdsbyrde var Workload A og omkring 3 millioner operationer.

Det kan konkluderes ud fra grafen, at 16 tråde sandsynligvis er det "sweet spot" fra et belastningssynspunkt for denne MongoDB-server:Ud over det er gennemstrømningslinjen flad selv for en eksponentiel vækst i # af tråde, mens latenserne vokser til at blive uacceptabelt store.

Et par tips:

  • For et bedre billede af systemets ydeevne over skyen skal du automatisere og derefter gentage disse tests på forskellige tidspunkter på dagen. Vi har bemærket, at præstationskarakteristika kan variere betydeligt i løbet af dagen.
  • Når du sammenligner to potentielle DBaaS-udbydere, skal du sikre dig, at du vælger dine klientmaskiner og DBaaS-klyngen i samme geografi. Klyngerne skal have en lignende konfiguration. Husk også at køre testene på forskellige tidspunkter på dagen.

Hvad er det næste

Her er et par ting, som vi har til hensigt at undersøge, efterhånden som vi udfører mere arbejde på dette område:

  • Kørsel af arbejdsbelastninger fra flere maskiner parallelt:Når du forsøger at indlæse en MongoDB-klynge med høj kapacitet, vil en enkelt klientmaskine ikke være tilstrækkelig. YCSB giver i øjeblikket ingen nem måde at køre arbejdsbelastninger fra flere maskiner parallelt på. Det kan dog gøres manuelt. Dette vil også være nyttigt, når du forsøger at indlæse data i en stor klynge.
  • Størrelse på datasættet:Størrelsen af ​​databasen i forhold til hukommelsen i MongoDB-systemerne vil ændre karakteristika for absolut gennemløb/latenser, da MongoDB for større datasæt bliver nødt til at ramme disken .
  • Størrelse på individuelle poster:Det vil være interessant for ydeevneegenskaberne, når pladestørrelserne er store, især når den er tæt på den maksimalt understøttede pladestørrelse. Dette kan være afgørende for programmer, der for det meste udfører læs-modificere-skriv tilbage-operationer (såsom Workload F).
  • Alternative MongoDB-drivere:Da vi i øjeblikket var interesseret i at sammenligne to forskellige DBaaS-udbydere, forsøgte vi ikke at bruge mere effektive databasedrivere. Det er klart, at der kan opnås meget bedre absolutte tal med de nyeste og mere effektive drivere. Dette vil være interessant for applikationer, der forsøger at trække den sidste ounce juice ud af deres system. Denne blog taler om præstationsforbedringsmålinger gennem YCSB ved at bruge en asynkron MongoDB-driver.
  • Alternative benchmarkingværktøjer:Sysbench til MongoDB er et, som vi finder interessant. Vi kigger på andre.


  1. MongoDB $runde

  2. Brug af Cloudera Data Engineering til at analysere dataene i lønsedlens beskyttelsesprogram

  3. Start mongod fork, FEJL:underordnet proces mislykkedes, afsluttet med fejl nummer 1

  4. Mongodb find oprettede resultater efter dato i dag