db benchmarks

Puntos de referencia • Introducción • Por qué esto es importante • Características • Principios de prueba • Instalación • UI

Introducción

https://db-benchmarks.com tiene como objetivo hacer puntos de referencia de la base de datos y los motores de búsqueda:

⚖️ justo y transparente : debe ser claro en qué condiciones o aquella base de datos / motor de búsqueda le da este o aquel rendimiento

Alta calidad : el control sobre el coeficiente de variación permite la producción de resultados que siguen siendo los mismos si ejecuta una consulta hoy, mañana o la próxima semana

? Fácilmente reproducible : cualquiera puede reproducir cualquier prueba en su propio hardware

Fácil de entender : los gráficos son muy simples

➕ Extendible : la arquitectura conectable permite agregar más bases de datos para probar

¡Y manténlo todo 100% de código abierto!

Este repositorio proporciona un marco de prueba que hace el trabajo.

¿Por qué es esto importante?

Muchos puntos de referencia de bases de datos no son objetivos. Otros no hacen lo suficiente para garantizar la precisión y la estabilidad de los resultados, lo que en algunos casos rompe la idea de los puntos de referencia. Algunos ejemplos:

Druid vs Clickhouse vs Rockset

https://imply.io/blog/druid-nails-cost-eficiency-challenge-gainst-clickhouse-and-rockset/:

En realidad, queríamos hacer el punto de referencia en el mismo hardware, un M5.8xLarge, pero la única configuración preconsada que tenemos para M5.8xLarge es en realidad el M5D.8XLarge ... en cambio, ejecutamos en una instancia C5.9xLarge

Malas noticias, muchachos: cuando ejecutan puntos de referencia en diferentes hardware, al menos no se puede decir que algo es "106.76%" y "103.13%" de otra cosa. Incluso cuando prueba en el mismo servidor de metal desnudo, es bastante difícil obtener un coeficiente de variación inferior al 5%. Es muy probable que se pueda ignorar una diferencia del 3% en diferentes servidores. Dado todo eso, ¿cómo se puede asegurar que la conclusión final sea cierta?

---

Muchas bases de datos y motores

https://tech.marksblogg.com/benchmarks.html

Mark hizo un gran trabajo haciendo la prueba del taxi en tantas bases de datos y motores de búsqueda diferentes. Pero dado que las pruebas se realizan en diferentes hardware, los números en la tabla resultante no son realmente comparables. Siempre debe tener esto en cuenta al evaluar los resultados en la tabla.

---

Clickhouse vs otros

https://clickhouse.com/benchmark/dbms/

Cuando ejecuta cada consulta solo 3 veces, lo más probable es que obtenga coeficientes de variación muy altos para cada uno de ellos. Lo que significa que si ejecuta la prueba un minuto después, puede obtener una variación del 20%. ¿Y cómo se reproduce una prueba en el propio hardware? Desafortunadamente, no puedo encontrar cómo se puede hacerlo.

Principios de prueba

Nuestra creencia es que un punto de referencia de base de datos justo debe seguir algunos principios clave:

✅ Pruebe diferentes bases de datos en exactamente el mismo hardware

De lo contrario, debe reconocer un margen de error cuando hay pequeñas diferencias.

✅ Pruebe con la caché del sistema operativo completo purgado antes de cada prueba

De lo contrario, no puede probar consultas frías.

✅ La base de datos que se está probando debe tener todos sus cachés internos deshabilitados

De lo contrario, medirá el rendimiento de la memoria caché.

Best también si mides una carrera en frío también. Es especialmente importante para consultas analíticas donde las consultas frías pueden ocurrir a menudo

De lo contrario, oculta completamente cómo la base de datos puede manejar la E/S.

✅ Nada más debería estar ejecutándose durante las pruebas

De lo contrario, los resultados de su prueba pueden ser muy inestables.

✅ Debe reiniciar la base de datos antes de cada consulta

De lo contrario, las consultas anteriores aún pueden afectar el tiempo de respuesta de la consulta actual, a pesar de la limpieza de cachés internos.

