Using YCSB to Benchmark JSON Databases

Bruce Lindsay disse uma vez"Há três coisas importantes no mundo dos bancos de dados: Desempenho, desempenho e desempenho". A maioria dos arquitetos corporativos sabe que, à medida que avançamos nos recursos e nas arquiteturas de banco de dados, é importante medir o desempenho de forma aberta para que eles possam comparar o custo total de propriedade de forma confiável.

YCSB fez um excelente trabalho de benchmarking de armazenamentos de dados que atendem aos aplicativos "Cloud OLTP". Esses armazenamentos de dados eram simples, com operações simples de obter, colocar e excluir. A versão original Referência YCSB consiste em operações simples de inserção, atualização, exclusão e varredura em um documento simples de 10 valores-chave; as cargas de trabalho são definidas com uma combinação dessas operações em várias porcentagens.

JSON bancos de dados como Couchbase e MongoDB têm um modelo de dados mais avançado com escalares, objetos aninhados, matrizes, matrizes de objetos, matrizes e matrizes de objetos. Os bancos de dados JSON também têm consulta linguagem, índices e recursos. Além das operações de CRUD, os aplicativos usam rotineiramente as linguagens de consulta declarativas nesses bancos de dados para pesquisar, paginar e executar relatórios. Portanto, para ajudar os arquitetos a avaliar as plataformas de forma eficaz, precisamos de um benchmark adicional para medir esses recursos, além das operações básicas de CRUD. Este tutorial do YCSB explica seus recursos para preencher essa lacuna.

Papel YCSB estados: Também esperamos promover o desenvolvimento de outros conjuntos de benchmark de nuvem que representem outras classes de aplicativos, disponibilizando nossa ferramenta de benchmark por meio de código aberto. Nesse sentido, um dos principais recursos da estrutura/ferramenta YCSB é o fato de ser extensível - ela suporta a definição fácil de novas cargas de trabalho, além de facilitar a avaliação comparativa de novos sistemas.

Esse benchmark estende o YCSB para bancos de dados JSON, ampliando as operações existentes para JSON e, em seguida, definindo novas operações e novas cargas de trabalho.

Aqui está o esboço.

Introdução
Modelo de dados
Operações de referência
Cargas de trabalho de referência
Implementação do YCSB-JSON
Como executar o YCSB-JSON?
Referências

1. Introdução

O YCSB foi desenvolvido para medir o desempenho de armazenamentos de dados de valor-chave NoSQL dimensionáveis. A infraestrutura do YCSB faz bem esse trabalho. O YCSB usa uma chave-valor simples e plana. O Couchbase usa um modelo JSON, que os clientes usam para aplicativos interativos em massa. Criamos e estamos criando recursos no produto para permitir que os clientes criem esses aplicativos de forma eficaz. Precisamos de medições de desempenho para esses casos de uso.

Há outros bancos de dados compatíveis com o modelo JSON: MongoDB, DocumentDB, DynamoDB, RethinkDB, Oracle NoSQL. Ao executar o YCSB em bancos de dados JSON (Couchbase, MongoDB etc.), o driver simplesmente armazena e recupera cadeias de caracteres na estrutura de valor-chave JSON. Todos esses bancos de dados exigem um novo benchmark para medir o processamento da estrutura avançada do JSON (objetos aninhados, matrizes) e operações como paginação, agrupamento e agregações.

O objetivo do YCSB-JSON é estender o benchmark YCSB para medir a capacidade do banco de dados JSON para cobrir esses dois aspectos:

Representante de operações de aplicativos interativos em massa.
- Operações no modelo de dados JSON, incluindo objetos aninhados e matrizes.
Crie cargas de trabalho que representem as operações desses aplicativos.

Veja estes casos de uso de clientes:

Marriott criou seu sistema de reservas no IBM Mainframe e no DB2. Eles enfrentaram desafios de custo e desempenho à medida que mais e mais clientes tentavam navegar pelo inventário disponível. Os sistemas em DB2 foram originalmente criados para receber reservas de um sistema telefônico ou de agentes. A taxa de procura por reserva é baixa. Atualmente, essa proporção é alta, pois o número de solicitações de pesquisa aumentou exponencialmente. Isso também aumentou drasticamente o custo do banco de dados. A Marriott transferiu todos os seus dados de inventário para o Couchbase com sincronização contínua de seus sistemas de mainframe; os aplicativos da Web usam o Couchbase para as operações de consulta/pesquisa.
Carros.com é um portal para listar e vender carros. Eles têm os dados de listagem no Oracle. Quando os disponibilizam na Web, eles precisam não apenas apresentar as informações básicas sobre o carro, mas também fornecer insights adicionais, como quantos usuários estão procurando um carro ou o salvaram em sua lista de desejos. Essa é uma forma de aumentar o envolvimento e o senso de urgência. Todos os dados necessários para essas operações interativas são armazenados no Couchbase.

De modo mais geral, os aplicativos interativos em massa incluem o seguinte:

Consulte a disponibilidade de quartos, detalhes de preços, comodidades (pesquisas por clientes finais)
Procurar informações sobre marca/modelo de carro ou oficinas de reparo (habilitar consumidores e parceiros em escala da Web)
Fornecer informações ao cliente no contexto (serviços baseados em localização)
Atende tanto aos dados mestre quanto aos dados transacionais (em escala)

