Tout en parlant des caractéristiques de performance du système, la plupart des fournisseurs de DBaaS se limitent à fournir des informations sur le matériel sur lequel leurs systèmes sont provisionnés. Il est en effet difficile de parler avec précision des caractéristiques réelles de débit/latence d'un déploiement basé sur le cloud étant donné le nombre de variables dans un tel système. Les environnements virtualisés, les charges de travail imprévisibles, les latences du réseau, les différentes zones géographiques ne sont que quelques-unes des considérations.

Cependant, il est judicieux d'avoir une bonne compréhension des performances réelles de votre déploiement MongoDB :afin de pouvoir provisionner avec précision en fonction des besoins de votre application ; afin que vous puissiez réellement comparer différents fournisseurs de DBaaS pour vous assurer que vous en avez le plus "pour votre argent".

Ce blog est une introduction à l'exécution de certains tests de performances de base sur votre cluster MongoDB. Il explique en détail comment configurer et exécuter les tests de référence YCSB et interpréter les résultats. L'inspiration est venue du récent blog MongoDB sur l'amélioration des performances dans MongoDB 3.0.

YCSB est une spécification et une suite de programmes open source Java populaires développées chez Yahoo ! pour comparer les performances relatives de différentes bases de données NoSQL. Ses charges de travail sont utilisées dans diverses études comparatives de bases de données NoSQL.

Configuration du YCSB

Cette section et les suivantes vous guideront étape par étape pour installer, configurer et exécuter les tests YCSB sur votre système de fournisseur DBaaS préféré.

Afin d'exécuter des tests de charge de travail, vous aurez besoin d'une machine cliente, de préférence dans le même emplacement géographique que votre cluster MongoDB pour éviter les latences sur Internet. Sélectionnez une configuration qui a une quantité décente de jus pour exécuter plusieurs threads afin de charger votre cluster Mongo de manière appropriée. La machine doit avoir une version récente de Java, Maven et git installée.

Étapes :

Si Java, Maven ou git ne sont pas déjà installés sur votre système, installez-les. Reportez-vous à la documentation disponible pour votre système d'exploitation spécifique. Assurez-vous d'installer une version de Maven compatible avec votre version de Java. Vérifiez que toutes les dépendances fonctionnent correctement. Par exemple

$ 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)

Comme suggéré par la page Github de YCSB, vous pouvez obtenir l'archive tar de YCSB. Mais nous vous recommandons de le construire à partir de la source. Les étapes sont documentées dans le fichier README MongoDB de YCSB. Cela nous aidera à activer ultérieurement l'authentification MongoDB pour votre fournisseur de cloud.

git clone git://github.com/brianfrankcooper/YCSB.git
cd YCSB
mvn clean package

Remarque :Si votre `mvn clean package` ou `mvn clean install` La commande échoue en raison d'erreurs de localisation du package "mapkeeper". Supprimez ou commentez les 2 instances des entrées "mapkeeper" dans le fichier pom.xml. au niveau racine. Consultez ce numéro Github pour plus d'informations.
Une fois la construction réussie, vous êtes maintenant prêt à exécuter les tests YCSB !

Activer l'authentification

La plupart des fournisseurs MongoDB fournissent l'authentification MongoDB par défaut et il n'y a aucun moyen de la désactiver. Malheureusement, YCSB ne prend actuellement pas en charge l'authentification MongoDB. L'implémentation du client elle-même utilise principalement, désormais, des appels d'API obsolètes. Pour répondre à nos besoins, nous avons ajouté une nouvelle propriété YCSB spécifique à MongoDB, 'mongodb.auth' avec quelques lignes de code pour le supporter. Les changements sont très simples et un diff peut être trouvé ici. Les propriétés YCSB spécifiques à MongoDB par défaut sont répertoriées ici.

Construire à nouveau le package en utilisant mvn à nouveau une fois les modifications terminées. Reportez-vous à la section ci-dessus pour savoir comment créer YCSB à l'aide de Maven.

Exécution des tests

Cette section du wiki YCSB répertorie en détail les activités suivantes et suivantes. Nous les décrirons ici brièvement avec d'autres pointeurs.

L'étape suivante consiste à choisir le type de charge de travail que vous souhaitez exécuter. Prenez le temps de lire et de comprendre la section Core Workloads du wiki YCSB. Ils sont résumés ici :
- Charge de travail A :charge de travail importante pour la mise à jour :mélange 50/50 % de lectures/écritures
- Charge de travail B :lecture principalement de la charge de travail :95/5 % de lectures/écritures
- Charge de travail C :lecture seule :100 % de lectures
- Charge de travail D :Lire la dernière charge de travail :plus de trafic sur les insertions récentes
- Charge de travail E :plages courtes :requêtes basées sur des plages courtes
- Charge de travail F :lecture-modification-écriture :lecture, modification et mise à jour des enregistrements existants

