YCSB: cargas de trabalho A-F, execução e limites

Q: Qual a diferença entre ycsb load e ycsb run?

A fase load insere o número de registros definido por `recordcount`. A fase run depois executa `operationcount` operações com a mistura da carga de trabalho sobre esses registros e informa a vazão e a latência.

31 de outubro de 2026 7 min de leitura

O YCSB, Yahoo! Cloud Serving Benchmark, é uma ferramenta open source escrita em Java que carrega registros sintéticos num banco de dados e depois executa sobre eles uma mistura fixa de leituras, atualizações, inserções e scans enquanto registra a vazão e a latência de cada operação. Suas seis cargas de trabalho principais (core workloads), de A a F, são misturas padronizadas, então o mesmo teste pode rodar contra Cassandra, MongoDB, Redis, HBase e dezenas de outros bancos por meio de bindings. Ele mede só o banco de dados, por isso não diz nada sobre as consultas reais da sua aplicação nem sobre a latência que seus usuários veem.

Não rodamos o YCSB para este artigo. Os fatos vêm do repositório no GitHub, da wiki e do código-fonte do projeto, conferidos em 31 de outubro de 2026, e as avaliações são nossas.

Carga de trabalho	Mistura de operações	Distribuição das chaves	Exemplo dado pela wiki
A: muitas atualizações	50% leituras, 50% atualizações	zipfian	Armazenamento de sessões que guarda ações recentes
B: quase só leitura	95% leituras, 5% atualizações	zipfian	Marcação de fotos
C: só leitura	100% leituras	zipfian	Cache de perfis de usuário
D: ler o mais recente	95% leituras, 5% inserções	latest	Atualizações de status de usuários
E: intervalos curtos	95% scans, 5% inserções	zipfian (scans de até 100 registros)	Threads de conversa
F: ler-modificar-gravar	50% leituras, 50% ler-modificar-gravar	zipfian	Banco de dados de usuários

As misturas vêm dos arquivos do diretório workloads e os exemplos da página Core Workloads (conferido em 31 de outubro de 2026). Cada arquivo vem com só 1.000 registros e 1.000 operações: o bastante para depurar uma instalação e pouco demais para um benchmark.

O que é o YCSB, e ele ainda é mantido?

É um gerador de carga com um conjunto de cargas de trabalho padronizadas para comparar bancos chave-valor e de “cloud serving”, publicado como open source pelo Yahoo! em 2010 sob a licença Apache 2.0. A última versão é de outubro de 2019, e o código ainda recebe pequenos commits.

A página de publicações cita o artigo original, “Benchmarking Cloud Serving Systems with YCSB”, de Cooper, Silberstein, Tam, Ramakrishnan e Sears (ACM SoCC 2010). A versão 0.17.0 tem data de 6 de outubro de 2019 e não existe tag mais nova, enquanto o histórico de commits mostra trabalho em 2026, como uma opção para seguir em frente quando uma inserção falha e uma mudança no binding do Cloud Spanner em 20 de outubro (conferido em 31 de outubro de 2026). Essas mudanças só chegam se você compilar a partir do código-fonte, o que exige o Maven 3.

Como rodar um benchmark com o YCSB?

Em duas fases que compartilham as mesmas propriedades: load insere recordcount registros e depois run executa operationcount operações com a mistura da carga de trabalho. Você informa o binding do seu banco e passa o arquivo da carga de trabalho com -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

A página Running a Workload traz os detalhes que mais pegam as pessoas (conferido em 31 de outubro de 2026). O cliente nunca cria tabelas, então antes você precisa mapear a usertable para o que o seu banco exige, como uma tabela no MySQL ou um keyspace no Cassandra. Arquivos -P posteriores sobrescrevem os anteriores, e -p sobrescreve todos. A fase run precisa do mesmo recordcount da carga, porque escolhe as chaves dentro de todo o conjunto de dados. -s mostra uma linha de status a cada 10 segundos. Como D e E inserem registros, a página Core Workloads recomenda carregar uma vez com o arquivo de A, rodar A, B, C, F e D, depois apagar os dados e carregar de novo para E.

O que -threads e -target controlam?

-threads define quantas threads de cliente enviam operações (uma por padrão), e -target limita o total de operações por segundo. Sem alvo, cada thread envia a próxima operação assim que a anterior volta, então um banco mais lento simplesmente recebe menos carga.

É um modelo de carga fechado, e nosso artigo sobre o modelo de carga aberto vs fechado explica o que ele esconde. O exemplo da wiki, 10 threads com alvo de 100 operações por segundo, só se sustenta enquanto a latência média fica abaixo de 100 ms; com threads de menos, a taxa alcançada fica abaixo do alvo. É a lei de Little em ação: threads divididas pela latência média limitam a vazão. Se você rodar vários alvos e anotar a latência de cada um, obtém a curva do nosso guia sobre vazão vs latência.

