YCSB : charges de travail A-F, exécution et limites

31 octobre 2026 8 min de lecture

YCSB, le Yahoo! Cloud Serving Benchmark, est un outil open source écrit en Java qui charge des enregistrements synthétiques dans une base de données, puis y exécute un mélange fixe de lectures, de mises à jour, d’insertions et de scans en mesurant le débit et la latence de chaque opération. Ses six charges de travail de base (core workloads), de A à F, sont des mélanges standard : le même test peut donc tourner sur Cassandra, MongoDB, Redis, HBase et des dizaines d’autres bases grâce à des bindings. Il mesure la base de données seule et ne dit donc rien des vraies requêtes de votre application ni de la latence que voient vos utilisateurs.

Nous n’avons pas exécuté YCSB pour cet article. Les faits proviennent de son dépôt GitHub, de son wiki et de son code source, vérifiés le 31 octobre 2026, et les appréciations sont les nôtres.

Charge de travail	Mélange d’opérations	Distribution des clés	Exemple donné par le wiki
A : mises à jour intensives	50 % lectures, 50 % mises à jour	zipfian	Stockage de sessions qui enregistre les actions récentes
B : surtout des lectures	95 % lectures, 5 % mises à jour	zipfian	Ajout de tags sur des photos
C : lecture seule	100 % lectures	zipfian	Cache de profils utilisateur
D : lecture des plus récents	95 % lectures, 5 % insertions	latest	Statuts publiés par les utilisateurs
E : plages courtes	95 % scans, 5 % insertions	zipfian (scans de 100 enregistrements au plus)	Fils de discussion
F : lecture-modification-écriture	50 % lectures, 50 % lecture-modification-écriture	zipfian	Base d’utilisateurs

Les mélanges viennent des fichiers du répertoire workloads et les exemples de la page Core Workloads (vérifié le 31 octobre 2026). Chaque fichier ne contient que 1 000 enregistrements et 1 000 opérations : assez pour déboguer une installation, beaucoup trop peu pour un benchmark.

Qu’est-ce que YCSB, et est-il encore maintenu ?

C’est un générateur de charge accompagné de charges de travail standard pour comparer des bases clé-valeur et de type « cloud serving », publié en open source par Yahoo! en 2010 sous licence Apache 2.0. La dernière version date d’octobre 2019, et le code reçoit encore de petits commits.

La page des publications cite l’article d’origine, « Benchmarking Cloud Serving Systems with YCSB », de Cooper, Silberstein, Tam, Ramakrishnan et Sears (ACM SoCC 2010). La version 0.17.0 est datée du 6 octobre 2019 et aucun tag plus récent n’existe, alors que l’historique des commits montre du travail en 2026, comme une option pour continuer après un échec d’insertion et une modification du binding Cloud Spanner le 20 octobre (vérifié le 31 octobre 2026). Ces changements ne sont disponibles qu’en compilant depuis les sources, ce qui demande Maven 3.

Comment lancer un benchmark YCSB ?

En deux phases qui partagent les mêmes propriétés : load insère recordcount enregistrements, puis run exécute operationcount opérations selon le mélange de la charge de travail. Vous indiquez le binding de votre base et passez le fichier de la charge de travail avec -P.

bin/ycsb load mongodb -s -P workloads/workloada \
  -p recordcount=1000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb
bin/ycsb run mongodb -s -P workloads/workloada \
  -p recordcount=1000000 -p operationcount=5000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb \
  -threads 32 -target 20000

La page Running a Workload détaille les pièges courants (vérifié le 31 octobre 2026). Le client ne crée jamais de table : vous associez d’abord usertable à ce dont votre base a besoin, par exemple une table dans MySQL ou un keyspace dans Cassandra. Les fichiers -P placés plus loin écrasent les précédents, et -p les écrase tous. La phase d’exécution doit recevoir le même recordcount que le chargement, car elle choisit ses clés dans l’ensemble des données. -s affiche une ligne d’état toutes les 10 secondes. Comme D et E insèrent des enregistrements, la page Core Workloads conseille de charger une fois avec le fichier de A, d’exécuter A, B, C, F et D, puis de supprimer les données et de recharger pour E.

Que règlent -threads et -target ?

-threads fixe le nombre de threads clients qui envoient des opérations (un par défaut), et -target plafonne le nombre total d’opérations par seconde. Sans cible, chaque thread envoie l’opération suivante dès que la précédente revient : une base plus lente reçoit donc tout simplement moins de charge.

C’est un modèle de charge fermé, et notre article sur le modèle de charge ouvert ou fermé explique ce qu’il masque. L’exemple du wiki, 10 threads pour une cible de 100 opérations par seconde, ne tient que tant que la latence moyenne reste sous 100 ms ; avec trop peu de threads, le débit atteint reste sous la cible. C’est la loi de Little : le nombre de threads divisé par la latence moyenne plafonne le débit. En lançant plusieurs cibles et en relevant la latence à chacune, vous obtenez la courbe décrite dans notre guide débit vs latence.

