Using YCSB to Benchmark JSON Databases

Bruce Lindsay dijo una vez"Hay tres cosas importantes en el mundo de las bases de datos: Rendimiento, rendimiento y rendimiento". La mayoría de los arquitectos de empresa saben que, a medida que avanzamos en características y arquitecturas de bases de datos, es importante medir el rendimiento de forma abierta para poder comparar el coste total de propiedad de forma fiable.

YCSB hizo un gran trabajo de evaluación comparativa de los almacenes de datos que servían a las aplicaciones "Cloud OLTP". Estos almacenes de datos eran sencillos, con operaciones simples de obtención, colocación y eliminación. El YCSB punto de referencia consiste en operaciones simples de inserción, actualización, eliminación y escaneo en un documento simple de 10 valores clave; las cargas de trabajo se definen con una mezcla de estas operaciones con diversos porcentajes.

JSON bases de datos como Couchbase y MongoDB tienen un modelo de datos más avanzado con escalares, objetos anidados, matrices, matrices de objetos, matrices y matrices de objetos. Las bases de datos JSON también tienen consulta lenguaje, índices y capacidades. Además de las operaciones CRUD, las aplicaciones utilizan habitualmente los lenguajes de consulta declarativos de estas bases de datos para buscar, paginar y ejecutar informes. Por tanto, para ayudar a los arquitectos a evaluar las plataformas de forma eficaz, necesitamos una referencia adicional que mida estas capacidades además de las operaciones CRUD básicas. Este tutorial de YCSB explica sus capacidades para colmar esta laguna.

Documento YCSB estados: También esperamos fomentar el desarrollo de otras suites de evaluación comparativa de la nube que representen otras clases de aplicaciones poniendo a disposición nuestra herramienta de evaluación comparativa a través de código abierto. En este sentido, una característica clave del marco/herramienta YCSB es que es extensible: permite definir fácilmente nuevas cargas de trabajo, además de facilitar la evaluación comparativa de nuevos sistemas.

Este benchmark extiende YCSB a las bases de datos JSON mediante la ampliación de las operaciones existentes a JSON y la posterior definición de nuevas operaciones y nuevas cargas de trabajo.

Este es el esquema.

Introducción
Modelo de datos
Operaciones de referencia
Cargas de trabajo de referencia
Implementación de YCSB-JSON
¿Cómo se ejecuta YCSB-JSON?
Referencias

1. Introducción

YCSB se desarrolló para medir el rendimiento de los almacenes de datos escalables NoSQL clave-valor. La infraestructura de YCSB hace bien ese trabajo. YCSB utiliza un simple clave-valor plano. Couchbase utiliza un modelo JSON, que los clientes utilizan para aplicaciones masivamente interactivas. Hemos incorporado y estamos incorporando funciones al producto para que los clientes puedan crear estas aplicaciones de forma eficaz. Necesitamos mediciones de rendimiento para estos casos de uso.

Existen otras bases de datos compatibles con el modelo JSON: MongoDB, DocumentDB, DynamoDB, RethinkDB, Oracle NoSQL. Cuando se ejecuta YCSB en bases de datos JSON (Couchbase, MongoDB, etc), el controlador simplemente almacena y recupera cadenas en la estructura clave-valor JSON. Todas estas bases de datos requieren un nuevo punto de referencia para medir el procesamiento de la rica estructura de JSON (objetos anidados, matrices) y operaciones como paginación, agrupación, agregaciones.

El propósito de YCSB-JSON es ampliar el benchmark YCSB para medir la capacidad de las bases de datos JSON para cubrir estas dos cosas:

Operaciones representativas de aplicaciones interactivas masivas.
- Operaciones sobre el modelo de datos JSON, incluyendo objetos anidados, arrays.
Crear cargas de trabajo que representen operaciones de estas aplicaciones.

Vea estos casos de uso de clientes:

Marriott construyó su sistema de reservas en IBM Mainframe y DB2. Se han encontrado con problemas de costes y rendimiento, ya que cada vez más clientes intentan consultar el inventario disponible. Los sistemas en DB2 se crearon originalmente para aceptar reservas de un sistema telefónico o de agentes. La proporción entre reservas y consultas era baja. Hoy en día, este ratio es alto, ya que el número de solicitudes de búsqueda ha aumentado exponencialmente. Esto también ha aumentado drásticamente el coste de la base de datos. Marriott trasladó todos sus datos de inventario a Couchbase con sincronización continua desde sus sistemas mainframe; las aplicaciones web utilizan Couchbase para las operaciones de consulta/búsqueda.
Coches.com es un portal para listar y vender coches. Tienen los datos de la lista en Oracle. Cuando los publican en la web, no sólo tienen que presentar la información básica sobre el coche, sino también proporcionar información adicional, como cuántos usuarios están buscando un coche o lo han guardado en su lista de deseos. Es una forma de aumentar el compromiso y la sensación de urgencia. Todos los datos necesarios para estas operaciones interactivas se almacenan en Couchbase.

En términos más generales, las aplicaciones interactivas masivas incluyen las siguientes:

Ver disponibilidad de habitaciones, precios y servicios (búsquedas por cliente final)
Buscar información sobre marcas/modelos de coches o talleres de reparación (habilitar a los consumidores y socios a escala web)
Proporcionar información al cliente en su contexto (servicios de localización)
Servir tanto datos maestros como transaccionales (a escala)

Para cumplir estos requisitos, las aplicaciones y bases de datos hacen lo siguiente:

Descarga de consultas de bases de datos de sistemas de registro de alto coste (mainframe, Oracle)
- (aplicaciones de reservas e ingresos)
Apertura de las funciones de back-office al acceso web/móvil
- (permite a los internautas consultar los datos de la habitación)
Escalar bases de datos/consultas con un mejor coste total de propiedad
- (escalar mainframes con servidores básicos)
Modernizar los sistemas heredados con las capacidades que exigen las nuevas aplicaciones de colaboración/compromiso
- (consultar inventario, vuelos, disponibilidad de habitaciones, análisis por departamentos)

La nueva referencia debe medir el rendimiento de las consultas que implementan estas operaciones.

2. Modelo de datos

Hemos tomado cliente y pedidos como dos colecciones distintas de documentos JSON. Cada pedido tiene una referencia a su cliente.

A continuación se muestra el ejemplo de cliente y el documento de pedido. Se ha generado mediante el generador de datos fakeit. Esta herramienta está disponible en: https://github.com/bentonam/fakeit

Consulte en el apéndice el archivo YAML utilizado para definir el modelo de datos y el dominio.



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.

Muestra cliente documento

Documento Llave: 100_advjson