✅ Debe esperar hasta que la base de datos se caliente por completo después de que comience

De lo contrario, puede terminar compitiendo con el proceso de calentamiento de la base de datos para E/S, lo que puede estropear severamente los resultados de su prueba.

Best

El coeficiente de variación es una muy buena métrica que muestra cuán estables son los resultados de su prueba. Si es más alto que n%, no puede decir que una base de datos es n% más rápida que otra.

✅ Lo mejor es que prueba con una frecuencia de CPU fija

De lo contrario, si está utilizando el gobernador de la CPU "bajo demanda" (que normalmente es un valor predeterminado) puede convertir fácilmente su tiempo de respuesta de 500 ms en más de 1000 ms.

✅ Mejor si prueba en SSD/NVME en lugar de HDD

De lo contrario, dependiendo de dónde estén ubicados sus archivos en HDD, puede obtener hasta 2 veces un rendimiento de E/S más bajo/mayor (probamos), lo que puede hacer que al menos sus consultas fríos sean incorrectas.

Marco de prueba

El marco de prueba que se utiliza en el backend de https://db-benchmarks.com es de código abierto (licencia AGPLV3) y se puede encontrar en https://github.com/db-benchmarks/db-benchmarks. Esto es lo que hace:

• Automatiza la carga de datos en las bases de datos/motores de búsqueda incluidos en el repositorio.
• Puede ejecutar una base de datos/motor de búsqueda en Docker con una restricción de CPU/RAM particular.
• Mientras prueba:
  • Purga el caché del sistema operativo automáticamente
  • Automatizar la purga de cachés de la base de datos antes de cada ejecución del frío
  • Reinicie la base de datos antes de cada ejecución del frío
  • Cuida después de la temperatura de su CPU para evitar acelerar
  • Cuida el coeficiente de variación mientras hace consultas y puede detenerse tan pronto como:
    • El CV es lo suficientemente bajo
    • Y el número de consultas realizadas es suficiente
  • Después de iniciar una base de datos/motor de búsqueda, permita que haga su etapa de calentamiento (datos necesarios previos a la lectura del disco), deja de esperar tan pronto como:
    • No hay IO por unos segundos
    • Y puede conectarse a la base de datos/motor de búsqueda
  • Después de detener una base de datos/motor de búsqueda, espera hasta que se detenga por completo
  • Puede aceptar diferentes tiempos de espera: arranque, calentamiento, conexión inicial, obtener información sobre la base de datos/motor de búsqueda, consulta
  • Puede emular un núcleo físico que permita las capacidades algorítmicas de la evaluación comparativa de las bases de datos de manera más objetiva ( --limited )
  • Puede aceptar todos los valores como argumentos de línea de comandos, así como variables de entorno para una integración más fácil con los sistemas CI
  • --test guarda los resultados de las pruebas para archivar
  • --save guarda los resultados de las pruebas de los archivos a una base de datos remota (ninguno de los que se han probado)
  • Rastrea muchas cosas mientras prueba:
    • Información del servidor: CPU, memoria, ejecución de procesos, sistema de archivos, nombre de host
    • Información actual del repositorio para asegurarse de que no haya cambios locales
    • Métricas de rendimiento: cada tiempo de respuesta de consulta en microsegundos, estadísticas agregadas:
      • Coeficiente de variación de todas las consultas
      • Coeficiente de variación de 80% de consultas más rápidas
      • Tiempo de respuesta de la consulta fría
      • AVG (tiempos de respuesta)
      • AVG (80% de los tiempos de respuesta de consultas más rápidas)
      • El tiempo de respuesta de la consulta más lenta
    • Información de base de datos/motor de búsqueda:
      • select count(*) y select * limit 1 para asegurarse de que las colecciones de datos sean similares en diferentes bases de datos
      • Estado de estructuras de datos de base de datos internos/motores de búsqueda (fragmentos, fragmentos, segmentos, particiones, piezas, etc.)
