db benchmarks
1.0.0
يهدف https://db-benkmarks.com إلى جعل معايير قواعد البيانات والمحركات: معايير:
⚖ عادل وشفاف - يجب أن يكون واضحًا في ظل الظروف التي يعطيها قاعدة البيانات / البحث / محرك البحث هذا أو ذاك
جودة عالية - تتيح التحكم في معامل التباين إنتاج نتائج تبقى كما هي إذا قمت بتشغيل استعلام اليوم أو غدًا أو الأسبوع المقبل
؟ يمكن استنساخها بسهولة - يمكن لأي شخص إعادة إنتاج أي اختبار على أجهزته الخاصة
سهل الفهم - المخططات بسيطة للغاية
➕ قابلة للتمديد - تتيح الهندسة المعمارية القابلة للتجميع إضافة المزيد من قواعد البيانات للاختبار
والحفاظ على كل شيء مفتوح 100 ٪!
يوفر هذا المستودع إطار اختبار يقوم بالمهمة.
العديد من معايير قاعدة البيانات ليست موضوعية. البعض الآخر لا يفعلون ما يكفي لضمان دقة النتائج والاستقرار ، والتي في بعض الحالات تكسر فكرة المعايير الكاملة. أمثلة قليلة:
https://imply.io/blog/druid-nails-cost- كفاءة challenge-against-clickhouse-and-rockset/:
لقد أردنا فعلاً القيام بالمعيار على نفس الأجهزة ، وهو M5.8xlarge ، ولكن التكوين الوحيد قبل المخبوزة لدينا هو في الواقع M5d.8xlarge ... بدلاً من ذلك ، نركض على مثيل C5.9xlarge
الأخبار السيئة ، الرجال: عندما تقوم بتشغيل معايير على أجهزة مختلفة ، على الأقل لا يمكنك أن تقول أن هناك شيئًا ما "106.76 ٪" و "103.13 ٪" من شيء آخر. حتى عند الاختبار على نفس الخادم العاري المعدني ، من الصعب للغاية الحصول على معامل تباين أقل من 5 ٪. من المرجح أن يتم تجاهل فرق 3 ٪ على الخوادم المختلفة. بالنظر إلى كل ذلك ، كيف يمكن للمرء التأكد من أن الاستنتاج النهائي صحيح؟
https://tech.marksblogg.com/benchmarks.html
قام مارك بعمل رائع في إجراء اختبار ركوب سيارة الأجرة على العديد من قواعد البيانات ومحركات البحث المختلفة. ولكن نظرًا لأن الاختبارات التي تم إجراؤها على أجهزة مختلفة ، فإن الأرقام في الجدول الناتج ليست قابلة للمقارنة حقًا. تحتاج دائمًا إلى وضع هذا في الاعتبار عند تقييم النتائج في الجدول.
https://clickhouse.com/benchmark/dbms/
عندما تقوم بتشغيل كل استعلام 3 مرات فقط ، ستحصل على الأرجح على معاملات عالية جدًا من التباين لكل منها. مما يعني أنه إذا قمت بإجراء الاختبار بعد دقيقة واحدة ، فقد تحصل على تباين قدره 20 ٪. وكيف يمكن للمرء أن يعيد اختبار الاختبار على أجهزة المرء؟ لسوء الحظ ، لا يمكنني العثور على كيف يمكن للمرء أن يفعل ذلك.
إيماننا هو أن معيار قاعدة البيانات العادلة يجب أن يتبع بعض المبادئ الرئيسية:
✅ اختبار قواعد بيانات مختلفة على نفس الأجهزة بالضبط
خلاف ذلك ، يجب أن تعترف بهامش خطأ عندما تكون هناك اختلافات صغيرة.
✅ الاختبار باستخدام ذاكرة التخزين المؤقت OS كاملة تم تطهيرها قبل كل اختبار
وإلا لا يمكنك اختبار الاستعلامات الباردة.
✅ قاعدة البيانات التي يتم اختبارها يجب أن تحتوي على كل ذاكرة التخزين المؤقت الداخلية
وإلا فإنك ستقيس أداء ذاكرة التخزين المؤقت.
✅ أفضل إذا قمت بقياس الجري البارد أيضًا. من المهم بشكل خاص للاستعلامات التحليلية حيث قد تحدث الاستعلامات الباردة في كثير من الأحيان
وإلا فإنك تخفي تمامًا كيف يمكن لقاعدة البيانات التعامل مع I/O.
✅ لا ينبغي أن يعمل أي شيء آخر أثناء الاختبار
وإلا فإن نتائج الاختبار قد تكون غير مستقرة للغاية.
✅ تحتاج إلى إعادة تشغيل قاعدة البيانات قبل كل استعلام
خلاف ذلك ، لا يزال بإمكان الاستعلامات السابقة التأثير على وقت استجابة الاستعلام الحالي ، على الرغم من تطهير ذاكرة التخزين المؤقت الداخلية.
✅ تحتاج إلى الانتظار حتى تسخن قاعدة البيانات تمامًا بعد بدء تشغيلها
خلاف ذلك ، قد ينتهي بك الأمر إلى التنافس مع عملية الاحماء الخاصة بقاعدة البيانات لإدخال/إخراج والتي يمكن أن تفسد نتائج الاختبار بشدة.
✅ الأفضل إذا قدمت معامل التباين ، لذلك يفهم الجميع مدى استقرار نتائجك وتأكد من أنه منخفض بما فيه الكفاية
معامل التباين هو مقياس جيد للغاية يوضح مدى استقرار نتائج الاختبار الخاصة بك. إذا كان أعلى من N ٪ ، فلا يمكنك القول أن قاعدة بيانات واحدة أسرع من الآخر.
✅ أفضل إذا قمت باختبار على تردد وحدة المعالجة المركزية الثابتة
خلاف ذلك ، إذا كنت تستخدم حاكم وحدة المعالجة المركزية "عند الطلب" (وهو عادةً ما يكون افتراضيًا) ، فيمكنه بسهولة تحويل وقت استجابة 500 مللي ثانية إلى 1000+ مللي ثانية.
✅ الأفضل إذا قمت باختبار على SSD/NVME بدلاً من HDD
خلاف ذلك ، بناءً على مكان وجود ملفاتك على محرك الأقراص الثابتة ، يمكنك الحصول على ما يصل إلى 2x أقل/أعلى أداء I/O (اختبرنا) ، مما قد يجعل على الأقل نتائج الاستعلامات الباردة خاطئًا.
إطار الاختبار الذي يتم استخدامه في الخلفية من https://db-benchmarks.com مفتوح المصدر بالكامل (ترخيص AGPLV3) ويمكن العثور عليه على https://github.com/db-benchmarks/db-bencharks. هذا ما يفعله:
--limited )--test يحفظ نتائج الاختبار للملف--save يحفظ نتائج الاختبار من الملفات إلى قاعدة بيانات عن بُعد (لا يوجد أي من تلك التي تم اختبارها)select count(*) select * limit 1 للتأكد من أن مجموعات البيانات متشابهة في قواعد البيانات المختلفةcpuset و mem ).قبل نشر إطار الاختبار ، تأكد من أن لديك ما يلي:
PHP 8 و:curlmysqlidockerdocker-composesensors للتحكم في درجة حرارة وحدة المعالجة المركزية لمنع الاختناقdstatcgroups v2للتثبيت:
git clone [email protected]:db-benchmarks/db-benchmarks.git
cd db-benchmarks.env.example إلى .envmem و cpuset في .env مع القيمة الافتراضية للذاكرة (في Megabytes) ووحدة المعالجة المركزية يمكن أن يستخدمها إطار الاختبار في المهام الثانوية (تحميل البيانات ، والحصول على معلومات حول قواعد البيانات)ES_JAVA_OPTS للاختبارات الخاصة بك. عادة ما يكون حجم الذاكرة المخصصة لآلة Docker أولاً ، تحتاج إلى إعداد اختبار:
انتقل إلى دليل اختبار معين (يجب أن تكون جميع الاختبارات في الدليل ./tests ) ، على سبيل المثال "HN_SMALL":
cd tests/hn_smallقم بتشغيل البرنامج النصي init:
./initهذا سوف:
ثم قم بتشغيل ../../test (إنه في مجلد Project Root) لمعرفة الخيارات:
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 إذا قمت بإجراء اختباراتك في الوضع المحلي (التطوير) ولا تهتم بعدم الدقة في الاختبارات ، فيمكنك تجنب اختبارات الأقراص والتحقق من وحدة المعالجة المركزية عن طريق تعيين المعلمة --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-benkmarks.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 : خرائط ./tests/logs10m/es/data/idx_tuned كدليل بياناتmem=32768 يحد من ذاكرة الوصول العشوائي إلى 32 جيجابايت ، إذا لم يتم تحديده ، سيتم استخدام الافتراضي من الملف .envcpuset="0,1" : سيتم تشغيل حاوية Elasticsearch فقط على CPU Cores 0 و 1 (والتي قد تكون أول وحدة المعالجة المركزية المادية الكاملة) للتوقف - فقط CTRL-C .
هل تريد المشاركة في المشروع؟ إليك كيف يمكنك المساهمة:
كل هذا ينتظر مساهمتك!
