YCSB: cargas de trabajo A-F, ejecución y límites

YCSB, el Yahoo! Cloud Serving Benchmark, es una herramienta open source escrita en Java que carga registros sintéticos en una base de datos y después ejecuta sobre ellos una mezcla fija de lecturas, actualizaciones, inserciones y escaneos mientras registra el rendimiento y la latencia de cada operación. Sus seis cargas de trabajo básicas (core workloads), de la A a la F, son mezclas estándar, así que la misma prueba puede correr contra Cassandra, MongoDB, Redis, HBase y decenas de bases más gracias a los bindings. Mide solo la base de datos, por lo que no dice nada de las consultas reales de tu aplicación ni de la latencia que ven tus usuarios.

No hemos ejecutado YCSB para este artículo. Los datos salen de su repositorio de GitHub, su wiki y su código fuente, comprobados el 31 de octubre de 2026, y las valoraciones son nuestras.

Las mezclas vienen de los archivos del directorio workloads y los ejemplos de la página Core Workloads (comprobado el 31 de octubre de 2026). Cada archivo trae solo 1.000 registros y 1.000 operaciones: suficiente para depurar una instalación y demasiado pocos para un benchmark.

¿Qué es YCSB y sigue teniendo mantenimiento?

Es un generador de carga con un conjunto de cargas de trabajo estándar para comparar bases clave-valor y de tipo “cloud serving”, que Yahoo! publicó como open source en 2010 con licencia Apache 2.0. La última versión es de octubre de 2019, y el código todavía recibe pequeños commits.

La página de publicaciones cita el artículo original, “Benchmarking Cloud Serving Systems with YCSB”, de Cooper, Silberstein, Tam, Ramakrishnan y Sears (ACM SoCC 2010). La versión 0.17.0 tiene fecha del 6 de octubre de 2019 y no existe ningún tag posterior, mientras que el historial de commits muestra trabajo de 2026, como una opción para seguir adelante cuando falla una inserción y un cambio en el binding de Cloud Spanner del 20 de octubre (comprobado el 31 de octubre de 2026). Esos cambios solo llegan si compilas desde el código fuente, y para eso necesitas Maven 3.

¿Cómo se ejecuta un benchmark con YCSB?

En dos fases que comparten las mismas propiedades: load inserta recordcount registros y después run ejecuta operationcount operaciones con la mezcla de la carga de trabajo. Indicas el binding de tu base de datos y pasas el archivo de la carga de trabajo con -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 página Running a Workload recoge los detalles en los que más gente tropieza (comprobado el 31 de octubre de 2026). El cliente nunca crea tablas, así que antes tienes que asociar usertable a lo que necesite tu almacén de datos, por ejemplo una tabla en MySQL o un keyspace en Cassandra. Los archivos -P posteriores sobrescriben a los anteriores, y -p los sobrescribe a todos. La fase run necesita el mismo recordcount que la carga, porque elige las claves entre todo el conjunto de datos. -s muestra una línea de estado cada 10 segundos. Como D y E insertan registros, la página Core Workloads aconseja cargar una vez con el archivo de A, ejecutar A, B, C, F y D, y después borrar los datos y volver a cargar para E.

¿Qué controlan -threads y -target?

-threads fija cuántos hilos cliente envían operaciones (uno por defecto) y -target limita el total de operaciones por segundo. Sin objetivo, cada hilo envía la siguiente operación en cuanto vuelve la anterior, así que una base de datos más lenta simplemente recibe menos carga.

Es un modelo de carga cerrado, y nuestro artículo sobre el modelo de carga abierto vs cerrado explica lo que oculta ese modelo. El ejemplo de la wiki, 10 hilos con un objetivo de 100 operaciones por segundo, solo se cumple mientras la latencia media se mantenga por debajo de 100 ms; con pocos hilos, el ritmo alcanzado se queda por debajo del objetivo. Es la ley de Little: los hilos divididos entre la latencia media ponen techo al rendimiento. Si lanzas varios objetivos y anotas la latencia de cada uno, obtienes la curva de nuestra guía sobre rendimiento vs latencia.

¿Cómo se lee la salida de YCSB?

Al final de cada fase, el cliente imprime un bloque [OVERALL] con el tiempo de ejecución y el rendimiento, y luego un bloque por tipo de operación con el recuento, las latencias media, mínima, máxima y por percentil, y un recuento por código de retorno.

Estos nombres de campo salen del código fuente de la 0.17.0; los valores son marcadores de posición:

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

