loadtest.appvon LoadFocus

Anleitungen

YCSB: Workloads A-F, Ausführung und Grenzen

6 Min. Lesezeit

YCSB, der Yahoo! Cloud Serving Benchmark, ist ein Open-Source-Tool in Java, das synthetische Datensätze in einen Datenspeicher lädt und darauf dann eine feste Mischung aus Lese-, Update-, Insert- und Scan-Operationen ausführt, während es Durchsatz und Latenz pro Operation aufzeichnet. Seine sechs Core Workloads, A bis F, sind standardisierte Mischungen, sodass derselbe Test über Bindings gegen Cassandra, MongoDB, Redis, HBase und Dutzende weitere Datenbanken laufen kann. Es misst nur den Datenspeicher selbst und sagt daher nichts über die echten Abfragen Ihrer Anwendung oder über die Latenz, die Ihre Benutzer sehen.

Wir haben YCSB für diesen Artikel nicht selbst ausgeführt. Die Fakten stammen aus dem GitHub-Repository, dem Wiki und dem Quellcode, geprüft am 31. Oktober 2026; die Einschätzungen sind unsere eigenen.

WorkloadOperationsmixSchlüsselverteilungBeispiel aus dem Wiki
A: updatelastig50 % Lesen, 50 % UpdatezipfianSitzungsspeicher, der letzte Aktionen festhält
B: überwiegend Lesen95 % Lesen, 5 % UpdatezipfianFotos taggen
C: nur Lesen100 % LesenzipfianCache für Benutzerprofile
D: neueste lesen95 % Lesen, 5 % InsertlatestStatusmeldungen von Benutzern
E: kurze Bereiche95 % Scan, 5 % Insertzipfian (Scans über bis zu 100 Datensätze)Diskussionsverläufe
F: Read-Modify-Write50 % Lesen, 50 % Read-Modify-WritezipfianBenutzerdatenbank

Die Mischungen stammen aus den Dateien im Verzeichnis workloads, die Beispiele von der Seite Core Workloads (geprüft am 31. Oktober 2026). Jede Datei bringt nur 1.000 Datensätze und 1.000 Operationen mit: genug, um ein Setup zu debuggen, und viel zu wenig für einen Benchmark.

Was ist YCSB, und wird es noch gepflegt?

Es ist ein Workload-Generator mit einer Reihe standardisierter Workloads, um Key-Value- und “Cloud Serving”-Datenbanken zu vergleichen, 2010 von Yahoo! unter der Apache-2.0-Lizenz als Open Source veröffentlicht. Die letzte Version stammt vom Oktober 2019, der Code erhält aber weiterhin kleine Commits.

Die Seite mit Papers nennt das ursprüngliche Paper, “Benchmarking Cloud Serving Systems with YCSB” von Cooper, Silberstein, Tam, Ramakrishnan und Sears (ACM SoCC 2010). Das Release 0.17.0 ist auf den 6. Oktober 2019 datiert, und es gibt keinen neueren Tag; die Commit-Historie zeigt dagegen Arbeit aus 2026, etwa eine Option, nach einem fehlgeschlagenen Insert weiterzulaufen, und eine Änderung am Cloud-Spanner-Binding vom 20. Oktober (geprüft am 31. Oktober 2026). Diese Änderungen gibt es nur in einem eigenen Build aus dem Quellcode, und der braucht Maven 3.

Wie führen Sie einen YCSB-Benchmark aus?

In zwei Phasen mit denselben Properties: load fügt recordcount Datensätze ein, danach führt run operationcount Operationen aus dem Mix des Workloads aus. Sie nennen das Binding für Ihre Datenbank und übergeben die Workload-Datei mit -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

Die Seite Running a Workload erklärt die Details, über die viele stolpern (geprüft am 31. Oktober 2026). Der Client legt keine Tabellen an, Sie bilden usertable also vorher auf das ab, was Ihr Datenspeicher braucht, etwa eine Tabelle in MySQL oder einen Keyspace in Cassandra. Spätere -P-Dateien überschreiben frühere, und -p überschreibt alle. Die Laufphase braucht denselben recordcount wie die Ladephase, weil sie die Schlüssel aus dem gesamten Datenbestand wählt. -s gibt alle 10 Sekunden eine Statuszeile aus. Weil D und E Datensätze einfügen, empfiehlt die Seite Core Workloads, einmal mit der Datei von Workload A zu laden, A, B, C, F und D auszuführen, dann die Daten zu löschen und für E neu zu laden.

Was steuern -threads und -target?

-threads legt fest, wie viele Client-Threads Operationen senden (standardmäßig einer), und -target begrenzt die Operationen pro Sekunde insgesamt. Ohne Target sendet jeder Thread seine nächste Operation, sobald die vorige zurückkommt, eine langsamere Datenbank bekommt also einfach weniger Last.

Das ist ein geschlossenes Lastmodell, und unser Artikel zum offenen vs geschlossenen Lastmodell erklärt, was dieses Modell verdeckt. Das Wiki-Beispiel mit 10 Threads und einem Target von 100 Operationen pro Sekunde geht nur auf, solange die mittlere Latenz unter 100 ms bleibt; mit zu wenigen Threads bleibt die erreichte Rate unter dem Target. Hier wirkt Little’s Law: Threads geteilt durch die mittlere Latenz begrenzen den Durchsatz. Wenn Sie mehrere Targets fahren und jeweils die Latenz notieren, erhalten Sie die Kurve aus unserem Leitfaden zu Durchsatz vs. Latenz.

