db benchmarks
1.0.0
https://db-benchmarks.comは、データベースと検索エンジンのベンチマークを作成することを目指しています。
⚖️公正で透明性- これまたはそのデータベース /検索エンジンがこれまたはそのパフォーマンスを提供する条件下で明確にする必要があります
高品質- 変動係数の制御により、今日、明日、または来週クエリを実行した場合、同じままの結果を生成できます
？簡単に再現できます- 誰でも自分のハードウェアでテストを再現できます
理解しやすい- チャートは非常にシンプルです
extende拡張可能- プラグ可能なアーキテクチャにより、より多くのデータベースを追加してテストすることができます
そして、それをすべて100％オープンソースに保ちます！
このリポジトリは、ジョブを行うテストフレームワークを提供します。
多くのデータベースベンチマークは客観的ではありません。他の人は、結果の正確性と安定性を確保するのに十分なことをしません。いくつかの例：
https://imply.io/blog/druid-nails-cost-efficiency-challenge-ageainst-clickhouse-and-rockset/：
実際には、同じハードウェア、M5.8xlargeでベンチマークを作成したかったのですが、M5.8xLarge用に持っている唯一の事前に焼き付けられた構成は、実際にはM5D.8XLARGEです...代わりに、C5.9XLARGEインスタンスで実行します。
悪いニュース、みんな：さまざまなハードウェアでベンチマークを実行すると、少なくとも他の何かの「106.76％」と「103.13％」であると言うことはできません。同じベアメタルサーバーでテストする場合でも、5％未満の変動係数を取得することは非常に困難です。さまざまなサーバーの3％の違いは無視できる可能性があります。それをすべて考えると、最終的な結論が真であることをどのように確認できますか？
https://tech.marksblogg.com/benchmarks.html
マークは、非常に多くの異なるデータベースと検索エンジンでタクシーに乗るテストを行う素晴らしい仕事をしました。しかし、テストは異なるハードウェアで行われるため、結果のテーブルの数値は実際には匹敵しません。テーブルの結果を評価するときは、常にこれを念頭に置いておく必要があります。
https://clickhouse.com/benchmark/dbms/
各クエリを3回だけ実行すると、それぞれのバリエーションの係数が非常に高いと思われます。つまり、1分後にテストを実行すると、20％のバリエーションが得られる可能性があります。そして、自分のハードウェアでテストをどのように再現しますか？残念ながら、私はそれがどのようにできるかを見つけることができません。
私たちの信念は、公正なデータベースベンチマークはいくつかの重要な原則に従うべきであるということです。
cordまったく同じハードウェアで異なるデータベースをテストします
それ以外の場合は、小さな違いがある場合はエラーマージンを確認する必要があります。
full各テストの前に完全なOSキャッシュをパージしたテスト
それ以外の場合は、コールドクエリをテストすることはできません。
testされているデータベースは、すべての内部キャッシュを無効にする必要があります
それ以外の場合は、キャッシュパフォーマンスを測定します。
coldあなたもコールドランを測定する場合に最適です。コールドクエリが頻繁に発生する可能性のある分析クエリにとって特に重要です
それ以外の場合は、データベースがI/Oを処理する方法を完全に非表示にします。
testテスト中に他に実行されるべきではありません
それ以外の場合、テスト結果は非常に不安定です。
query各クエリの前にデータベースを再起動する必要があります
それ以外の場合、内部キャッシュのクリアにもかかわらず、以前のクエリは現在のクエリの応答時間に影響を与える可能性があります。
dataデータベースが開始された後、データベースが完全に暖まるまで待つ必要があります
それ以外の場合は、テスト結果を大幅に台無しにする可能性のあるI/Oのデータベースのウォームアッププロセスと競合することになります。
bariation係数を提供する場合に最適なので、誰もがあなたの結果がどれほど安定しているかを理解し、それが十分に低いことを確認してください
変動係数は、テスト結果の安定性を示す非常に優れたメトリックです。 n％よりも高い場合、あるデータベースが別のデータベースよりもn％高速であるとは言えません。
codific CPU周波数でテストする場合に最適
それ以外の場合、「オンデマンド」CPUガバナー（通常はデフォルトです）を使用している場合、500msの応答時間を1000以上のMSに簡単に変えることができます。
hddではなくSSD/NVMEでテストする場合に最適
それ以外の場合、ファイルがHDDの場所に応じて、最大2倍低い/高いI/Oパフォーマンス（テスト）を得ることができます。
https://db-benchmarks.comのバックエンドで使用されるテストフレームワークは、完全にオープンソース（Agplv3ライセンス）であり、https：//github.com/db-benchmarks/db-benchmarksにあります。これがそれがすることです：
--limited ）--testテスト結果をファイルに保存します--saveファイルからテスト結果をリモートデータベースに保存します（テストされたものはどちらも）select count(*) 、 select * limit 1データコレクションが異なるデータベースで類似していることを確認しますcpusetおよびmemを使用）。テストフレームワークを展開する前に、次のことを確認してください。
PHP 8および：curlモジュールmysqliモジュールdockerdocker-composesensorsスロットリングを防ぐdstatcgroups v2インストールするには：
git clone [email protected]:db-benchmarks/db-benchmarks.git
cd db-benchmarks.env.example to .envmemとcpusetを.envで更新し、メモリのデフォルト値（Megabytes）とCPUを使用して、テストフレームワークはセカンダリタスクに使用できます（データの読み込み、データベースに関する情報の取得）ES_JAVA_OPTSを制限します。通常、Dockerマシンに割り当てられたメモリのサイズですまず、テストを準備する必要があります。
特定のテストのディレクトリに移動します（すべてのテストはディレクトリ./testsにある必要があります）。たとえば、「hn_small」：
cd tests/hn_smallinitスクリプトを実行します：
./initこれは：
次に../../test Test（プロジェクトルートのフォルダーにあります）を実行して、オプションを確認します。
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.テストを実行します：
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384テストをローカルモード（開発）で実行し、テストの不正確さを気にしない場合、パラメーターを設定することでディスクの穏やかさとCPUチェックを避けることができます--skip_inaccuracy
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 --skip_inaccuracyたとえば、 ./results/ （リポジトリのルート）にテスト結果があります。
# ls results/
220401_054753これで、結果をデータベースにアップロードして、さらに視覚化できます。 https://db-benchmarks.com/で使用される視覚化ツールは、オープンソースでもあり、https：//github.com/db-benchmarks/uiにあります。
結果を保存する方法は次のとおりです。
username=login password=pass host=db.db-benchmarks.com port=443 save=./results ./testまたは
./test --username=login --password=pass --host=db.db-benchmarks.com --port=443 --save=./results
私たちはあなたのテスト結果を見たいと思っています。それらをhttps://db-benchmarks.comに追加する必要があると思われる場合は、このリポジトリに結果をプルリクエストしてください。
次のことを念頭に置いてください：
./resultsに配置する必要があります。それでは：
.
|-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 elasticsearch意思：
suffix=_tuned ：maps ./tests/logs10m/es/data/idx_tunedデータディレクトリとしてmem=32768はRAMを32GBに制限します。指定されていない場合は、デフォルトがファイルから使用されます.envcpuset="0,1" ：Elasticsearchのコンテナは、CPUコア0および1でのみ実行されます（これは最初の物理CPU全体である可能性があります）停止するCTRL-Cだけ。
プロジェクトに参加したいですか？貢献する方法は次のとおりです。
これらはすべてあなたの貢献を待っています！
