db benchmarks
1.0.0
https://db-tenchmarks.com zielt darauf ab, Datenbank- und Suchmaschinen-Benchmarks zu erstellen:
⚖️ fair und transparent - es sollte klar sein, unter welchen Bedingungen diese oder diese Datenbank / Suchmaschine diese oder diese Leistung verleiht
Hohe Qualität - Kontrolle über den Variationskoeffizienten ermöglicht die Erzeugung von Ergebnissen, die gleich bleiben, wenn Sie heute, morgen oder nächste Woche eine Abfrage ausführen
? Leicht reproduzierbar - jeder kann jeden Test auf seiner eigenen Hardware reproduzieren
Leicht zu verstehen - die Diagramme sind sehr einfach
➕ Extendable - Steckbare Architektur ermöglicht das Hinzufügen weiterer Testen von Datenbanken
Und halten Sie alles 100% Open Source!
Dieses Repository enthält ein Testframework, das den Auftrag erledigt.
Viele Datenbank -Benchmarks sind nicht objektiv. Andere tun nicht genug, um die Genauigkeit und Stabilität der Ergebnisse sicherzustellen, was in einigen Fällen die gesamte Idee von Benchmarks bricht. Ein paar Beispiele:
https://imply.io/blog/druid-nail-cost-ection-chalenge-against-clickhouse-and-and-rockset/:
Wir wollten eigentlich den Benchmark auf derselben Hardware, einen M5.8XLarge, aber die einzige vorgebackene Konfiguration für M5.8xLarge sind tatsächlich die M5D.8xlarge ... Stattdessen laufen wir auf einer C5.9xlarge-Instanz.
Schlechte Nachrichten, Leute: Wenn Sie Benchmarks für verschiedene Hardware ausführen, kann man zumindest nicht sagen, dass etwas "106,76%" und "103,13%" von etwas anderem ist. Selbst wenn Sie auf demselben Bare-Metal-Server testen, ist es ziemlich schwierig, einen Variationskoeffizienten von weniger als 5%zu erhalten. Ein Unterschied von 3% auf verschiedenen Servern kann höchstwahrscheinlich ignoriert werden. Wie kann man angesichts dessen sicherstellen, dass die endgültige Schlussfolgerung wahr ist?
https://tech.marksblogg.com/benchmarks.html
Mark hat großartige Arbeit geleistet, um den Taxi -Fahrgeschäfte auf so vielen verschiedenen Datenbanken und Suchmaschinen zu testen. Da die Tests jedoch auf verschiedenen Hardware durchgeführt werden, sind die Zahlen in der resultierenden Tabelle nicht wirklich vergleichbar. Sie müssen dies immer berücksichtigen, wenn Sie die Ergebnisse in der Tabelle bewerten.
https://clickhouse.com/benchmark/dbms/
Wenn Sie jede Abfrage nur dreimal ausführen, erhalten Sie für jede von ihnen höchstwahrscheinlich sehr hohe Variationskoeffizienten. Das heißt, wenn Sie den Test eine Minute später durchführen, können Sie eine Variation von 20%erhalten. Und wie reproduziert man einen Test auf der eigenen Hardware? Leider kann ich nicht herausfinden, wie man es kann.
Wir glauben, dass ein fairer Datenbank -Benchmark einige wichtige Prinzipien folgen sollte:
✅ Testen Sie verschiedene Datenbanken auf genau derselben Hardware
Andernfalls sollten Sie einen Fehlerrand anerkennen, wenn es kleine Unterschiede gibt.
✅ Testen Sie vor jedem Test mit dem vollständigen Betriebssystem -Cache
Andernfalls können Sie Kaltanfragen nicht testen.
✅ Die getestete Datenbank sollte alle internen Caches deaktiviert haben
Andernfalls werden Sie die Cache -Leistung messen.
✅ Am besten, wenn Sie auch einen Kaltlauf messen. Es ist besonders wichtig für analytische Abfragen, bei denen häufig kalte Fragen auftreten können
Andernfalls verbergen Sie vollständig, wie die Datenbank mit E/A umgehen kann.
✅ Nichts anderes sollte während des Tests ausgeführt werden
Andernfalls können Ihre Testergebnisse sehr instabil sein.
✅ Sie müssen die Datenbank vor jeder Abfrage neu starten
Andernfalls können frühere Abfragen trotz des Löschens interner Caches die Reaktionszeit der aktuellen Abfrage weiterhin beeinflussen.
✅ Sie müssen warten, bis sich die Datenbank vollständig erwärmt, nachdem sie begonnen hat
Andernfalls konkurrieren Sie möglicherweise mit dem Aufwärmprozess der Datenbank für I/A, der Ihre Testergebnisse stark verderben kann.
✅ Am besten, wenn Sie einen Variationskoeffizienten anbieten, versteht jeder, wie stabil Ihre Ergebnisse sind, und stellen Sie sicher, dass es niedrig genug ist
Variationskoeffizient ist eine sehr gute Metrik, die zeigt, wie stabil Ihre Testergebnisse sind. Wenn es höher als n% ist, können Sie nicht sagen, dass eine Datenbank n% schneller ist als eine andere.
✅ Am besten, wenn Sie eine feste CPU -Frequenz testen
Andernfalls kann der CPU-Gouverneur von "On-Demand" -Louverneur (was normalerweise ein Standard ist) Ihre Reaktionszeit von 500 ms problemlos in eine Reaktionszeit von 500 ms verwandeln.
✅ Am besten, wenn Sie eher auf SSD/NVME als auf HDD testen
Andernfalls können Sie je nachdem, wo sich Ihre Dateien auf HDD befinden, bis zu 2x niedrigere/höhere E/A -Leistung (wir getestet) erhalten, was zumindest Ihre kalten Abfragenergebnisse falsch machen kann.
Das Test-Framework, das im Backend von https://db-benchmarks.com verwendet wird, ist vollständig Open Source (AGPLV3-Lizenz) und finden Sie unter https://github.com/db-Benchmarks/db-Benchmarks. Hier ist, was es tut:
--limited ).--test speichert Testergebnisse in der Datei--save speichert Testergebnisse von Dateien in einer Remote-Datenbank (keine der getesteten derjenigen)select count(*) und select * limit 1 um sicherzustellen, dass die Datensammlungen in verschiedenen Datenbanken ähnlich sindcpuset und mem ).Bevor Sie das Testframework bereitstellen, stellen Sie sicher, dass Sie Folgendes haben:
PHP 8 und:curlmysqli Moduldockerdocker-composesensors zur Kontrolle der CPU -Temperatur, um das Drossel zu verhinderndstatcgroups v2Zu installieren:
git clone [email protected]:db-benchmarks/db-benchmarks.git
cd db-benchmarks.env.example nach .envmem und cpuset in .env mit dem Standardwert des Speichers (in Megabyte) und CPUs Das Testframework kann für Sekundäraufgaben verwendet werden (Datenladen, Informationen zu Datenbanken erhalten)ES_JAVA_OPTS für Ihre Tests. Normalerweise hat die Größe des zugewiesenen Speichers für Docker -Maschine Zuerst müssen Sie einen Test vorbereiten:
Gehen Sie zum Verzeichnis eines bestimmten Tests (alle Tests müssen im Verzeichnis sein ./tests ), zum Beispiel "hn_small":
cd tests/hn_smallFühren Sie das Init -Skript aus:
./initDies wird:
Dann laufen Sie ../../test (es befindet sich im Ordner des Projektroots), um die Optionen zu sehen:
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.Und führen Sie den Test aus:
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 Wenn Sie Ihre Tests --skip_inaccuracy lokalen Modus (Entwicklung) ausführen und sich nicht für die Ungenauigkeiten der Tests interessieren
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 --skip_inaccuracy Jetzt haben Sie Testergebnisse in ./results/ (im Wurzel des Repositorys) beispielsweise:
# ls results/
220401_054753Sie können die Ergebnisse jetzt zur weiteren Visualisierung in die Datenbank hochladen. Das Visualisierungsinstrument, das auf https://db-benchmarks.com/ verwendet wird, ist ebenfalls Open Source und finden Sie unter https://github.com/db-autchmarks/ui.
So können Sie die Ergebnisse speichern:
username=login password=pass host=db.db-benchmarks.com port=443 save=./results ./testoder
./test --username=login --password=pass --host=db.db-benchmarks.com --port=443 --save=./results
Wir sind bestrebt, Ihre Testergebnisse zu sehen. Wenn Sie der Meinung sind, dass sie zu https://db-tenchmarks.com hinzugefügt werden sollten, stellen Sie bitte eine Pull-Anfrage Ihrer Ergebnisse zu diesem Repository.
Bitte beachten Sie Folgendes:
./results .Wir werden dann:
.
|-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 elasticsearchWille:
suffix=_tuned : maps ./tests/logs10m/es/data/idx_tuned als Datenverzeichnismem=32768 begrenzt den RAM auf 32 GB. Wenn nicht angegeben, wird der Standard aus der Datei verwendet .envcpuset="0,1" : Der Container von Elasticsearch läuft nur auf CPU -Kernen 0 und 1 (was die erste ganze physische CPU sein kann) Anhalten - nur CTRL-C .
Möchten Sie sich in das Projekt einlassen? So können Sie dazu beitragen:
Diese warten alle auf Ihren Beitrag!