Comment lire la sortie de YCSB ?

À la fin de chaque phase, le client affiche un bloc [OVERALL] avec la durée et le débit, puis un bloc par type d’opération avec le nombre d’opérations, les latences moyenne, minimale, maximale et par percentile, et un décompte par code de retour.

Ces noms de champs viennent du code source de la 0.17.0 ; les valeurs sont des exemples fictifs :

[OVERALL], RunTime(ms), <total>
[OVERALL], Throughput(ops/sec), <rate>
[READ], Operations, <count>
[READ], AverageLatency(us), <value>
[READ], 95thPercentileLatency(us), <value>
[READ], 99thPercentileLatency(us), <value>
[READ], Return=OK, <count>

L’exemple de sortie du wiki affiche des millisecondes, mais la mesure HdrHistogram par défaut, dans la 0.17.0 comme dans le code actuel, indique des microsecondes, (us). La page Core Properties et la version 0.17.0 fixent les percentiles par défaut à 95 et 99, modifiables avec hdrhistogram.percentiles ; depuis avril 2025, la branche master ajoute 50, donc une compilation depuis les sources affiche aussi 50thPercentileLatency(us) (vérifié le 31 octobre 2026). Le README oriente vers le P99 et au-delà, rappelle qu’on ne peut pas faire la moyenne de percentiles et conseille, avec plusieurs clients, d’enregistrer des fichiers d’histogramme HDR avec hdrhistogram.fileoutput=true puis de les fusionner.

YCSB tient-il compte de la coordinated omission ?

Seulement si vous le demandez, et seulement avec -target. Par défaut, chaque latence est mesurée à partir du moment où l’opération est réellement envoyée : un blocage qui retarde les opérations suivantes se voit donc à peine.

Le code source des mesures prévoit une propriété measurement.interval qui accepte op (par défaut), intended ou both (vérifié le 31 octobre 2026). Avec une cible, chaque thread note le départ prévu de chaque opération ; intended mesure la latence à partir de ce moment, et both ajoute des blocs Intended- comme [Intended-READ] à côté des blocs habituels. Le wiki ne mentionne pas cette propriété : vérifiez le code de la version que vous compilez. Notre guide sur la coordinated omission explique pourquoi le départ prévu donne le chiffre honnête.

Quelles bases de données YCSB peut-il tester ?

Toute base qui dispose d’un binding. Le fichier de build de la branche master liste 46 modules de binding, parmi lesquels Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB et un binding JDBC générique.

La liste figure dans le pom.xml, et chaque répertoire de binding a son propre README avec les propriétés de connexion, comme mongodb.url pour le binding MongoDB (vérifié le 31 octobre 2026). D’après la page Running a Workload, une seule machine cliente suffit pour des clusters d’une dizaine de machines ; au-delà, vous lancez plusieurs clients, et la page Running a Workload in Parallel répartit la charge entre eux avec insertstart et insertcount.

Quand YCSB n’est-il pas le bon outil ?

Quand votre question porte sur votre application. La charge de travail de base écrit des enregistrements synthétiques, 10 champs d’une longueur de 100 chacun par défaut, au moyen d’opérations simples sur des clés : elle ne peut donc pas montrer comment vos propres requêtes, vos index ou le code de votre API se comportent sous charge.

Pour l’OLTP relationnel, pgbench exécute sur PostgreSQL un script inspiré de TPC-B et accepte vos propres scripts, et sysbench fournit des benchmarks Lua de type OLTP (tous deux vérifiés le 31 octobre 2026).
Pour la latence que voient les utilisateurs, mettez sous charge la couche HTTP ou API placée devant la base. LoadFocus, qui publie ce site, exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud sur des endpoints web et API. LoadFocus n’exécute pas YCSB.

FAQ

Quelles sont les charges de travail de base de YCSB ? Six mélanges standard : A compte 50 % de lectures et 50 % de mises à jour, B 95 % de lectures, C uniquement des lectures, D privilégie les enregistrements insérés le plus récemment, E fait des scans courts et F des lectures-modifications-écritures.

Quelle est la différence entre ycsb load et ycsb run ? La phase de chargement insère le nombre d’enregistrements fixé par recordcount. La phase d’exécution lance ensuite operationcount opérations selon le mélange de la charge de travail sur ces enregistrements et indique le débit et la latence.

YCSB est-il encore maintenu ? La dernière version, la 0.17.0, est sortie le 6 octobre 2019. Le dépôt reçoit encore des commits de temps en temps, le plus récent le 20 octobre 2026 : les correctifs récents demandent donc de compiler depuis les sources.

LoadFocus peut-il exécuter des benchmarks YCSB ? Non. LoadFocus n’exécute pas YCSB. Ses plans de test JMeter et ses scripts k6 visent des endpoints web et API, c’est-à-dire la couche placée devant la base de données.