{

"_id": "100_advjson",

"doc_id": 100,

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

"nombre": "Stella",

"segundo_nombre": "Jackson",

"apellido": "Juguete",

"saldo_actual": "$1084.94",

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

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

"isActive": verdadero,

"puntuación_lineal": 31,

"weighted_score": 40,

"país_teléfono": "fr",

"teléfono_por_país": "01 80 03 25 39",

"grupo_de_edad": "niño",

3. Operaciones de referencia:

Las cuatro primeras operaciones son las mismas que las del YCSB estándar, salvo que se trata de documentos JSON. El resto de las operaciones son nuevas.

Inserte: Inserta un nuevo documento JSON.
Actualización: Actualiza un documento JSON reemplazando el valor de un campo escalar.
Leer: Lee un documento JSON, ya sea un campo elegido al azar o todos los campos.
Borrar: Elimina un documento JSON con una clave dada.
Escanear: Escanea documentos JSON en orden, empezando por una clave de registro elegida aleatoriamente. El número de registros a escanear se elige aleatoriamente (LIMIT).
Buscar en: Búsqueda de documentos JSON basada en predicados de rango en 3 campos (personalizable a n campos).
Página: Paginar el conjunto de resultados de una consulta con predicado sobre un campo del documento.
- Todos los clientes en zip con OFFSET y LIMIT elegidos al azar en SQL, N1QL.
NestScan: Consulta documentos JSON basándose en un predicado sobre un campo anidado de 1 nivel.
ArrayScan: Consulta documentos JSON basados en un predicado dentro del campo de matriz de un solo nivel.
ArrayDeepScan: Consulta documentos JSON basándose en un predicado dentro de un campo array de dos niveles (array de arrays).
Informe: Consulte los detalles de los pedidos de los clientes de un código postal específico.
- Cada cliente tiene varios pedidos.
- El documento de pedido contiene los datos del pedido.
Informe2: Generar resumen de pedidos de venta para un día determinado, agrupar por zip.
Carga: Carga de datos.
Sincroniza: Transmisión y sincronización de datos desde otro sistema.
Agregado: Agrupar y agregar.

Para Couchbase: Ejemplos de implementación de Benchmark Operations

Las cuatro primeras operaciones son las mismas que las del YCSB estándar, salvo que se trata de documentos JSON. El resto de las operaciones son nuevas.

Couchbase implementa YCSB en dos modos.

KV=verdadero. KV significa clave-valor. Las operaciones simples de YCSB INSERT, UPDATE y DELETE pueden implementarse a través de APIs KV en lugar de consultas. Establecer KV=true significa utilizar la API KV y KV=false significa utilizar la API N1QL (SQL para JSON). Consulte el tutorial de N1QL en https://query-tutorial.couchbase.com

Inserte: Inserta un nuevo documento JSON.

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

1 2	KV=verdadero: KV llame a a insertar KV=falso: INSERTAR EN cliente VALORES(...)

2. Actualice: Actualiza un documento JSON reemplazando el valor de un 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=verdadero: KV llame a a ACTUALIZACIÓN a solo documento.

KV=falso: ACTUALIZACIÓN cliente SET campo1 = valor UTILICE TECLAS [documentkey]<span estilo"font-weight: 400"><fuerte>Leer</strong>: Leer a JSON documento, o bien un aleatoriamente elegido campo en el documento o todos el campos.</span>


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

KV=verdadero: KV llame a a buscar a solo documento.

KV=falso: SELECCIONE * DESDE cliente UTILICE TECLAS [documentkey]

3. Lee: Obtener un documento JSON con una clave dada.


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

KV=verdadero: KV llame a a buscar a solo documento.

KV=falso: SELECCIONE * DESDE cliente UTILICE TECLAS [documentkey]

4. Borrar: Elimina un documento JSON con una clave dada.


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

KV=verdadero: KV llame a a buscar a solo documento.

KV=falso: BORRAR DESDE cliente UTILICE TECLAS [documentkey]

5. Escanear: Escanea documentos JSON en orden, empezando por una clave de registro elegida aleatoriamente. El número de registros a escanear se elige 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=TRUE:

SELECCIONE META().id DESDE cliente DONDE META().id > "val" ORDENAR POR META().id LÍMITE <num>

Visite el actual documentos directamente utilizando KV llama a de el referencia conductor.

KV=falso: SELECCIONE * DESDE cliente DONDE META().id > "val" ORDENAR POR META().id LÍMITE <num>

6. Página: Paginar el conjunto de resultados de una consulta con predicado sobre un campo del 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 en dirección.zip con aleatoriamente elegido OFFSET y LÍMITE en SQL, N1QL

KV=TRUE:

SELECCIONE META().id DESDE cliente DONDE dirección.zip = "valor" OFFSET <num> LÍMITE <num>

Visite el actual documentos directamente utilizando KV llama a de el referencia conductor.

KV=falso: SELECCIONE * DESDE cliente DONDE dirección.zip = "valor" OFFSET <num> LÍMITE <num>

7. Buscar en: Búsqueda de documentos JSON basada en predicados de rango en 3 campos (personalizable a 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 DONDE (país = "valor1" Y grupo_de_edad = "valor2" y AÑO(Fecha de nacimiento) = "valor" )

Todos clientes recuperado con aleatoriamente elegido OFFSET y LÍMITE en SQL, N1QL

KV=TRUE:

SELECCIONE META().id DESDE cliente DONDE país = "valor1" Y grupo_de_edad = "valor2" y AÑO(Fecha de nacimiento) = "valor" PEDIR POR país, grupo_de_edad, AÑO(Fecha de nacimiento) OFFSET <num> LÍMITE <num>

Visite el actual documentos directamente utilizando KV llama a de el referencia conductor.

KV=falso: SELECCIONAR * DESDE cliente DONDE DONDE país = "valor1" Y grupo_de_edad = "valor2" y AÑO(Fecha de nacimiento) = "valor" PEDIR POR país, grupo_de_edad, AÑO(Fecha de nacimiento) OFFSET <num> LÍMITE <num>

8. NestScan: Consulta documentos JSON basándose en un predicado sobre un campo anidado de 1 nivel.



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=TRUE:

SELECCIONE META().id DESDE cliente DONDE direccion.prev_direccion.zip = "valor" LÍMITE <num>

Visite el actual documentos directamente utilizando KV llama a de el referencia conductor.

KV=falso: SELECCIONE * DESDE cliente DONDE direccion.prev_direccion.zip = "valor" LÍMITE <num>

9. ArrayScan: Consulta documentos JSON basados en un predicado dentro del campo de matriz de un solo nivel.



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>

Encuentre todos clientes que tienen dispositivos con a valor. E.g. FF-012

Muestra dispositivos campo

"dispositivos": [

"EE-245",

"FF-012",

"GG-789",

"HH-246"

KV=TRUE:

SELECCIONE META().id DESDE cliente DONDE CUALQUIER v EN dispositivos SATISFACE v = "FF-012" FIN PEDIR POR META().id LÍMITE <num>

Visite el actual documentos directamente utilizando KV llama a de el referencia conductor.

KV=falso: SELECCIONAR * DESDE cliente DONDE CUALQUIER v EN dispositivos SATISFACE v = "FF-012" PEDIR POR META().id FIN LÍMITE <num>

10. ArrayDeepscan: Consulta documentos JSON basándose en un predicado dentro de un campo array de dos niveles (array de arrays).

Consígueme la lista de todos los clientes que han visitado París, Francia.

KV=verdadero:


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>

SELECCIONE META().id DESDE cliente

DONDE CUALQUIER v en lugares_visitados SATISFACE

v.país = "Francia" Y

CUALQUIER c en v.ciudades SATISFACE c = "París" FIN

PEDIR POR META().id

LÍMITE <num>

Obtenga los documentos reales directamente mediante llamadas KV desde el controlador de referencia.

KV=falso:


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>

SELECCIONE * DESDE cliente

DONDE CUALQUIER v en lugares_visitados SATISFACE v.país = "Francia" Y

CUALQUIER c en v.ciudades SATISFACE c = "París" FIN

FIN

PEDIR POR META().id

LÍMITE <num>

11. Informe: Consulte los detalles de los pedidos de los clientes de un 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 tiene varios pedidos.

Pida documento tiene pedir detalles.

KV=TRUE:

No posible (fácilmente sin significativo perf impacto.

KV=falso:

SELECCIONAR *

DESDE cliente c INTERIOR ÚNASE A pedidos o

EN (META(id) EN c.lista_pedidos)

DONDE dirección.zip = "val"

ANSI ÚNASE A con HASH únase a:

SELECCIONAR *

DESDE cliente c INTERIOR ÚNASE A pedidos o UTILICE HASH (sonda)

EN (META(id) EN c.lista_pedidos)

DONDE dirección.zip = "val"

12. Informe2: Generar resumen de pedidos de venta para un día determinado, agrupar por zip.

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=TRUE:

Necesita a escriba a a programa

KV=falso:

SELECCIONE o.día, c.zip, SUM(o.salesamt)

DESDE cliente c INNER JOIN pedidos o

EN (META(id) EN c.lista_pedidos)

DONDE c.zip = "valor"

Y o.día = "valor"

GRUPO POR c.día, c.zip

ORDENAR POR SUM(o.sales_amt)

----ANSI únase a

SELECCIONE o.día, c.zip, SUM(o.salesamt)

DESDE cliente c INNER JOIN pedidos o

EN (META(id) EN c.lista_pedidos)

DONDE c.zip = "valor"

Y o.día = "valor"

GRUPO POR c.día, c.zip

ORDENAR POR SUM(o.sales_amt)

------ANSI únase a con HASH únase a

SELECCIONE o.día, c.zip, SUM(o.salesamt)

DESDE cliente c INNER JOIN pedidos o UTILICE HASH (sonda)

EN (META(id) EN c.lista_pedidos)

DONDE c.zip = "valor"

Y o.día = "valor"

GRUPO POR c.día, c.zip

ORDENAR POR SUM(o.sales_amt)

13. Carga: Carga de datos.

CARGAR 1 millón de documentos.
CARGAR 10 millones de documentos.

14. Sincronizar: Transmisión y sincronización de datos desde otro sistema

Necesidad de medir el rendimiento de la sincronización de datos.
1. Sincroniza 1 millón de documentos. 50% actualizar, 50% insertar.
2. Sincronización de 10 millones de documentos. Actualización 80%, inserción 20%.
Idealmente, esta sincronización se realizaría desde Kafka o algún otro conector que extraiga datos de una fuente diferente.

15. Agregado: Agrupar y agregar.

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

SELECCIONE c.zip, CONTAR(1)

DESDE cliente c

DONDE c.zip entre "valor1" y "valor2"

GRUPO POR c.zip



---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 POR consulta 2

SELECCIONE o.día, SUM(o.salesamt)

DESDE pedidos o

DONDE o.día entre "valor1" y "valor2"

GRUPO POR o.día;

4. Cargas de trabajo de referencia

Las cargas de trabajo son una combinación de estas operaciones.

Para empezar, la definición de la carga de trabajo puede reutilizar las definiciones de la definición YCSB: carga de trabajo-A a carga de trabajo-E. Los detalles están disponibles en https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads. Necesitaremos definir cargas de trabajo adicionales con una combinación de las operaciones definidas anteriormente.

La carga de trabajo SA es la misma que la carga de trabajo A en el nuevo modelo. Lo mismo ocurre con las cargas de trabajo B a F. Las llamaremos SB a SF para diferenciarlas de las cargas de trabajo B a F.

Carga de trabajo	Operaciones	Selección de discos	Ejemplo de aplicación
SA - Actualización pesada	Leer: 50% Actualización 50%	Zipfian	Almacén de sesión que registra las acciones recientes en una sesión de usuario
SB - Leer pesado	Leer: 95% Actualización: 5%	Zipfian	Etiquetado de fotos; añadir una etiqueta es una actualización, pero la mayoría de las operaciones Actualización: 5% son para leer etiquetas
SC - Sólo lectura	Leer: 100%	Zipfian	Caché de perfiles de usuario, donde los perfiles se construyen en otro lugar (por ejemplo, Hadoop).
SD - Leer lo último	Leer: 95% Inserto 5%	Última	Actualizaciones de estado de los usuarios; la gente quiere leer los últimos estados
SE - Rangos cortos	Escanear: 95% Inserto: 5%	Zipfian/Uniforme	Conversaciones en hilos, donde cada búsqueda es para los mensajes de un hilo determinado (se supone que se agrupan por identificador de hilo).
SF - Leer, modificar, escribir	Leer: 50% Escribe: 50%	Zipfian	base de datos de usuarios, donde el usuario lee y modifica los registros de usuario o para registrar la actividad del usuario.
SG - Página pesada	Página: 90% Inserto: 5% Actualización:5%	Zipfian	Base de datos de usuarios, donde se añaden nuevos usuarios, se actualizan los registros existentes y se realizan consultas de paginación en el sistema.
SH - Búsqueda pesada	Buscar: 90% Inserto: 5% Actualización: 5%	Zipfian	Base de datos de usuarios, donde se añaden nuevos usuarios, se actualizan los registros existentes y se realizan consultas de búsqueda en el sistema.
SI - NestScan pesado	Nestscan: 90% Inserto: 5% Actualización: 5%	Zipfian	Base de datos de usuarios, donde se añaden nuevos usuarios, se actualizan los registros existentes, se anidan las consultas sobre el sistema.
SJ - Arrayscan pesado	Arrayscan: 90% Inserto: 5% Actualización: 5%	Zipfian
SK - ArrayDeepscan pesado	ArrayDeepScan: 90% Inserto: 5% Actualización: 5%	Zipfian
SL - Informe	Informe: 100%
SL - Informe2	Informe2: 100%
SLoad - Carga	Carga: 100%	Todo	Carga de datos para configurar SoE
SN - Agregado (SN1, SN2)	Agregación: 90% Inserto: 5% Actualización: 5%
SMIX - Carga de trabajo mixta	Página:20% Búsqueda:20% Nestscan:15% Arrayscan:15% ArrayDeepscan:10% Agregado: 10% Informe: 10%		Véase más abajo.
SSync - Sincronización	Sincronización: 100% Fusión/Actualización: 70% Nuevo/Inserto: 30%		Sincronización continua de datos de otros sistemas con los sistemas de compromiso. Véase más abajo.

Ejemplo de configuración para la carga de trabajo 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

recordcount=1000

operationcount=1000

carga de trabajo=com.yahoo.ycsb.cargas de trabajo.CoreWorkload

Filternumlow = 2

Filternumhigh = 14

Sortnumlow = 3

Sortnumhigh = 6

page1propotion=0.95

insertarproporción=0.05

requestdistribution=zipfian

maxscanlength=100

scanlengthdistribution=uniforme

Agradecimientos

Gracias a Raju Suravarjjala, Couchbase Senior director for QE and Performance, por empujarnos a hacer esto y a todo el equipo de rendimiento por apoyar este esfuerzo. El benchmark YCSB-JSON fue desarrollado en colaboración con Alex Gyryk, Ingeniero principal de rendimiento de Couchbase. Desarrolló los modelos de datos para clientes y pedidos utilizados en este artículo e implementó las operaciones y cargas de trabajo en YCSB-JSON para Couchbase y MongoDB. La implementación de YCSB-JSON está disponible en: https://github.com/couchbaselabs/YCSB

Gracias a Aron Benton, Couchase Solution Architect, por desarrollar un generador de datos JSON fácil de usar y eficiente, fakeit. Lo desarrolló antes de unirse a Couchbase. Está disponible en: https://github.com/bentonam/fakeit

Parte siguiente

En el próximo artículo sobre YCSB-JSON, Alex explicará las implementaciones de este benchmark para Couchbase y MongoDB. El código fuente de la implementación está disponible en: https://github.com/couchbaselabs/YCSB

Referencias

Evaluación comparativa de sistemas de servicio en nube con YCSB: https://www.cs.duke.edu/courses/fall13/cps296.4/838-CloudPapers/ycsb.pdf
JSON: http://json.org
Generador JSON: http://www.json-generator.com/
Implementación de YCSB-JSON: https://github.com/couchbaselabs/YCSB

Anexo

YAML para generar el conjunto de datos de clientes.


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();"

nombre: AdvJSON

tipo: objeto

clave: _id

datos:

fijo: 10000

propiedades:

_id:

tipo: cadena

datos:

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

doc_id:

tipo: entero

descripción: El identificador del documento

datos:

construya: "return índice_documento + 1"

gid:

tipo:

descripción: "guid"

datos:

construya: "return chance.guid();"

nombre:

tipo: cadena

descripción: " Nombre - cadena, vinculado a url como el personal página"

datos:

Keshav Murthy

Comparte este artículo

6 Comentarios

heyfaraday febrero 5, 2019 a 5:56 am

Hola. ¿Existe YAML para pedidos para generar el conjunto de datos de pedidos?

Inicia sesión para responder
1. 3bst0r agosto 26, 2021 a 8:32 am
  
  También estoy buscando esto. En el YAML del apéndice falta la clave "order_list".
  
  Inicia sesión para responder
3bst0r julio 14, 2021 a 9:03 am

Hola, ¡gran trabajo! ¿Podría por favor proporcionar más instrucciones sobre cómo llegar a la aplicación mencionada aquí? Acabo de comprobar la rama maestra de https://github.com/couchbaselabs/YCSB y no consigo encontrar ni las cargas de trabajo mencionadas aquí ni la implementación de las nuevas operaciones.

Inicia sesión para responder
Keshav Murthy julio 14, 2021 a 9:12 am

Consulte los detalles en el artículo de seguimiento: https://www.couchbase.com/ycsb-json-implementation-for-couchbase-and-mongodb/

Inicia sesión para responder
1. 3bst0r julio 21, 2021 a 12:49 am
  
  ¡Genial, gracias!
  
  Inicia sesión para responder
alflahi agosto 9, 2021 a 2:34 pm

Muchas gracias,
Por favor, tengo una pregunta, ¿Cómo podemos generar una nueva carga de trabajo basada en nuevos requisitos? por favor, necesitamos un ejemplo.

Inicia sesión para responder

Deja un comentario Cancelar respuesta

Lo siento, debes estar conectado para publicar un comentario.

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

Uso de YCSB para comparar bases de datos JSON

1. Introducción

2. Modelo de datos

3. Operaciones de referencia:

Para Couchbase: Ejemplos de implementación de Benchmark Operations

4. Cargas de trabajo de referencia

Parte siguiente

En el próximo artículo sobre YCSB-JSON, Alex explicará las implementaciones de este benchmark para Couchbase y MongoDB. El código fuente de la implementación está disponible en: https://github.com/couchbaselabs/YCSB

Referencias

Anexo

Recibe actualizaciones del blog de Couchbase en tu bandeja de entrada

Autor

Publicado por Keshav Murthy

6 Comentarios

Deja un comentario Cancelar respuesta

¿Listo para empezar con Couchbase Capella?

Empezar a construir

Utilizar Capella gratis

Póngase en contacto