La salida de ejemplo de la wiki muestra milisegundos, pero la medición HdrHistogram por defecto, tanto en la 0.17.0 como en el código actual, da microsegundos, (us). La página Core Properties y la versión 0.17.0 fijan los percentiles por defecto en 95 y 99, que puedes cambiar con hdrhistogram.percentiles; desde abril de 2025 la rama master añade el 50, así que una compilación desde el código fuente también muestra 50thPercentileLatency(us) (comprobado el 31 de octubre de 2026). El README dirige la atención al P99 y más allá, advierte que los percentiles no se pueden promediar y recomienda, si usas varios clientes, guardar archivos de histograma HDR con hdrhistogram.fileoutput=true y combinarlos.

¿Tiene en cuenta YCSB la coordinated omission?

Solo si lo pides, y solo con -target. Por defecto, cada latencia se mide desde el momento en que la operación se envía de verdad, así que un atasco que retrasa las operaciones que vienen detrás apenas se nota.

El código fuente de las mediciones incluye una propiedad measurement.interval que acepta op (por defecto), intended o both (comprobado el 31 de octubre de 2026). Con un objetivo, cada hilo anota el inicio previsto de cada operación; intended mide la latencia desde ese punto y both añade bloques Intended- como [Intended-READ] junto a los habituales. La wiki no menciona la propiedad, así que revisa el código de la versión que compiles. Nuestra guía sobre la coordinated omission explica por qué el inicio previsto da la cifra honesta.

¿Qué bases de datos puede probar YCSB?

Cualquiera que tenga un binding. El archivo de build de la rama master lista 46 módulos de binding, entre ellos Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB y un binding JDBC genérico.

La lista está en el pom.xml, y cada directorio de binding tiene su propio README con las propiedades de conexión, como mongodb.url en el binding de MongoDB (comprobado el 31 de octubre de 2026). Según la página Running a Workload, una sola máquina cliente basta para clústeres de unas 10 máquinas; por encima, arrancas varios clientes, y la página Running a Workload in Parallel reparte la carga entre ellos con insertstart e insertcount.

¿Cuándo no es YCSB la herramienta adecuada?

Cuando tu pregunta es sobre tu aplicación. La carga de trabajo básica escribe registros sintéticos, 10 campos con una longitud de 100 cada uno por defecto, mediante operaciones simples por clave, así que no puede mostrar cómo se comportan bajo carga tus propias consultas, tus índices o el código de tu API.

• Para OLTP relacional, pgbench ejecuta contra PostgreSQL un script inspirado en TPC-B y acepta tus propios scripts, y sysbench incluye benchmarks en Lua de tipo OLTP (ambos comprobados el 31 de octubre de 2026).
• Para la latencia que ven los usuarios, pon bajo carga la capa HTTP o de API que hay delante de la base de datos. LoadFocus, que publica este sitio, ejecuta planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube contra endpoints web y de API. LoadFocus no ejecuta YCSB.

FAQ

¿Cuáles son las cargas de trabajo básicas de YCSB? Seis mezclas estándar: A tiene un 50 % de lecturas y un 50 % de actualizaciones, B un 95 % de lecturas, C solo lecturas, D favorece los registros insertados más recientemente, E hace escaneos cortos y F hace operaciones de lectura-modificación-escritura.

¿Qué diferencia hay entre ycsb load y ycsb run? La fase load inserta el número de registros que fija recordcount. La fase run ejecuta después operationcount operaciones con la mezcla de la carga de trabajo sobre esos registros e informa del rendimiento y la latencia.

¿YCSB sigue teniendo mantenimiento? La última versión, la 0.17.0, salió el 6 de octubre de 2019. El repositorio todavía recibe commits de vez en cuando, el más reciente el 20 de octubre de 2026, así que las correcciones nuevas exigen compilar desde el código fuente.

¿Puede LoadFocus ejecutar benchmarks de YCSB? No. LoadFocus no ejecuta YCSB. Sus planes de prueba JMeter y sus scripts de k6 se dirigen a endpoints web y de API, es decir, a la capa que hay delante del almacén de datos.

Lecturas relacionadas

• Coordinated omission: qué es y cómo evitarla
• Latencia de cola: qué es y cómo medirla
• Modelo de carga abierto vs cerrado: cuál usar y cuándo
• Ley de Little en pruebas de carga: dimensionar y comprobar
• Rendimiento vs latencia: cómo se relacionan bajo carga
• pgbench: benchmark y pruebas de carga de PostgreSQL
• Cómo usar sysbench: benchmarks de CPU, disco y MySQL
• redis-benchmark: cómo usarlo y leer sus resultados
• TPC-H: qué mide el benchmark y cómo ejecutarlo

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.