Para dar suporte a esses requisitos, os aplicativos e bancos de dados fazem o seguinte:

Descarga de consultas de bancos de dados de sistemas de registro de alto custo (mainframe, Oracle)
- (aplicativos de reservas e receitas)
Abertura das funções de back-office para acesso à Web/móvel
- (permitir que os usuários da Web verifiquem os detalhes do quarto)
Dimensione o banco de dados/consultas com melhor TCO
- (dimensionar mainframes com servidores de commodities)
Modernize os sistemas legados com os recursos exigidos pelos novos aplicativos de colaboração/engajamento
- (inventário de navegação, voos, disponibilidade de quartos, análise departamental)

O novo benchmark precisa medir o desempenho das consultas que implementam essas operações.

2. Modelo de dados

Consideramos o cliente e os pedidos como duas coleções distintas de documentos JSON. Cada pedido tem uma referência ao seu cliente.

Abaixo estão os exemplos de cliente e documento de pedido. Eles foram gerados por meio do gerador de dados fakeit. Essa ferramenta está disponível em: https://github.com/bentonam/fakeit

Consulte o apêndice para ver o arquivo YAML usado para definir o modelo de dados e o domínio.



Sample customer document
Document Key: 100_advjson
{
  "_id": "100_advjson",
  "doc_id": 100,
  "gid": "48a8e177-15e5-5116-95d0-41478601bbdd",
  "first_name": "Stella",
  "middle_name": "Jackson",
  "last_name": "Toy",
  "ballance_current": "$1084.94",
  "dob": "2016-05-11",
  "email": "Alysson83@yahoo.com",
  "isActive": true,
  "linear_score": 31,
  "weighted_score": 40,
  "phone_country": "fr",
  "phone_by_country": "01 80 03 25 39",
  "age_group": "child",
  "age_by_group": 12,
  "url_protocol": "http",
  "url_site": "twitter",
  "url_domain": "gov",
  "url": "http://www.twitter.gov/Stella",
  "devices": [
    "EE-245",
    "FF-012",
    "GG-789",
    "HH-246"
  ],
  "linked_devices": [
    [
      "AA-038",
      "BB-577"
    ],
    [
      "OO-565",
      "KK-448",
      "FF-281"
    ],
    [
      "BB-495",
      "AA-374"
    ],
    [
      "BB-609",
      "VV-899",
      "LL-675",
      "BB-291"
    ],
    [
      "CC-048"
    ]
  ],
  "address": {
    "street": "6392 Crona Rue Curve",
    "city": "Simeonland",
    "zip": "98316",
    "country": "Bahrain",
    "prev_address": {
      "street": "9063 Johns Islands Divide",
      "city": "South Jayme",
      "zip": "34950-8194",
      "country": "Bulgaria",
      "property_current_owner": {
        "first_name": "Weston",
        "middle_name": "Clyde",
        "last_name": "Considine",
        "phone": "(665) 343-9468"
      }
    }
  },
  "children": [
    {
      "first_name": "Darrel",
      "gender": null,
      "age": 10
    },
    {
      "first_name": "Shea",
      "gender": null,
      "age": 6
    }
  ],
  "visited_places": [
    {
      "country": "Iran",
      "cities": [
        "Heidenreichshire",
        "West Luciano",
        "Haroldmouth",
        "West Jakeburgh"
      ]
    },
    {
      "country": "Comoros",
      "cities": [
        "New Valliemouth",
        "East Kaleighland"
      ]
    },
    {
      "country": "Israel",
      "cities": [
        "East Kali",
        "Pabloport"
      ]
    },
    {
      "country": "French Guiana",
      "cities": [
        "North Zachary",
        "Kielmouth"
      ]
    }
  ]
}

See the appendix for the YAML file used to define the data model and domain.

Amostra cliente documento

Documento Chave: 100_advjson