Como ler a saída do YCSB?

No fim de cada fase, o cliente imprime um bloco [OVERALL] com o tempo de execução e a vazão, depois um bloco por tipo de operação com a contagem, as latências média, mínima, máxima e por percentil, e uma contagem por código de retorno.

Estes nomes de campo vêm do código-fonte da 0.17.0; os valores são marcadores de posição:

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

A saída de exemplo da wiki mostra milissegundos, mas a medição HdrHistogram padrão, tanto na 0.17.0 quanto no código atual, informa microssegundos, (us). A página Core Properties e a versão 0.17.0 definem os percentis padrão como 95 e 99, que você muda com hdrhistogram.percentiles; desde abril de 2025 o branch master acrescenta o 50, então um build a partir do código-fonte também mostra 50thPercentileLatency(us) (conferido em 31 de outubro de 2026). O README chama a atenção para o P99 e além, avisa que não se tira média de percentis e recomenda, com vários clientes, salvar arquivos de histograma HDR com hdrhistogram.fileoutput=true e juntá-los.

O YCSB leva em conta a coordinated omission?

Só se você pedir, e só com -target. Por padrão, cada latência é medida a partir do momento em que a operação é de fato enviada, então uma travada que atrasa as operações seguintes quase não aparece.

O código-fonte das medições tem uma propriedade measurement.interval que aceita op (padrão), intended ou both (conferido em 31 de outubro de 2026). Com um alvo, cada thread anota o início previsto de cada operação; intended mede a latência a partir desse ponto, e both acrescenta blocos Intended- como [Intended-READ] ao lado dos habituais. A wiki não menciona a propriedade, então confira o código da versão que você compilar. Nosso guia sobre coordinated omission explica por que o início previsto dá o número honesto.

Quais bancos de dados o YCSB consegue testar?

Qualquer um que tenha um binding. O arquivo de build do branch master lista 46 módulos de binding, entre eles Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB e um binding JDBC genérico.

A lista está no pom.xml, e cada diretório de binding tem o próprio README com as propriedades de conexão, como mongodb.url no binding do MongoDB (conferido em 31 de outubro de 2026). Segundo a página Running a Workload, uma única máquina cliente basta para clusters de umas 10 máquinas; acima disso, você sobe vários clientes, e a página Running a Workload in Parallel divide a carga entre eles com insertstart e insertcount.

Quando o YCSB não é a ferramenta certa?

Quando a sua pergunta é sobre a sua aplicação. A carga de trabalho principal grava registros sintéticos, 10 campos com comprimento de 100 cada por padrão, com operações simples por chave, então não consegue mostrar como suas próprias consultas, seus índices ou o código da sua API se comportam sob carga.

Para OLTP relacional, o pgbench roda no PostgreSQL um script inspirado no TPC-B e aceita scripts seus, e o sysbench traz benchmarks em Lua no estilo OLTP (ambos conferidos em 31 de outubro de 2026).
Para a latência que os usuários veem, coloque sob carga a camada HTTP ou de API que fica na frente do banco. A LoadFocus, que publica este site, roda planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem contra endpoints web e de API. A LoadFocus não roda o YCSB.

FAQ

Quais são as cargas de trabalho principais do YCSB? Seis misturas padronizadas: A tem 50% de leituras e 50% de atualizações, B tem 95% de leituras, C só leituras, D privilegia os registros inseridos mais recentemente, E faz scans curtos e F faz operações de leitura-modificação-gravação.

Qual a diferença entre ycsb load e ycsb run? A fase load insere o número de registros definido por recordcount. A fase run depois executa operationcount operações com a mistura da carga de trabalho sobre esses registros e informa a vazão e a latência.

O YCSB ainda é mantido? A última versão, 0.17.0, saiu em 6 de outubro de 2019. O repositório ainda recebe commits de vez em quando, o mais recente em 20 de outubro de 2026, então as correções novas exigem compilar a partir do código-fonte.

A LoadFocus consegue rodar benchmarks do YCSB? Não. A LoadFocus não roda o YCSB. Os planos de teste JMeter e os scripts k6 dela miram endpoints web e de API, ou seja, a camada que fica na frente do banco de dados.

Leituras relacionadas

As afirmações técnicas deste artigo não foram revisadas de forma independente.

LoadFocus team

Escrito pela equipe da LoadFocus, as pessoas por trás de um serviço de teste de carga na nuvem.