db benchmarks
1.0.0
https://db-benchmarks.com bertujuan untuk membuat tolok ukur mesin database dan pencarian:
⚖️ Adil dan transparan - harus jelas dalam kondisi apa ini atau itu mesin database / pencari memberikan kinerja ini atau itu
Kualitas Tinggi - Kontrol atas koefisien variasi memungkinkan hasil menghasilkan yang tetap sama jika Anda menjalankan kueri hari ini, besok atau minggu depan
? Mudah direproduksi - siapa pun dapat mereproduksi tes apa pun pada perangkat keras mereka sendiri
Mudah dimengerti - grafiknya sangat sederhana
➕ Arsitektur yang dapat diperpanjang - Pluggable memungkinkan penambahan lebih banyak database untuk diuji
Dan simpan semuanya 100% open source!
Repositori ini menyediakan kerangka kerja tes yang melakukan pekerjaan.
Banyak tolok ukur basis data tidak objektif. Yang lain tidak cukup melakukan untuk memastikan akurasi dan stabilitas hasil, yang dalam beberapa kasus merusak seluruh gagasan tolok ukur. Beberapa contoh:
https://imply.io/blog/druid-nails-cost-efficiency-challenge-against-clickhouse-and-rockset/:
Kami sebenarnya ingin melakukan tolok ukur pada perangkat keras yang sama, M5.8XLarge, tetapi satu-satunya konfigurasi pra-matang yang kami miliki untuk M5.8XLarge sebenarnya adalah M5D.8XLarge ... sebagai gantinya, kami menjalankan pada instance C5.9XLARGE M5D
Berita buruk, teman -teman: Ketika Anda menjalankan tolok ukur pada perangkat keras yang berbeda, setidaknya Anda tidak dapat mengatakan bahwa ada sesuatu adalah "106,76%" dan "103,13%" dari sesuatu yang lain. Bahkan ketika Anda menguji pada server telanjang-logam yang sama, cukup sulit untuk mendapatkan koefisien variasi lebih rendah dari 5%. Perbedaan 3% pada server yang berbeda kemungkinan besar dapat diabaikan. Mengingat semua itu, bagaimana seseorang dapat memastikan kesimpulan akhir itu benar?
https://tech.markblogg.com/benchmarks.html
Mark melakukan pekerjaan yang hebat membuat tes Taxi Rides pada begitu banyak database dan mesin pencari yang berbeda. Tetapi karena tes dilakukan pada perangkat keras yang berbeda, angka -angka dalam tabel yang dihasilkan tidak benar -benar sebanding. Anda selalu perlu mengingat hal ini saat mengevaluasi hasil dalam tabel.
https://clickhouse.com/benchmark/dbms/
Saat Anda menjalankan setiap kueri hanya 3 kali, kemungkinan besar Anda akan mendapatkan koefisien variasi yang sangat tinggi untuk masing -masing. Yang berarti bahwa jika Anda menjalankan tes satu menit kemudian, Anda mungkin mendapatkan variasi 20%. Dan bagaimana seseorang mereproduksi tes pada perangkat keras sendiri? Sayangnya, saya tidak dapat menemukan bagaimana seseorang dapat melakukannya.
Keyakinan kami adalah bahwa tolok ukur basis data yang adil harus mengikuti beberapa prinsip utama:
✅ Uji database yang berbeda pada perangkat keras yang persis sama
Jika tidak, Anda harus mengakui margin kesalahan ketika ada perbedaan kecil.
✅ Tes dengan cache OS lengkap dibersihkan sebelum setiap tes
Kalau tidak, Anda tidak dapat menguji pertanyaan dingin.
✅ Database yang sedang diuji harus membuat semua cache internalnya dinonaktifkan
Kalau tidak, Anda akan mengukur kinerja cache.
✅ Terbaik jika Anda mengukur lari dingin juga. Ini sangat penting untuk pertanyaan analitik di mana pertanyaan dingin mungkin sering terjadi
Kalau tidak, Anda sepenuhnya menyembunyikan bagaimana database dapat menangani I/O.
✅ Tidak ada hal lain yang harus dijalankan selama pengujian
Kalau tidak, hasil tes Anda mungkin sangat tidak stabil.
✅ Anda perlu me -restart database sebelum setiap kueri
Kalau tidak, kueri sebelumnya masih dapat memengaruhi waktu respons kueri saat ini, meskipun membersihkan cache internal.
✅ Anda harus menunggu sampai database memanas sepenuhnya setelah dimulai
Kalau tidak, Anda dapat bersaing dengan proses pemanasan database untuk I/O yang dapat sangat merusak hasil tes Anda.
✅ Terbaik jika Anda memberikan koefisien variasi, jadi semua orang mengerti seberapa stabil hasil Anda dan pastikan diri Anda cukup rendah
Koefisien variasi adalah metrik yang sangat baik yang menunjukkan seberapa stabil hasil tes Anda. Jika lebih tinggi dari N%, Anda tidak dapat mengatakan satu database lebih cepat dari yang lain.
✅ Terbaik jika Anda menguji frekuensi CPU tetap
Jika tidak, jika Anda menggunakan gubernur CPU "sesuai permintaan" (yang biasanya default), ia dapat dengan mudah mengubah waktu respons 500ms Anda menjadi 1000+ ms.
✅ Terbaik jika Anda menguji SSD/NVME daripada HDD
Kalau tidak, tergantung di mana file Anda berada di HDD, Anda bisa mendapatkan kinerja I/O yang lebih rendah/lebih tinggi (kami diuji), yang dapat membuat setidaknya hasil permintaan dingin Anda salah.
Kerangka pengujian yang digunakan pada backend https://db-benchmarks.com adalah sumber terbuka sepenuhnya (lisensi AGPLV3) dan dapat ditemukan di https://github.com/db-benchmarks/db-benchmarks. Inilah yang dilakukannya:
--limited )--test menyimpan hasil tes untuk mengajukan--save Simpan Hasil Tes dari File ke Database Jarak Jauh (Tak satu pun dari yang telah diuji)select count(*) dan select * limit 1 untuk memastikan koleksi data serupa di database yang berbedacpuset dan mem ).Sebelum Anda menggunakan kerangka kerja tes, pastikan Anda memiliki yang berikut:
PHP 8 dan:curlmysqlidockerdocker-composesensors untuk mengontrol suhu CPU untuk mencegah pelambatandstatcgroups v2Untuk menginstal:
git clone [email protected]:db-benchmarks/db-benchmarks.git
cd db-benchmarks.env.example to .envmem dan cpuset di .env dengan nilai default memori (dalam megabytes) dan CPU yang dapat digunakan kerangka kerja tes untuk tugas sekunder (pemuatan data, mendapatkan info tentang database)ES_JAVA_OPTS untuk tes Anda. Biasanya ukuran memori yang dialokasikan untuk mesin Docker Pertama, Anda perlu menyiapkan tes:
Pergi ke direktori tes tertentu (semua tes harus di direktori ./tests ), misalnya "hn_small":
cd tests/hn_smallJalankan skrip init:
./initIni akan:
Lalu jalankan ../../test (ada di folder proyek root) untuk melihat opsi:
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.Dan jalankan tes:
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 Jika Anda menjalankan tes dalam mode lokal (pengembangan) dan tidak peduli tentang tes ketidakakuratan, Anda dapat menghindari cakram ketenangan dan pemeriksaan CPU dengan mengatur parameter --skip_inaccuracy
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 --skip_inaccuracy Sekarang Anda memiliki hasil tes di ./results/ (dalam akar repositori), misalnya:
# ls results/
220401_054753Anda sekarang dapat mengunggah hasil ke database untuk visualisasi lebih lanjut. Alat visualisasi, yang digunakan pada https://db-benchmarks.com/, juga open source dan dapat ditemukan di https://github.com/db-benchmarks/ui.
Inilah cara Anda dapat menyimpan hasilnya:
username=login password=pass host=db.db-benchmarks.com port=443 save=./results ./testatau
./test --username=login --password=pass --host=db.db-benchmarks.com --port=443 --save=./results
Kami sangat ingin melihat hasil tes Anda. Jika Anda yakin mereka harus ditambahkan ke https://db-benchmarks.com, silakan buat permintaan tarik hasil Anda ke repositori ini.
Harap ingat berikut:
./results .KAMI AKAN:
.
|-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 elasticsearchakan:
suffix=_tuned : peta ./tests/logs10m/es/data/idx_tuned sebagai direktori datamem=32768 membatasi RAM ke 32GB, jika tidak ditentukan default akan digunakan dari file .envcpuset="0,1" : Wadah Elasticsearch akan berjalan hanya pada core CPU 0 dan 1 (yang mungkin merupakan CPU fisik pertama yang pertama) Untuk berhenti - hanya CTRL-C .
Ingin terlibat dalam proyek? Begini cara Anda dapat berkontribusi:
Ini semua sedang menunggu kontribusi Anda!
