sql >> Databasteknik >  >> NoSQL >> MongoDB

Hur benchmarkar man MongoDB med YCSB?

Medan vi pratar om systemprestandaegenskaper begränsar de flesta DBaaS-leverantörer sig till att tillhandahålla information om hårdvaran som deras system tillhandahålls på. Det är verkligen svårt att tala exakt om de faktiska genomströmnings-/latensegenskaperna för en molnbaserad implementering med tanke på antalet variabler i ett sådant system. Virtualiserade miljöer, oförutsägbara arbetsbelastningar, nätverkslatenser, olika geografier är bara några av övervägandena.

Det är dock en bra idé att ha en rättvis förståelse för den faktiska prestandan för din MongoDB-distribution:så att du kan tillhandahålla korrekt baserat på dina applikationsbehov; så att du faktiskt kan jämföra olika DBaaS-leverantörer för att säkerställa att du får mest "bang for the buck".

Den här bloggen är en utgångspunkt för att köra några grundläggande prestandariktmärken på ditt MongoDB-kluster. Den går in på detaljerna om hur man konfigurerar och kör YCSB benchmarks tester och tolkar resultaten. Inspirationen till det kom från den senaste MongoDB-bloggen om prestandaförbättringar i MongoDB 3.0.

YCSB är en populär Java-specifikation och programsvit med öppen källkod utvecklad på Yahoo! för att jämföra den relativa prestandan för olika NoSQL-databaser. Dess arbetsbelastning används i olika jämförande studier av NoSQL-databaser.

Konfigurera YCSB

Detta och senare avsnitt guidar dig genom en steg-för-steg-process för att ställa in, konfigurera och köra YCSB-tester på ditt favoritsystem för DBaaS-leverantörer.

För att köra arbetsbelastningstester behöver du en klientdator, helst på samma geografiska plats som ditt MongoDB-kluster för att undvika fördröjningar över Internet. Välj en konfiguration som har en anständig mängd juice för att köra flera trådar för att ladda ditt Mongo-kluster på rätt sätt. Maskinen måste ha en ny version av Java, Maven och git installerad.

Steg:

  • Om Java, Maven eller git inte redan är installerat på ditt system, installera dem. Se dokumentationen för ditt specifika operativsystem. Se till att du installerar en Maven-version som är kompatibel med din Java-version. Testa att alla beroenden fungerar korrekt. För t.ex.
$ 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 föreslagits av Github-sidan på YCSB kan du hämta YCSBs tar-arkiv. Men vi rekommenderar att du bygger den från källan. Steg finns dokumenterade i MongoDB README av YCSB. Detta kommer att hjälpa oss att aktivera MongoDB-autentisering för din molnleverantör senare.
git clone git://github.com/brianfrankcooper/YCSB.git
cd YCSB
mvn clean package
  • Obs! Om ditt `mvn clean package` eller `mvn clean install` kommandot misslyckas på grund av fel i att hitta "mapkeeper"-paketet, ta bort eller kommentera de två instanserna av "mapkeeper"-posterna i pom.xml på rotnivån. Titta på detta Github-problem för mer information.
  • När bygget är framgångsrikt är du nu redo att köra YCSB-tester!

Aktivera autentisering

De flesta MongoDB-leverantörer tillhandahåller MongoDB-autentisering som standard och det finns inget sätt att inaktivera den. Tyvärr stöder YCSB för närvarande inte MongoDB-autentisering. Själva klientimplementeringen använder för det mesta, nu, föråldrade API-anrop. För att möta våra behov lade vi till en ny MongoDB-specifik YCSB-egenskap, 'mongodb.auth' tillsammans med några rader kod för att stödja det. Ändringarna är mycket enkla och en skillnad kan hittas här. Standard MongoDB-specifika YCSB-egenskaper listas här.

Bygg paketet igen med mvn igen när ändringarna är klara. Se avsnittet ovan om hur man bygger YCSB med Maven.

Köra testerna