Wie lesen Sie die Ausgabe von YCSB?

Am Ende jeder Phase gibt der Client einen [OVERALL]-Block mit Laufzeit und Durchsatz aus, dann einen Block pro Operationstyp mit Anzahl, mittlerer, minimaler und maximaler Latenz, Perzentilen und einer Zählung pro Rückgabecode.

Diese Feldnamen stammen aus dem Quellcode von 0.17.0; die Werte sind Platzhalter:

[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>

Die Beispielausgabe im Wiki zeigt Millisekunden, die standardmäßige HdrHistogram-Messung meldet aber sowohl in 0.17.0 als auch im aktuellen Quellcode Mikrosekunden, (us). Die Seite Core Properties und Version 0.17.0 setzen die Standard-Perzentile auf 95 und 99, änderbar mit hdrhistogram.percentiles; seit April 2025 ergänzt der Master-Branch 50, ein Build aus dem Quellcode gibt also auch 50thPercentileLatency(us) aus (geprüft am 31. Oktober 2026). Die README lenkt den Blick auf P99 und darüber hinaus, warnt, dass sich Perzentile nicht mitteln lassen, und rät, bei mehreren Clients HDR-Histogramm-Dateien mit hdrhistogram.fileoutput=true zu speichern und zusammenzuführen.

Berücksichtigt YCSB Coordinated Omission?

Nur wenn Sie es verlangen, und nur mit gesetztem -target. Standardmäßig wird jede Latenz ab dem Moment gemessen, in dem die Operation tatsächlich gesendet wurde, sodass ein Stillstand, der die nachfolgenden Operationen verzögert, kaum sichtbar wird.

Der Mess-Quellcode kennt eine Property measurement.interval mit den Werten op (Standard), intended oder both (geprüft am 31. Oktober 2026). Mit Target merkt sich jeder Thread den geplanten Start jeder Operation; intended misst die Latenz ab diesem Zeitpunkt, und both fügt neben den üblichen Blöcken Intended--Blöcke wie [Intended-READ] hinzu. Im Wiki fehlt die Property, prüfen Sie also den Quellcode der Version, die Sie bauen. Unser Leitfaden zu Coordinated Omission erklärt, warum der geplante Start die ehrliche Zahl liefert.

Welche Datenbanken kann YCSB testen?

Jede, für die es ein Binding gibt. Die Build-Datei im Master-Branch listet 46 Binding-Module, darunter Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB und ein generisches JDBC-Binding.

Die Liste steht in der pom.xml, und jedes Binding-Verzeichnis hat eine eigene README mit den Verbindungs-Properties, etwa mongodb.url für das MongoDB-Binding (geprüft am 31. Oktober 2026). Laut der Seite Running a Workload reicht ein Client-Rechner für Cluster mit etwa 10 Maschinen; darüber starten Sie mehrere Clients, und die Seite Running a Workload in Parallel teilt die Last mit insertstart und insertcount zwischen ihnen auf.

Wann ist YCSB das falsche Tool?

Wenn Ihre Frage Ihre Anwendung betrifft. Der Core Workload schreibt synthetische Datensätze, standardmäßig 10 Felder mit je einer Länge von 100, über einfache Schlüsseloperationen und kann daher nicht zeigen, wie sich Ihre eigenen Abfragen, Indizes oder Ihr API-Code unter Last verhalten.

  • Für relationales OLTP führt pgbench ein an TPC-B angelehntes Skript gegen PostgreSQL aus und nimmt auch eigene Skripte an, und sysbench bringt OLTP-artige Lua-Benchmarks mit (beide geprüft am 31. Oktober 2026).
  • Für die Latenz, die Benutzer sehen, setzen Sie die HTTP- oder API-Schicht vor dem Datenspeicher unter Last. LoadFocus, der Herausgeber dieser Website, führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen gegen Web- und API-Endpoints aus. LoadFocus führt kein YCSB aus.

FAQ

Was sind die Core Workloads von YCSB? Sechs standardisierte Mischungen: A besteht zu 50 % aus Lese- und zu 50 % aus Update-Operationen, B zu 95 % aus Lesen, C nur aus Lesen, D bevorzugt die zuletzt eingefügten Datensätze, E führt kurze Scans aus, und F macht Read-Modify-Write.

Was ist der Unterschied zwischen ycsb load und ycsb run? Die Ladephase fügt so viele Datensätze ein, wie recordcount angibt. Die Laufphase führt dann operationcount Operationen aus dem Mix des Workloads auf diesen Datensätzen aus und meldet Durchsatz und Latenz.

Wird YCSB noch gepflegt? Die letzte Version, 0.17.0, erschien am 6. Oktober 2019. Das Repository erhält weiterhin gelegentlich Commits, zuletzt am 20. Oktober 2026, neuere Korrekturen erfordern also einen Build aus dem Quellcode.

Kann LoadFocus YCSB-Benchmarks ausführen? Nein. LoadFocus führt kein YCSB aus. Seine JMeter-Testpläne und k6-Skripte zielen auf Web- und API-Endpoints, also auf die Schicht vor dem Datenspeicher.

Weiterlesen

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.

LoadFocus team
Geschrieben vom LoadFocus-Team, den Leuten hinter einem Cloud-Lasttest-Dienst.