• Facilita limitar el consumo de CPU/RAM dentro o fuera de la prueba (utilizando las variables de entorno cpuset y mem ).
• Permite iniciar cada base de datos/motor de búsqueda fácilmente de la misma manera que está iniciado por el marco para las pruebas manuales y la preparación de consultas de prueba.

Instalación

Antes de implementar el marco de prueba, asegúrese de tener lo siguiente:

• Servidor de Linux totalmente dedicado a las pruebas
• Pasta termal de CPU fresca para asegurarse de que sus CPU no se aceleren
• PHP 8 y:
  • módulo curl
  • módulo mysqli
• docker
• docker-compose
• sensors para controlar la temperatura de la CPU para evitar que se aceleren
• dstat
• cgroups v2

Para instalar:

1. clon Git del repositorio:

   git clone [email protected]:db-benchmarks/db-benchmarks.git
   cd db-benchmarks

2. Copiar .env.example a .env
3. Actualice mem y cpuset en .env con el valor predeterminado de la memoria (en megabytes) y las CPU, el marco de prueba puede usar para tareas secundarias (carga de datos, obtener información sobre bases de datos)
4. Tune JVM Limits ES_JAVA_OPTS para sus pruebas. Por lo general, es el tamaño de la memoria asignada para Docker Machine

Empezar

Preparar prueba

Primero necesitas preparar una prueba:

Vaya a un directorio de prueba en particular (todas las pruebas deben estar en el directorio ./tests ), por ejemplo "hn_small":

 cd tests/hn_small

Ejecute el script init:

./init

Esto lo hará:

• Descargue la recopilación de datos de Internet
• construir las tablas/índices

Prueba de ejecución

Luego ejecute ../../test (está en la carpeta de la raíz del proyecto) para ver las opciones:

To run a particular test with specified engines, memory constraints and number of attempts and save the results locally:
	/perf/test_engines/test
	--test=test_name
	--engines={engine1:type,...,engineN}
	--memory=1024,2048,...,1048576 - memory constraints to test with, MB
	[--times = N] - max number of times to test each query, 100 by default
	[--dir = path] - if path is omitted - save to directory ' results ' in the same dir where this file is located
	[--probe_timeout = N] - how long to wait for an initial connection, 30 seconds by default
	[--start_timeout = N] - how long to wait for a db/engine to start, 120 seconds by default
	[--warmup_timeout = N] - how long to wait for a db/engine to warmup after start, 300 seconds by default
	[--query_timeout = N] - max time a query can run, 900 seconds by default
	[--info_timeout = N] - how long to wait for getting info from a db/engine
	[--limited] - emulate one physical CPU core
	[--queries = /path/to/queries] - queries to test, ./tests/ < test name > /test_queries by default
To save to db all results it finds by path
	/perf/test_engines/test
	--save=path/to/file/or/dir, all files in the dir recursively will be saved
	--host=HOSTNAME
	--port=PORT
	--username=USERNAME
	--password=PASSWORD
	--rm - remove after successful saving to database
	--skip_calm - avoid waiting until discs become calm
----------------------
Environment variables:
	All the options can be specified as environment variables, but you can ' t use the same option as an environment variables and as a command line argument at the same time.

Y ejecuta la prueba:

../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384

Si ejecuta sus pruebas en modo local (desarrollo) y no les importa la inexactitud de las pruebas, puede evitar la calma de los discos y las verificaciones de CPU estableciendo el parámetro --skip_inaccuracy

../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 --skip_inaccuracy

Ahora tiene resultados de prueba en ./results/ (en la raíz del repositorio), por ejemplo:

 # ls results/
220401_054753

Guardar a DB para visualizar

Ahora puede cargar los resultados en la base de datos para una visualización adicional. La herramienta de visualización, que se utiliza en https://db-benchmarks.com/, también es de código abierto y se puede encontrar en https://github.com/db-benchmarks/ui.

Así es como puede guardar los resultados:

username=login password=pass host=db.db-benchmarks.com port=443 save=./results ./test

o

 ./test --username=login --password=pass --host=db.db-benchmarks.com --port=443 --save=./results