Évidemment, les charges de travail individuelles peuvent être modifiées à l'aide des propriétés principales. Vous pouvez choisir une charge de travail et modifier les propriétés pour qu'elles correspondent à quelque chose qui correspond aux caractéristiques de votre application. (Cette étude comparative a choisi un tas de charges de travail "modifiées" intéressantes). Reportez-vous également au blog MongoDB que nous avons mentionné dans la première section. (Notre test détectera la charge de travail A avec des ratios de lecture/mise à jour par défaut).
Choisissez le nombre d'opérations (propriété 'operationcount') afin que le test lui-même s'exécute pendant une durée appropriée. Les tests qui se terminent en moins de 30 minutes ne peuvent pas être de bons indicateurs des performances générales du système.
Choisissez le nombre approprié de threads que YCSB doit exécuter. Cela dépend vraiment de la qualité de vos machines clientes, de la charge que votre cluster MongoDB peut supporter et de sa représentativité de votre application réelle. Nous exécuterons nos tests de référence sur une gamme de threads.
Exécutez la phase de chargement. Choisissez un nombre d'enregistrements (Property 'recordcount') à insérer dans la base de données qui est proche du nombre d'opérations que vous avez l'intention d'exécuter dessus. Choisissez un nombre approprié de fils pour que l'insertion ne prenne pas trop de temps. Par exemple
```
./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 ' indique qu'il s'agit d'une exécution de chargement.
- ‘s ‘ le drapeau imprime l'état à intervalles de 10 secondes
- ‘recordcount ‘ est défini sur 10 millions.
- ‘threads ‘ définit le nombre de threads clients sur 16.
- ‘mongodb.auth ‘ est la propriété que nous avons écrite pour activer l'authentification MongoDB.
N'oubliez pas de
- Redirigez la sortie standard vers un fichier.
- Utiliser 'screen ' ou une méthode équivalente afin que votre session ne soit pas perdue lors de l'exécution de ces opérations
Une fois la phase de chargement des données terminée, vous êtes prêt à exécuter vos charges de travail. Par exemple

./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

Répétez les exécutions avec différents nombres de threads. N'oubliez pas de rediriger les résultats afin de pouvoir les comparer ultérieurement. Par ex. nous avons répété nos tests pour 2, 4, 8, 16 et 32 fils.

Analyse des résultats

La dernière section de cette page wiki du YCSB traite de l'analyse des résultats. Les informations les plus intéressantes sont le débit global et les latences centiles 95/99 %. Habituellement, l'augmentation du nombre de threads augmente le débit jusqu'à ce que les gains s'aplatissent et que les latences deviennent inacceptables. Par ex. voici un graphique du débit et de la latence par rapport au nombre de threads pour un système de test que nous essayions de comparer. La charge de travail sélectionnée était la charge de travail A et environ 3 millions d'opérations.

On peut conclure à partir du graphique que 16 threads sont probablement le "sweet spot" du point de vue de la charge pour ce serveur MongoDB :au-delà, la ligne de débit est plate même pour une croissance exponentielle du nombre de threads tandis que les latences deviennent inacceptables.

Quelques conseils :

Pour une meilleure image des performances du système sur le cloud, automatisez puis répétez ces tests à différents moments de la journée. Nous avons remarqué que les caractéristiques de performances peuvent varier considérablement au cours de la journée.
Lorsque vous comparez deux fournisseurs DBaaS potentiels, assurez-vous de sélectionner vos machines clientes et le cluster DBaaS dans la même zone géographique. Les clusters doivent avoir une configuration similaire. N'oubliez pas non plus d'exécuter les tests à différents moments de la journée.

Et ensuite

Voici quelques éléments sur lesquels nous avons l'intention d'enquêter à mesure que nous approfondissons nos travaux dans ce domaine :

Exécuter des charges de travail à partir de plusieurs machines en parallèle :lorsque vous tentez de charger un cluster MongoDB haute capacité, une seule machine cliente ne suffira pas. YCSB ne fournit actuellement aucun moyen simple d'exécuter des charges de travail à partir de plusieurs machines en parallèle. Cependant, cela peut être fait manuellement. Cela sera également utile lorsque vous tenterez de charger des données dans un grand cluster.
Taille de l'ensemble de données :la taille de la base de données par rapport à la mémoire des systèmes MongoDB modifiera les caractéristiques absolues de débit/latence étant donné que pour les ensembles de données plus volumineux, MongoDB devra atteindre le disque .
Taille des enregistrements individuels :il sera intéressant pour les caractéristiques de performance lorsque les tailles d'enregistrement sont importantes, en particulier lorsqu'elles sont proches de la taille d'enregistrement maximale prise en charge. Cela peut être crucial pour les applications qui effectuent principalement des opérations de lecture-modification-réécriture (comme Workload F).
Pilotes MongoDB alternatifs :étant donné que nous étions actuellement intéressés par la comparaison de deux fournisseurs DBaaS différents, nous n'avons pas tenté d'utiliser des pilotes de base de données plus efficaces. Évidemment, de bien meilleurs chiffres absolus peuvent être obtenus avec les pilotes les plus récents et les plus efficaces. Ce sera intéressant pour les applications essayant d'extraire la dernière once de jus de leur système. Ce blog parle des mesures d'amélioration des performances via YCSB en utilisant un pilote MongoDB asynchrone.
Outils d'analyse comparative alternatifs :Sysbench pour MongoDB est celui que nous trouvons intéressant. Nous regardons les autres.