db benchmarks
1.0.0
https://db-benchmarks.com vise à faire des références de base de données et de recherche:
⚖️ Fair and Transparent - Il doit être clair dans quelles conditions cette ou ce moteur de base de données / de recherche donne ceci ou cette performance
Haute qualité - Le contrôle du coefficient de variation permet de produire des résultats qui restent les mêmes si vous exécutez une requête aujourd'hui, demain ou la semaine prochaine
? Facilement reproductible - n'importe qui peut reproduire n'importe quel test sur son propre matériel
Facile à comprendre - les graphiques sont très simples
➕ Extensible - L'architecture enfichable permet d'ajouter plus de bases de données pour tester
Et gardez tout 100% open source!
Ce référentiel fournit un cadre de test qui fait le travail.
De nombreux repères de base de données ne sont pas objectifs. D'autres ne font pas assez pour assurer la précision et la stabilité des résultats, ce qui, dans certains cas, brise l'idée des références. Quelques exemples:
https://imply.io/blog/druid-nails-cost-efficy-challenge-against-clickhouse-and-rockset/:
Nous voulions en fait faire le benchmark sur le même matériel, un M5.8xlarge, mais la seule configuration pré-cuite que nous avons pour M5.8xlarge est en fait le M5D.8xlARGE ... Au lieu de cela, nous exécutons sur une instance C5.9xlarge
Mauvaise nouvelle, les gars: lorsque vous exécutez des références sur différents matériels, à tout le moins, vous ne pouvez pas dire que quelque chose est "106,76%" et "103,13%" de quelque chose d'autre. Même lorsque vous testez sur le même serveur à métal nu, il est assez difficile d'obtenir un coefficient de variation inférieur à 5%. Une différence de 3% sur différents serveurs peut très probablement être ignorée. Compte tenu de tout cela, comment peut-on s'assurer que la conclusion finale est vraie?
https://tech.marksblogg.com/benchmarks.html
Mark a fait un excellent travail pour faire le test des trajets en taxi sur tant de bases de données et de moteurs de recherche différents. Mais comme les tests sont effectués sur différents matériels, les chiffres du tableau résultant ne sont pas vraiment comparables. Vous devez toujours garder cela à l'esprit lors de l'évaluation des résultats du tableau.
https://clickhouse.com/benchmark/dbms/
Lorsque vous exécutez chaque requête 3 fois, vous obtiendrez très probablement des coefficients de variation très élevés pour chacun d'eux. Ce qui signifie que si vous exécutez le test une minute plus tard, vous pouvez obtenir une variation de 20%. Et comment reproduire un test sur son propre matériel? Malheureusement, je ne trouve pas comment on peut le faire.
Notre croyance est qu'une référence juste de la base de données devrait suivre certains principes clés:
✅ Testez différentes bases de données sur exactement le même matériel
Sinon, vous devez reconnaître une marge d'erreur lorsqu'il y a de petites différences.
✅ Test avec le cache complet du système d'exploitation purgé avant chaque test
Sinon, vous ne pouvez pas tester les requêtes à froid.
✅ La base de données testée devrait avoir tous ses caches internes désactivées
Sinon, vous mesurerez les performances du cache.
✅ Mieux si vous mesurez aussi une course à froid. C'est particulièrement important pour les requêtes analytiques où les requêtes à froid peuvent se produire souvent
Sinon, vous masquez complètement la façon dont la base de données peut gérer les E / S.
✅ Rien d'autre ne devrait fonctionner pendant les tests
Sinon, vos résultats de test peuvent être très instables.
✅ Vous devez redémarrer la base de données avant chaque requête
Sinon, les requêtes précédentes peuvent toujours avoir un impact sur le temps de réponse de la requête actuelle, malgré le nettoyage des caches internes.
✅ Vous devez attendre que la base de données se réchauffe complètement après son démarrage
Sinon, vous pouvez finir par rivaliser avec le processus d'échauffement de la base de données pour les E / S qui peuvent sévèrement gâcher vos résultats de test.
✅ Mieux si vous fournissez un coefficient de variation, donc tout le monde comprend à quel point vos résultats sont stables et assurez-vous que vous êtes suffisamment bas
Le coefficient de variation est une très bonne métrique qui montre à quel point vos résultats de test sont stables. S'il est supérieur à N%, vous ne pouvez pas dire qu'une base de données est N% plus rapide qu'un autre.
✅ Mieux si vous testez sur une fréquence CPU fixe
Sinon, si vous utilisez le gouverneur du processeur "à la demande" (qui est normalement un défaut), il peut facilement transformer votre temps de réponse de 500 ms en 1000+ ms.
✅ Mieux si vous testez sur SSD / NVME plutôt que sur le disque dur
Sinon, selon l'endroit où vos fichiers se trouvent sur le disque dur, vous pouvez obtenir jusqu'à 2 fois les performances d'E / S plus bas / supérieures (nous avons testé), ce qui peut rendre au moins vos résultats de requête à froid mal.
Le cadre de test utilisé sur le backend de https://db-benchmarks.com est entièrement open source (licence AGPLV3) et peut être trouvé sur https://github.com/db-benchmarks/db-benchmarks. Voici ce qu'il fait:
--limited )--test enregistre les résultats des tests dans le fichier--save Save enregistre les résultats des tests des fichiers à une base de données distante (aucun de ceux qui ont été testés)select count(*) et select * limit 1 pour vous assurer que les collections de données sont similaires dans différentes bases de donnéescpuset et mem ).Avant de déployer le cadre de test, assurez-vous d'avoir ce qui suit:
PHP 8 et:curlmysqlidockerdocker-composesensors pour contrôler la température du processeur pour éviter les limitesdstatcgroups v2Pour installer:
git clone [email protected]:db-benchmarks/db-benchmarks.git
cd db-benchmarks.env.example à .envmem et cpuset dans .env avec la valeur par défaut de la mémoire (dans les mégaoctets) et les processeurs que le cadre de test peut utiliser pour les tâches secondaires (chargement de données, obtenir des informations sur les bases de données)ES_JAVA_OPTS pour vos tests. Habituellement, c'est la taille de la mémoire allouée pour la machine Docker Vous devez d'abord préparer un test:
Accédez au répertoire d'un test particulier (tous les tests doivent être dans le répertoire ./tests ), par exemple "hn_small":
cd tests/hn_smallExécutez le script init:
./initCe sera:
Ensuite, exécutez ../../test (c'est dans le dossier de la racine du projet) pour voir les options:
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.Et exécutez le test:
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 Si vous exécutez vos tests en mode local (développement) et que vous ne vous souciez pas de l'inexactitude des tests, vous pouvez éviter les disques calmes et les vérifications du --skip_inaccuracy
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 --skip_inaccuracy Vous avez maintenant des résultats de test dans ./results/ (à la racine du référentiel), par exemple:
# ls results/
220401_054753Vous pouvez maintenant télécharger les résultats dans la base de données pour une visualisation plus approfondie. L'outil de visualisation, qui est utilisé sur https://db-benchmarks.com/, est également open source et peut être trouvé sur https://github.com/db-benchmarks/ui.
Voici comment vous pouvez enregistrer les résultats:
username=login password=pass host=db.db-benchmarks.com port=443 save=./results ./testou
./test --username=login --password=pass --host=db.db-benchmarks.com --port=443 --save=./results
Nous sommes impatients de voir vos résultats de test. Si vous pensez qu'ils doivent être ajoutés à https://db-benchmarks.com, veuillez faire une demande de traction de vos résultats à ce référentiel.
Veuillez garder à l'esprit ce qui suit:
./results .Nous allons alors:
.
|-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.
test=logs10m cpuset= " 0,1 " mem=32768 suffix=_tuned docker-compose up elasticsearchvolonté:
suffix=_tuned : maps ./tests/logs10m/es/data/idx_tuned comme répertoire de donnéesmem=32768 limite la RAM à 32 Go, si elle n'est pas spécifiée, la valeur par défaut sera utilisée à partir du fichier .envcpuset="0,1" : Le conteneur d'Elasticsearch fonctionnera uniquement sur les cœurs CPU 0 et 1 (qui peuvent être le premier processeur physique entier) Pour arrêter - juste CTRL-C .
Vous voulez vous impliquer dans le projet? Voici comment vous pouvez contribuer:
Ceux-ci attendent votre contribution!