Hacer solicitud de extracción

Estamos ansiosos por ver los resultados de su prueba. Si cree que deben agregarse a https://db-benchmarks.com, haga una solicitud de extracción de sus resultados a este repositorio.

Tenga lo siguiente en mente:

• Sus resultados deben ubicarse en el directorio ./results .
• Si se trata de una nueva prueba/motor, cualquier otro cambio debe incluirse en la misma solicitud de extracción.
• Es importante que nosotros, y cualquier otra persona, debamos ser capaces de reproducir su prueba y, con suerte, obtener resultados similares.

Entonces:

• Revise sus resultados para asegurarse de que sigan los principios de prueba.
• Reproducir su prueba en nuestro hardware para asegurarse de que sean comparables con otras pruebas.
• Discuta cualquier pregunta que surja con usted.
• Y, si todo se verifica, fusionaremos su solicitud de extracción.

Estructura de directorio

 .
  |-core                                    <- Core directory, contains base files required for tests.
  |  |-engine.php                           <- Abstract class Engine. Manages test execution, result saving, and parsing of test attributes.
  |  |-helpers.php                          <- Helper file with logging functions, attribute parsing, exit functions, etc.
  |-misc                                    <- Miscellaneous directory, intended for storing files useful during the initialization step.
  |  |-func.sh                              <- Meilisearch initialization helper script.
  |-plugins                                 <- Plugins directory: if you want to extend the framework by adding another database or search engine for testing, place it here.
  |  |-elasticsearch.php                    <- Elasticsearch plugin.
  |  |-manticoresearch.php                  <- Manticore Search plugin.
  |  |-clickhouse.php                       <- ClickHouse plugin.
  |  |-mysql.php                            <- MySQL plugin.
  |  |-meilisearch.php                      <- Meilisearch plugin.
  |  |-mysql_percona.php                    <- MySQL (Percona) plugin.
  |  |-postgres.php                         <- Postgres plugin.
  |  |-typesense.php                        <- Typesense plugin.
  |-results                                 <- Test results directory. The results shown on https://db-benchmarks.com/ are found here. You can also use `./test --save` to visualize them locally.
  |-tests                                   <- Directory containing test suites.
  |  |-hn                                   <- Hackernews test suite.
  |  |  |-clickhouse                        <- Directory for "Hackernews test -> ClickHouse".
  |  |  |  |-inflate_hook                   <- Engine initialization script. Handles data ingestion into the database.
  |  |  |  |-post_hook                      <- Engine verification script. Ensures the correct number of documents have been ingested and verifies data consistency.
  |  |  |  |-pre_hook                       <- Engine pre-check script. Determines if tables need to be rebuilt, starts the engine, and ensures availability.
  |  |  |-data                              <- Prepared data collection for the tests.
  |  |  |-elasticsearch                     <- Directory for "Hackernews test -> Elasticsearch".
  |  |  |  |-logstash_tuned                 <- Logstash configuration directory for the "tuned" type.
  |  |  |  |  |-logstash.conf
  |  |  |  |  |-template.json
  |  |  |  |-elasticsearch_tuned.yml
  |  |  |  |-inflate_hook                   <- Engine initialization script for data ingestion.
  |  |  |  |-post_hook                      <- Verifies document count and data consistency.
  |  |  |  |-pre_hook                       <- Pre-check script for table rebuilding and engine initialization.
  |  |  |-manticoresearch                   <- Directory for testing Manticore Search in the Hackernews test suite.
  |  |  |  |-generate_manticore_config.php  <- Script for dynamically generating Manticore Search configuration.
  |  |  |  |-inflate_hook                   <- Data ingestion script.
  |  |  |  |-post_hook                      <- Verifies document count and consistency.
  |  |  |  |-pre_hook                       <- Pre-check for table rebuilds and engine availability.
  |  |  |-meilisearch                       <- Directory for "Hackernews test -> Meilisearch".
  |  |  |  |-inflate_hook                   <- Data ingestion script.
  |  |  |  |-post_hook                      <- Ensures correct document count and data consistency.
  |  |  |  |-pre_hook                       <- Pre-check for table rebuilds and engine start.
  |  |  |-mysql                             <- Directory for "Hackernews test -> MySQL".
  |  |  |  |-inflate_hook                   <- Data ingestion script.
  |  |  |  |-post_hook                      <- Ensures document count and consistency.
  |  |  |  |-pre_hook                       <- Pre-check for table rebuilds and engine start.
  |  |  |-postgres                          <- Directory for "Hackernews test -> Postgres".
  |  |  |  |-inflate_hook                   <- Data ingestion script.
  |  |  |  |-post_hook                      <- Verifies document count and data consistency.
  |  |  |  |-pre_hook                       <- Pre-check for table rebuilds and engine availability.
  |  |  |-prepare_csv                       <- Prepares the data collection, handled in `./tests/hn/init`.
  |  |  |-description                       <- Test description, included in test results and used during result visualization.
  |  |  |-init                              <- Main initialization script for the test.
  |  |  |-test_info_queries                 <- Contains queries to retrieve information about the data collection.
  |  |  |-test_queries                      <- Contains all test queries for the current test.
  |  |-taxi                                 <- Taxi rides test suite, with a similar structure.
  |  |-hn_small                             <- Test for a smaller, non-multiplied Hackernews dataset, similar structure.
  |  |-logs10m                              <- Test for Nginx logs, similar structure.
  |-.env.example                            <- Example environment file. Update the "mem" and "cpuset" values as needed.
  |-LICENSE                                 <- License file.
  |-NOTICE                                  <- Notice file.
  |-README.md                               <- You're reading this file.
  |-docker-compose.yml                      <- Docker Compose configuration for starting and stopping databases and search engines.
  |-important_tests.sh
  |-init                                    <- Initialization script. Handles data ingestion and tracks the time taken.
  |-logo.svg                                <- Logo file.
  |-test                                    <- The executable file to run and save test results.