Detta avsnitt av YCSB-wikin listar nästa och efterföljande aktiviteter i detaljer. Vi kommer att beskriva dem här kortfattat tillsammans med andra tips.

  • Nästa steg är att välja vilken typ av arbetsbelastning du vill köra. Ta dig tid att läsa och förstå avsnittet Core Workloads på YCSB-wikin. De sammanfattas här:
    • Arbetsbelastning A:Uppdatera tung arbetsbelastning:50/50 % mix av läs/skriv
    • Arbetsbelastning B:Läs mestadels arbetsbelastning:95/5 % mix av läser/skriver
    • Arbetsbelastning C:Skrivskyddad:100 % läser
    • Arbetsbelastning D:Läs den senaste arbetsbelastningen:Mer trafik på de senaste inläggen
    • Arbetsbelastning E:Korta intervall:Korta intervall baserade frågor
    • Arbetsbelastning F:Läs-modifiera-skriv:Läs, ändra och uppdatera befintliga poster
  • Självklart kan de individuella arbetsbelastningarna justeras med hjälp av kärnegenskaper. Du kanske vill välja en arbetsbelastning och justera egenskaperna så att de matchar något som matchar din applikations egenskaper. (Denna jämförande studie valde ut ett gäng intressanta "justerade" arbetsbelastningar). Se även MongoDB-bloggen som vi nämnde i det första avsnittet. (Vårt test tar upp arbetsbelastning A med standard läs-/uppdateringsförhållanden).
  • Välj antalet operationer (Property 'operationcount') så att själva testet körs under en lämplig tid. Tester som slutar inom 30 minuter kan inte vara bra indikatorer på systemets allmänna prestanda.
  • Välj lämpligt antal trådar som YCSB ska köra. Detta beror verkligen på hur bra dina klientmaskiner är, hur mycket belastning ditt MongoDB-kluster kan ta och hur representativt det är för din faktiska applikation. Vi kommer att köra våra benchmark-tester mot en rad trådar.
  • Kör laddningsfasen. Välj ett rekordantal (Property 'recordcount') att infoga i databasen som är nära det antal operationer du tänker köra på den. Välj ett lämpligt antal trådar så att insättningen inte tar för lång tid. För t.ex.
    ./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 flaggan indikerar att detta är en laddningskörning.
    • 's flaggan skriver ut status med 10 sekunders intervall
    • recordcount ' är satt till 10 miljoner.
    • threads ' ställer in antalet klienttrådar till 16.
    • mongodb.auth ' är egenskapen som vi skrev för att aktivera MongoDB-autentisering.
  • Kom ihåg att
    • Omdirigera stdout till en fil.
    • Använd "screen ’ eller en motsvarande metod så att din session inte går förlorad när du kör dessa operationer
  • När dataladdningsfasen är klar är du redo att köra dina arbetsbelastningar. För t.ex.
./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
  • Upprepa körningarna med olika antal trådar. Kom ihåg att omdirigera resultaten så att du kan jämföra dem senare. För t.ex. vi upprepade våra tester för 2, 4, 8, 16 och 32 trådar.

Analysera resultat

Det sista avsnittet på denna YCSB-wikisida talar om att analysera resultat. De mest intressanta informationsbitarna är den totala genomströmningen och 95/99 % procentuella latenser. Vanligtvis ökar man genom att öka antalet trådar genomströmningen tills den tidpunkt då vinsterna planar ut och latenserna blir oacceptabla. För t.ex. här är en plot av genomströmning och fördröjning kontra antal trådar för ett testsystem som vi försökte jämföra. Arbetsbelastning som valdes var arbetsbelastning A och cirka 3 miljoner operationer.

Man kan dra slutsatsen från grafen att 16 trådar förmodligen är den "sweet spot" från en belastningssynpunkt för denna MongoDB-server:Utöver den är genomströmningslinjen platt även för en exponentiell tillväxt i antal trådar medan latenserna växer till att bli oacceptabelt stora.

Några tips:

  • För en bättre bild av systemets prestanda över molnet, automatisera och upprepa dessa tester på olika punkter på dagen. Vi har märkt att prestandaegenskaper kan variera avsevärt under dagen.
  • När du jämför två potentiella DBaaS-leverantörer, se till att du väljer dina klientdatorer och DBaaS-klustret i samma geografi. Klustren bör ha liknande konfiguration. Kom också ihåg att köra testerna på olika tider på dygnet.

Vad händer nu

Här är några saker som vi har för avsikt att undersöka när vi gör mer arbete inom detta område:

  • Köra arbetsbelastningar från flera datorer parallellt:När man försöker ladda ett MongoDB-kluster med hög kapacitet räcker det inte med en enda klientdator. YCSB erbjuder för närvarande inget enkelt sätt att köra arbetsbelastningar från flera maskiner parallellt. Det kan dock göras manuellt. Detta kommer också att vara användbart när du försöker ladda data till ett stort kluster.
  • Storlek på datamängden:Storleken på databasen kontra minnet i MongoDB-systemen kommer att ändra egenskaperna för absolut genomströmning/latenser givet att MongoDB för större datamängder måste träffa disken .
  • Storlek på enskilda skivor:Det kommer att vara intressant för prestandaegenskaperna när skivstorlekarna är stora, särskilt när den är nära den maximala skivstorleken som stöds. Detta kan vara avgörande för applikationer som mestadels gör läs-modifiera-skriv tillbaka operationer (som Workload F).
  • Alternativa MongoDB-drivrutiner:Eftersom vi för närvarande var intresserade av att jämföra två olika DBaaS-leverantörer, försökte vi inte använda mer effektiva databasdrivrutiner. Uppenbarligen kan mycket bättre absoluta tal uppnås med de senaste och mer effektiva drivrutinerna. Detta kommer att vara intressant för applikationer som försöker extrahera det sista unset juice ur deras system. Den här bloggen talar om prestandaförbättringsmätningar genom YCSB genom att använda en asynkron MongoDB-drivrutin.
  • Alternativa benchmarkingverktyg:Sysbench för MongoDB är ett som vi tycker är intressant. Vi tittar på andra.


  1. Vilka är användningsfallen där Redis föredras framför Aerospike?

  2. StackExchange TimeoutException när du försöker infoga 750 objekt i 2 uppsättningar i redis

  3. Lombok - java.lang.StackOverflowError:null på toString-metoden

  4. MongoDB - Index används inte vid sortering och begränsning av avståndsfråga