{

"_id": "100_advjson",

"doc_id": 100,

"gid": "48a8e177-15e5-5116-95d0-41478601bbdd",

"first_name": "Stella",

"middle_name": "Jackson",

"last_name": "Brinquedo",

"ballance_current": "$1084.94",

"dob": "2016-05-11",

"email": "Alysson83@yahoo.com",

"isActive": verdadeiro,

"linear_score": 31,

"Pontuação ponderada": 40,

"phone_country" (país do telefone): "fr",

"phone_by_country" (telefone por país): "01 80 03 25 39",

"age_group" (grupo de idade): "criança",

3. Operações de referência:

As quatro primeiras operações são iguais às do YCSB padrão, exceto pelo fato de que se trata de documentos JSON. O restante das operações é novo.

Inserir: Insere um novo documento JSON.
Atualização: Atualize um documento JSON substituindo o valor de um campo escalar.
Ler: Lê um documento JSON, seja um campo escolhido aleatoriamente ou todos os campos.
Excluir: Exclui um documento JSON com uma determinada chave.
Escaneamento: Digitaliza documentos JSON em ordem, começando por uma chave de registro escolhida aleatoriamente. O número de registros a serem digitalizados é escolhido aleatoriamente (LIMIT).
Pesquisa: Pesquise documentos JSON com base em predicados de intervalo em 3 campos (personalizável para n campos).
Página: Paginar o conjunto de resultados de uma consulta com predicado em um campo do documento.
- Todos os clientes em zip com OFFSET e LIMIT escolhidos aleatoriamente em SQL, N1QL.
NestScan: Consulta a documentos JSON com base em um predicado em um campo aninhado de 1 nível.
ArrayScan: Consulta de documentos JSON com base em um predicado dentro do campo de matriz de nível único.
ArrayDeepScan: Consulta de documentos JSON com base em um predicado em um campo de matriz de dois níveis (matriz de matrizes).
Relatório: Consultar detalhes de pedidos de clientes em um código postal específico.
- Cada cliente tem vários pedidos.
- O documento do pedido contém detalhes do pedido.
Relatório2: Gerar resumo de pedidos de vendas para um determinado dia, agrupado por CEP.
Carga: Carregamento de dados.
Sincronização: Transmissão e sincronização de dados de outro sistema.
Agregado: Faça alguns agrupamentos e agregações.

Para o Couchbase: Exemplos de implementação de operações de benchmark

As quatro primeiras operações são iguais às do YCSB padrão, exceto pelo fato de que se trata de documentos JSON. O restante das operações é novo.

O Couchbase implementa o YCSB em dois modos.

KV=verdadeiro. KV significa key-value (valor-chave). As operações simples INSERT, UPDATE e DELETE do YCSB podem ser implementadas por meio de APIs KV em vez de consultas. Definir KV=true significa usar a API KV e KV=false significa usar a API N1QL (SQL para JSON). Veja o tutorial do N1QL em https://query-tutorial.couchbase.com

Inserir: Insere um novo documento JSON.

KV=true: KV call to insert
KV=false: INSERT INTO customer VALUES(...)

1 2	KV=verdadeiro: KV chamada para inserir KV=falso: INSERIR PARA cliente VALORES(...)

2. Atualização: Atualize um documento JSON substituindo o valor de um campo escalar.


KV=true: KV call to UPDATE a single document.
KV=false: UPDATE customer SET field1 = value USE KEYS [documentkey]<span style="font-weight: 400"><strong>Read</strong>: Read a JSON document, either one randomly chosen field in the document or all the fields.</span>

KV=verdadeiro: KV chamada para ATUALIZAÇÃO a único documento.

KV=falso: ATUALIZAÇÃO cliente CONJUNTO campo1 = valor USO CHAVES [documentkey]<extensão estilo="font-weight: 400"><forte>Ler</forte>: Ler a JSON documento, ou um aleatoriamente escolhido campo em o documento ou todos o campos.</span>


KV=true: KV call to fetch a single document.
KV=false: SELECT * FROM customer USE KEYS [documentkey]

KV=verdadeiro: KV chamada para buscar a único documento.

KV=falso: SELECIONAR * DE cliente USO CHAVES [documentkey]

3. Leia: Obtém um documento JSON com uma determinada chave.


KV=true: KV call to fetch a single document.
KV=false: SELECT * FROM customer USE KEYS [documentkey]

KV=verdadeiro: KV chamada para buscar a único documento.

KV=falso: SELECIONAR * DE cliente USO CHAVES [documentkey]

4. Excluir: Exclui um documento JSON com uma determinada chave.


KV=true: KV call to fetch a single document.
KV=false: DELETE FROM customer USE KEYS [documentkey]

KV=verdadeiro: KV chamada para buscar a único documento.

KV=falso: DELETE DE cliente USO CHAVES [documentkey]

5. Digitalização: Digitaliza documentos JSON em ordem, começando por uma chave de registro escolhida aleatoriamente. O número de registros a serem digitalizados é escolhido aleatoriamente (LIMIT).


KV=TRUE:
SELECT META().id FROM customer WHERE META().id > “val” ORDER BY META().id LIMIT <num>
Fetch the actual documents directly using KV calls from the benchmark driver.

KV=false: SELECT * FROM customer WHERE META().id > “val” ORDER BY META().id LIMIT <num>

KV=VERDADEIRO:

SELECIONAR META().id DE cliente ONDE META().id > "val" ORDER BY META().id LIMITE <num>

Buscar o real documentos diretamente usando KV chamadas de o referência motorista.

KV=falso: SELECIONAR * DE cliente ONDE META().id > "val" ORDER BY META().id LIMITE <num>

6. Página: Paginar o conjunto de resultados de uma consulta com predicado em um campo do documento.



All customers in address.zip with randomly chosen OFFSET and LIMIT in SQL, N1QL
KV=TRUE:
SELECT META().id FROM customer WHERE address.zip = “value” OFFSET <num> LIMIT <num>
Fetch the actual documents directly using KV calls from the benchmark driver.

KV=false: SELECT * FROM customer WHERE address.zip = “value” OFFSET <num> LIMIT <num>

Todos clientes em endereço.zip com aleatoriamente escolhido DESLOCAMENTO e LIMITE em SQL, N1QL

KV=VERDADEIRO:

SELECIONAR META().id DE cliente ONDE endereço.zip = "valor" DESLOCAMENTO <num> LIMITE <num>

Buscar o real documentos diretamente usando KV chamadas de o referência motorista.

KV=falso: SELECIONAR * DE cliente ONDE endereço.zip = "valor" DESLOCAMENTO <num> LIMITE <num>

7. Busca: Pesquisar documentos JSON com base em predicados de intervalo em 3 campos (personalizável para n campos).



All customers WHERE (country = “value1” AND age_group = “value2” and YEAR(dob) = “value” )
All customers retrieved with randomly chosen OFFSET and LIMIT in SQL, N1QL

KV=TRUE:
SELECT META().id FROM customer WHERE country = “value1” AND age_group = “value2” and YEAR(dob) = “value” ORDER BY country, age_group, YEAR(dob) OFFSET <num> LIMIT <num>
Fetch the actual documents directly using KV calls from the benchmark driver.

KV=false: SELECT * FROM customer WHERE WHERE country = “value1” AND age_group = “value2” and YEAR(dob) = “value” ORDER BY country, age_group, YEAR(dob) OFFSET <num> LIMIT <num>

Todos clientes ONDE (país = "valor1" E grupo_idade = "valor2" e ANO(dob) = "valor" )

Todos clientes recuperado com aleatoriamente escolhido DESLOCAMENTO e LIMITE em SQL, N1QL

KV=VERDADEIRO:

SELECIONAR META().id DE cliente ONDE país = "valor1" E grupo_idade = "valor2" e ANO(dob) = "valor" ORDEM BY país, grupo_idade, ANO(dob) DESLOCAMENTO <num> LIMITE <num>

Buscar o real documentos diretamente usando KV chamadas de o referência motorista.

KV=falso: SELECT * DE cliente ONDE ONDE país = "valor1" E grupo_idade = "valor2" e ANO(dob) = "valor" ORDEM BY país, grupo_idade, ANO(dob) DESLOCAMENTO <num> LIMITE <num>

8. NestScan: Consulta a documentos JSON com base em um predicado em um campo aninhado de 1 nível.



KV=TRUE:
SELECT META().id FROM customer WHERE address.prev_address.zip = “value” LIMIT <num>
Fetch the actual documents directly using KV calls from the benchmark driver.

KV=false: SELECT * FROM customer WHERE address.prev_address.zip = “value” LIMIT <num>

KV=VERDADEIRO:

SELECIONAR META().id DE cliente ONDE address.prev_address.zip = "valor" LIMITE <num>

Buscar o real documentos diretamente usando KV chamadas de o referência motorista.

KV=falso: SELECIONAR * DE cliente ONDE address.prev_address.zip = "valor" LIMITE <num>

9. ArrayScan: Consulta de documentos JSON com base em um predicado dentro do campo de matriz de nível único.



Find all customers who have devices with a value. E.g. FF-012
Sample devices field
 "devices": [
   "EE-245",
   "FF-012",
   "GG-789",
   "HH-246"
 ],
KV=TRUE:
SELECT META().id FROM customer WHERE ANY v IN devices SATISFIES v = “FF-012” END ORDER BY META().id LIMIT <num>
Fetch the actual documents directly using KV calls from the benchmark driver.
KV=false: SELECT * FROM customer WHERE ANY v IN devices SATISFIES v = “FF-012” ORDER BY META().id END LIMIT <num>

Localizar todos clientes que ter dispositivos com a valor. E.g. FF-012

Amostra dispositivos campo

"dispositivos": [

"EE-245",

"FF-012",

"GG-789",

"HH-246"

KV=VERDADEIRO:

SELECIONAR META().id DE cliente ONDE QUALQUER v IN dispositivos SATISFAÇÕES v = "FF-012" FIM ORDEM BY META().id LIMITE <num>

Buscar o real documentos diretamente usando KV chamadas de o referência motorista.

KV=falso: SELECT * DE cliente ONDE QUALQUER v IN dispositivos SATISFAÇÕES v = "FF-012" ORDEM BY META().id FIM LIMITE <num>

10. ArrayDeepscan: Consulta de documentos JSON com base em um predicado em um campo de matriz de dois níveis (matriz de matrizes).

Obtenha uma lista de todos os clientes que visitaram Paris, França.

KV=verdadeiro:


SELECT META().id FROM customer
WHERE ANY v in visited_places SATISFIES
v.country = “France” AND
ANY c in v.cities SATISFIES c = “Paris” END
ORDER BY META().id
LIMIT <num>

SELECIONAR META().id DE cliente

ONDE QUALQUER v em locais_visitados SATISFAÇÕES

v.país = "França" E

QUALQUER c em v.cidades SATISFAÇÕES c = "Paris" FIM

ORDEM BY META().id

LIMITE <num>

Obtenha os documentos reais diretamente usando chamadas KV do driver de benchmark.

KV=false:


SELECT * FROM customer
WHERE ANY v in visited_places SATISFIES v.country = “France” AND
           ANY c in v.cities SATISFIES c = “Paris” END
      END
ORDER BY META().id
LIMIT <num>

SELECIONAR * DE cliente

ONDE QUALQUER v em locais_visitados SATISFAÇÕES v.país = "França" E

QUALQUER c em v.cidades SATISFAÇÕES c = "Paris" FIM

FIM

ORDEM BY META().id

LIMITE <num>

11. Relatório: Consultar detalhes de pedidos de clientes em um código postal específico.


Each customer has multiple orders.
Order document has order details.
KV=TRUE:
Not possible (easily without significant perf impact.
KV=false:

SELECT *
FROM customer c INNER JOIN orders o  
ON (META(id) IN c.order_list)
WHERE address.zip = "val"               

ANSI JOIN with HASH join:
SELECT *
FROM customer c INNER JOIN orders o USE HASH (probe)
ON (META(id) IN c.order_list)
WHERE address.zip = “val”

Cada cliente tem múltiplos pedidos.

Pedido documento tem ordem detalhes.

KV=VERDADEIRO:

Não possível (facilmente sem significativo perf impacto.

KV=falso:

SELECT *

DE cliente c INNER JUNTAR pedidos o

ON (META(id) IN c.lista_de_ordens)

ONDE endereço.zíper = "val"

ANSI JUNTAR com HASH unir-se:

SELECT *

DE cliente c INNER JUNTAR pedidos o USO HASH (sonda)

ON (META(id) IN c.lista_de_ordens)

ONDE endereço.zíper = "val"

12. Relatório2: Gerar resumo de pedidos de vendas para um determinado dia, agrupado por CEP.

KV=TRUE:
Need to write a program
KV=false:
SELECT  o.day, c.zip, SUM(o.salesamt)
FROM customer c INNER JOIN orders o  
ON (META(id) IN c.order_list)
WHERE c.zip = “value”
AND o.day = “value”
GROUP BY c.day, c.zip
ORDER BY SUM(o.sales_amt)



----ANSI join

SELECT  o.day, c.zip, SUM(o.salesamt)
FROM customer c INNER JOIN orders o
ON (META(id) IN c.order_list)
WHERE c.zip = “value”
AND o.day = “value”
GROUP BY c.day, c.zip
ORDER BY SUM(o.sales_amt)

------ANSI join with HASH join

SELECT  o.day, c.zip, SUM(o.salesamt)
FROM customer c INNER JOIN orders o USE HASH (probe)
ON (META(id) IN c.order_list)
WHERE c.zip = “value”
AND o.day = “value”
GROUP BY c.day, c.zip
ORDER BY SUM(o.sales_amt)

KV=VERDADEIRO:

Necessidade para escrever a programa

KV=falso:

SELECIONAR o.dia, c.zip, SUM(o.salesamt)

DE cliente c INNER JOIN pedidos o

ON (META(id) IN c.order_list)

ONDE c.zip = "valor"

E o.dia = "valor"

GRUPO BY c.dia, c.zip

ORDER BY SUM(o.sales_amt)

----ANSI unir-se

SELECIONAR o.dia, c.zip, SUM(o.salesamt)

DE cliente c INNER JOIN pedidos o

ON (META(id) IN c.order_list)

ONDE c.zip = "valor"

E o.dia = "valor"

GRUPO BY c.dia, c.zip

ORDER BY SUM(o.sales_amt)

------ANSI unir-se com HASH unir-se

SELECIONAR o.dia, c.zip, SUM(o.salesamt)

DE cliente c INNER JOIN pedidos o USO HASH (sonda)

ON (META(id) IN c.order_list)

ONDE c.zip = "valor"

E o.dia = "valor"

GRUPO BY c.dia, c.zip

ORDER BY SUM(o.sales_amt)

13. Carga: Carregamento de dados.

CARREGAR 1 milhão de documentos.
CARREGAR 10 milhões de documentos.

14. Sincronização: Transmissão e sincronização de dados de outro sistema

Necessidade de medir o desempenho da sincronização de dados.
1. Sincronização de 1 milhão de documentos. Atualização do 50%, inserção do 50%.
2. Sincronização de 10 milhões de documentos. Atualização 80%, inserção 20%.
O ideal é que essa sincronização seja feita a partir do Kafka ou de algum outro conector que extraia dados de uma fonte diferente.

15. Agregado: Faça alguns agrupamentos e agregações.

---Group Query 1

SELECT c.zip, COUNT(1)
FROM customer c
WHERE c.zip between "value1" and "value2"
GROUP BY c.zip

---Grupo Consulta 1

SELECIONAR c.zíper, CONTAGEM(1)

DE cliente c

ONDE c.zíper entre "value1" e "value2"

GRUPO BY c.zíper



---GROUP BY query 2

SELECT o.day, SUM(o.salesamt)
FROM orders o
WHERE o.day  between “value1” and “value2”
GROUP BY o.day;

---GRUPO BY consulta 2

SELECIONAR o.dia, SUM(o.salesamt)

DE pedidos o

ONDE o.dia entre "value1" e "value2"

GRUPO BY o.dia;

4. Cargas de trabalho de referência

As cargas de trabalho são uma combinação dessas operações.

Para começar, a definição da carga de trabalho pode reutilizar as definições da definição do YCSB: carga de trabalho A até carga de trabalho E. Os detalhes estão disponíveis em https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads. Precisaremos definir cargas de trabalho adicionais com uma combinação das operações definidas acima.

A carga de trabalho SA é a mesma que a carga de trabalho A no novo modelo. O mesmo acontece com a carga de trabalho de B a F. Vamos chamá-las de SB a SF para diferenciar da carga de trabalho de B a F.

Carga de trabalho	Operações	Seleção de registros	Exemplo de aplicativo
SA - Atualização pesada	Leia: 50% Atualização 50%	Zipfiano	Armazenamento de sessão que registra ações recentes em uma sessão de usuário
SB - Ler pesado	Ler: 95% Atualização: 5%	Zipfiano	Marcação de fotos; adicionar uma tag é uma atualização, mas a maioria das operações Atualização: 5% são para ler etiquetas
SC - Somente leitura	Ler: 100%	Zipfiano	Cache de perfil de usuário, em que os perfis são construídos em outro lugar (por exemplo, Hadoop)
SD - Leia mais recente	Ler: 95% Inserto 5%	Mais recentes	Atualizações de status do usuário; as pessoas querem ler os status mais recentes
SE - Alcances curtos	Escanear: 95% Inserção: 5%	Zipfian/Uniforme	Conversas encadeadas, em que cada varredura é para as postagens em um determinado encadeamento (supostamente agrupadas por ID de encadeamento)
SF - Ler, modificar, gravar	Leia: 50% Escreva: 50%	Zipfiano	banco de dados de usuários, em que os registros de usuários são lidos e modificados pelo usuário ou para registrar a atividade do usuário.
SG - Página pesada	Página: 90% Inserção: 5% Atualização:5%	Zipfiano	Banco de dados de usuários, onde novos usuários são adicionados, registros existentes são atualizados, consultas de paginação no sistema.
SH - Pesquisa pesada	Busca: 90% Inserção: 5% Atualização: 5%	Zipfiano	Banco de dados de usuários, onde novos usuários são adicionados, registros existentes são atualizados e consultas de pesquisa no sistema.
SI - NestScan pesado	Nestscan: 90% Inserção: 5% Atualização: 5%	Zipfiano	Banco de dados de usuários, onde novos usuários são adicionados, registros existentes são atualizados, consultas de nestscan no sistema.
SJ - Arrayscan pesado	Arrayscan: 90% Inserção: 5% Atualização: 5%	Zipfiano
SK - ArrayDeepscan pesado	ArrayDeepScan: 90% Inserção: 5% Atualização: 5%	Zipfiano
SL - Relatório	Relatório: 100%
SL - Relatório2	Relatório2: 100%
SLoad - Carga	Carga: 100%	Tudo	Carga de dados para configurar o SoE
SN - Agregado (SN1, SN2)	Agregação: 90% Inserção: 5% Atualização: 5%
SMIX - Carga de trabalho mista	Página:20% Busca:20% Nestscan:15% Arrayscan:15% MatrizDeepscan:10% Agregado: 10% Relatório: 10%		Veja abaixo.
SSync - Sincronização	Sincronização: 100% Mesclar/Atualizar: 70% Novo/Inserto: 30%		Sincronização contínua de dados de outros sistemas com os sistemas de engajamento. Veja abaixo.

Exemplo de configuração para carga de trabalho YCSB/JSON



recordcount=1000
operationcount=1000
workload=com.yahoo.ycsb.workloads.CoreWorkload
Filternumlow = 2
Filternumhigh = 14
Sortnumlow = 3
Sortnumhigh = 6
page1propotion=0.95
insertproportion=0.05
requestdistribution=zipfian
maxscanlength=100
scanlengthdistribution=uniform

contagem de registros=1000

operationcount=1000

carga de trabalho=com.yahoo.ycsb.cargas de trabalho.Carga de trabalho principal

Filternumlow = 2

Filternumhigh = 14

Sortnumlow = 3

Sortnumhigh = 6

page1propotion=0.95

insertproportion=0.05

requestdistribution=zipfian

maxscanlength=100

distribuição de comprimento de varredura=uniforme

Agradecimentos

Agradecimentos a Raju Suravarjjala, Ao diretor sênior de QE e desempenho do Couchbase, por nos incentivar a fazer isso, e a toda a equipe de desempenho por apoiar esse esforço. O benchmark YCSB-JSON foi desenvolvido em colaboração com Alex Gyryk, Engenheiro de desempenho principal do Couchbase. Ele desenvolveu os modelos de dados para clientes e pedidos usados neste artigo e implementou as operações e cargas de trabalho no YCSB-JSON para Couchbase e MongoDB. A implementação do YCSB-JSON está disponível em: https://github.com/couchbaselabs/YCSB

Agradecimentos a Aron Benton, Arquiteto de soluções do Couchase, por desenvolver um gerador de dados JSON fácil de usar e eficiente, o fakeit. Ele o desenvolveu antes de ingressar no Couchbase. Ele está disponível em: https://github.com/bentonam/fakeit

Próxima parte

No próximo artigo sobre o YCSB-JSON, Alex explicará as implementações desse benchmark para o Couchbase e o MongoDB. O código-fonte da implementação está disponível em: https://github.com/couchbaselabs/YCSB

Referências

Benchmarking Cloud Serving Systems com YCSB: https://www.cs.duke.edu/courses/fall13/cps296.4/838-CloudPapers/ycsb.pdf
JSON: http://json.org
Gerador de JSON: http://www.json-generator.com/
Implementação do YCSB-JSON: https://github.com/couchbaselabs/YCSB

Apêndice

YAML para gerar o conjunto de dados do cliente.


name: AdvJSON
type: object
key: _id
data:
  fixed: 10000
properties:
  _id:
    type: string
    data:
      post_build: "return '' + this.doc_id + '_advjson';"
  doc_id:
    type: integer
    description: The document id
    data:
      build: "return document_index + 1"
  gid:
    type:
    description: "guid"
    data:
        build: "return chance.guid();"
  first_name:
    type: string
    description: "First name - string, linked to url as the personal page"
    data:
      fake: "{{name.firstName}}"
  middle_name:
    type: string
    description: "Middle name - string"
    data:
      build: "return chance.bool() ? chance.name({middle: true}).split(' ')[1] : null;"
  last_name:
    type: string
    description: "Last name - string"
    data:
      fake: "{{name.lastName}}"
  ballance_current:
    type: string
    description: "currency"
    data:
      build: "return chance.dollar();"
  dob:
    type: string
    description: "Date"
    data:
      build: "return chance.bool() ? new Date(faker.date.past()).toISOString().split('T')[0] : null;"
  email:
    type: string
    description: "email"
    data:
      fake: "{{internet.email}}"
  isActive:
    type: boolean
    description: "active boolean"
    data:
      build: "return chance.bool();"
  linear_score:
    type: integer
    description: "integer 0 - 100"
    data:
      build: "return chance.integer({min: 0, max: 100});"
  weighted_score:
    type: integer
    description: "integer 0 - 100 with zipf distribution"
    data:
      build: "return chance.weighted([0, 1, 2, 3, 4, 5, 6, 7, 8, 9], [1, 0.4, 0.3, 0.25, 0.2, 0.17, 0.13, 0.11, 0.1, 0.09]) * 10 + chance.integer({min: 0, max: 10});"
  phone_country:
    type: string
    description: "field linked to phone, choices: us, uk, fr"
    data:
      build: "return  chance.pickone(['us', 'uk', 'fr']);"
  phone_by_country:
    type: string
    description: "phone number by country code, linked to phone_country field"
    data:
      post_build: "return chance.phone({country: this.phone_country});"
  age_group:
    type: string
    description: "field linked to age, choices: child, teen, adult, senior"
    data:
      build: "return  chance.pickone(['child', 'teen', 'adult', 'senior']);"
  age_by_group:
    type: integer
    description: "age by group, linked to age_group field"
    data:
      post_build: "return chance.age({type: this.age_group});"
  url_protocol:
    type: string
    description: "lined to url"
    data:
      build: "return  chance.pickone(['http', 'https']);"
  url_site:
    type: string
    description: "lined to url"
    data:
      build: "return  chance.pickone(['twitter', 'facebook', 'flixter', 'instagram', 'last', 'linkedin', 'xing', 'google', 'snapchat', 'tumblr', 'pinterest', 'youtube', 'vine', 'whatsapp']);"
  url_domain:
    type: string
    description: "lined to url"
    data:
      build: "return  chance.pickone(['com', 'org', 'net', 'int', 'edu', 'gov', 'mil', 'us', 'uk', 'ft', 'it', 'de']);"
  url:
    type: string
    description: "user profile url, linked to other document fields"
    data:
      post_build: "return '' + this.url_protocol + '://www.' + this.url_site + '.' + this.url_domain + '/' + this.first_name;"
  devices:
    type: array
    description: "Array of strings - device"
    items:
      $ref: '#/definitions/Device'
      data:
        min: 2
        max: 6
  linked_devices:
    type: array
    description: "Array of array of string"
    items:
      $ref: '#/definitions/Device'
      data:
        min: 3
        max: 6
        submin: 1
        submax: 4
  address:
    type: object
    description: An object of the Address
    schema:
      $ref: '#/definitions/Address'
  children:
    type: array
    description: "An array of Children objects"
    items:
      $ref: '#/definitions/Children'
      data:
        min: 0
        max: 5
  visited_places:
    type: array
    description: "Array of objects with arrays"
    items:
      $ref: '#/definitions/Visited_places'
      data:
        min: 1
        max: 4

definitions:
  Device:
    type: string
    description: "string AA-001 with zipf step distribution"
    data:
      build: "return chance.weighted(['AA', 'BB', 'CC', 'DD', 'EE', 'FF', 'GG', 'HH', 'II', 'JJ', 'KK', 'LL', 'MM', 'NN', 'OO', 'PP', 'QQ', 'RR', 'SS', 'TT', 'UU', 'VV', 'WW', 'XX', 'YY', 'ZZ'], [1, 0.5, 0.333, 0.25, 0.2, 0.167, 0.143, 0.125, 0.111, 0.1, 0.091, 0.083, 0.077, 0.071, 0.067, 0.063, 0.059, 0.056, 0.053, 0.050, 0.048, 0.045, 0.043, 0.042, 0.04, 0.038]).concat('-').concat(chance.string({length: 3, pool: '0123456789'}));"
  Address:
    type: object
    properties:
      street:
        type: string
        description: The address 1
        data:
          build: "return faker.address.streetAddress() + ' ' + faker.address.streetSuffix();"
      city:
        type: string
        description: The locality
        data:
          build: "return faker.address.city();"
      zip:
        type: string
        description: The zip code / postal code
        data:
          build: "return faker.address.zipCode();"
      country:
        type: string
        description: The country
        data:
          build: "return faker.address.country();"
      prev_address:
        type: object
        description: An object of the Address
        schema:
          $ref: '#/definitions/Previous_address'
  Previous_address:
    type: object
    properties:
      street:
        type: string
        description: The address 1
        data:
          build: "return faker.address.streetAddress() + ' ' + faker.address.streetSuffix();"
      city:
        type: string
        description: The locality
        data:
          build: "return faker.address.city();"
      zip:
        type: string
        description: The zip code / postal code
        data:
          build: "return faker.address.zipCode();"
      country:
        type: string
        description: The country
        data:
          build: "return faker.address.country();"
      property_current_owner:
        type: object
        description: "owner object"
        schema:
          $ref: '#/definitions/Property_owner'
  Children:
    type: object
    properties:
      first_name:
        type: string
        description: "first name - string"
        data:
          fake: "{{name.firstName}}"
      gender:
        type: string
        description: "gender M or F"
        data:
          build: "return chance.bool({likelihood: 50})? faker.random.arrayElement(['M', 'F']) : null;"
      age:
        type: integer
        description: "age - 1 to 17"
        data:
          build: "return chance.integer({min: 1, max: 17})"
  Visited_cities:
    type: string
    description: "city"
    data:
      build: "return faker.address.city();"
  Visited_places:
    type: object
    properties:
      country:
        type: string
        data:
          build: "return faker.address.country();"
      cities:
        type: array
        description: "Array of strings - device id"
        items:
          $ref: '#/definitions/Visited_cities'
          data:
            min: 1
            max: 5
  Property_owner:
    type: object
    properties:
      first_name:
        type: string
        description: "First name - string, linked to url as the personal page"
        data:
          fake: "{{name.firstName}}"
      middle_name:
        type: string
        description: "Middle name - string"
        data:
          build: "return chance.bool() ? chance.name({middle: true}).split(' ')[1] : null;"
      last_name:
        type: string
        description: "Last name - string"
        data:
          fake: "{{name.lastName}}"
      phone:
        type: string
        description: "phone"
        data:
          build: "return chance.phone();"

nome: AdvJSON

tipo: objeto

chave: _id

dados:

fixo: 10000

propriedades:

_id:

tipo: string

dados:

post_build: "return '' + this.doc_id + '_advjson';"

doc_id:

tipo: inteiro

descrição: O ID do documento

dados:

construir: "return document_index + 1"

gid:

tipo:

descrição: "guid"

dados:

construir: "return chance.guid();"

primeiro_nome:

tipo: string

descrição: "Primeiro nome - string, vinculado para url como o pessoal página"

dados:

Keshav Murthy

6 Comentários

heyfaraday fevereiro 5, 2019 em 5:56 am

Existe um YAML para pedidos para gerar o conjunto de dados de pedidos?

Acesse para responder
1. 3bst0r agosto 26, 2021 em 8:32 am
  
  Também estou procurando por isso. O YAML no apêndice não contém a chave "order_list".
  
  Acesse para responder
3bst0r julho 14, 2021 em 9:03 am

Olá, ótimo trabalho! Você poderia fornecer mais instruções sobre como chegar à implementação mencionada aqui? Acabei de verificar a ramificação principal de https://github.com/couchbaselabs/YCSB e não consigo encontrar nem as cargas de trabalho mencionadas aqui nem a implementação das novas operações.

Acesse para responder
Keshav Murthy julho 14, 2021 em 9:12 am

Veja os detalhes no artigo de acompanhamento: https://www.couchbase.com/ycsb-json-implementation-for-couchbase-and-mongodb/

Acesse para responder
1. 3bst0r julho 21, 2021 em 12:49 am
  
  Incrível, obrigado!
  
  Acesse para responder
alflahi agosto 9, 2021 em 2:34 pm

Muito obrigado,
Por favor, tenho uma pergunta: como podemos gerar uma nova carga de trabalho com base em novos requisitos?

Acesse para responder

Deixar uma resposta Cancelar resposta

Você precisa fazer o login para publicar um comentário.

Faça login com sua ID social

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

Todas as publicações

Usando o YCSB para fazer benchmark de bancos de dados JSON

1. Introdução

2. Modelo de dados

3. Operações de referência:

Para o Couchbase: Exemplos de implementação de operações de benchmark

4. Cargas de trabalho de referência

Próxima parte

No próximo artigo sobre o YCSB-JSON, Alex explicará as implementações desse benchmark para o Couchbase e o MongoDB. O código-fonte da implementação está disponível em: https://github.com/couchbaselabs/YCSB

Referências

Apêndice

Autor

Postado por Keshav Murthy

6 Comentários

Deixar uma resposta Cancelar resposta