Cómo iniciar una base de datos / motor de búsqueda en particular con un conjunto de datos en particular

test=logs10m cpuset= " 0,1 " mem=32768 suffix=_tuned docker-compose up elasticsearch

voluntad:

• Iniciar Elasticsearch para probar "Logs10m" con la siguiente configuración:
• suffix=_tuned : maps ./tests/logs10m/es/data/idx_tuned como directorio de datos
• mem=32768 limita la RAM a 32GB, si no se especifica, el valor predeterminado se usará desde el archivo .env
• cpuset="0,1" : el contenedor de Elasticsearch se ejecutará solo en los núcleos de CPU 0 y 1 (que puede ser la primera CPU física completa)

Para detenerse, solo CTRL-C .

Notas

• El diseño de resultados de la prueba original de la interfaz de usuario se inspiró en gran medida en los puntos de referencia de Clickhouse: https://clickhouse.com/benchmark/dbms/. ¡Gracias, Alexey Milovidov y Clickhouse Team!

❤️ Contribuir

¿Quieres participar en el proyecto? Así es como puedes contribuir:

Más bases de datos y motores de búsqueda

• MySQL vs Percona Server
• Cassandra vs Scylla
• mysql vs postgresql
• MongoDB vs FerretDB
• Cualquier otra cosa vs cualquier otra cosa

¡Todos están esperando su contribución!

Características Lista de deseos:

• Medir no solo el tiempo de respuesta, sino también el consumo de recursos, como:
  • Consumo de RAM para cada consulta
  • Consumo de CPU
  • Consumo de IO
• Mida no solo el tiempo de respuesta, sino también el rendimiento.
• Haga que sea fácil de usar en CI, de modo que cada nuevo confirmación se pruebe y, si es más lento que antes, la prueba no se pasa.
• Hazlo amigable con el teléfono móvil.
• Mejore la calidad de las pruebas de consulta en frío (actualmente, solo se realiza una ejecución en frío por consulta, lo que hace que la métrica se pueda usar solo para fines informativos, no es tan de alta calidad como AVG rápido ").