db benchmarks
1.0.0
https://db-benchmarks.com стремится сделать контрольные показатели базы данных и поисковых систем:
⚖ Справедливая и прозрачная - должно быть ясно при каких условиях эта или иначая база данных / поисковая система дает то или иное производительность
Высокое качество - контроль над коэффициентом изменения позволяет производить результаты, которые остаются прежними, если вы запускаете запрос сегодня, завтра или на следующей неделе
? Легко воспроизводим - любой может воспроизвести любой тест на собственном оборудовании
Легко понять - диаграммы очень простые
➕ расширяется - подключаемая архитектура позволяет добавлять больше баз данных для тестирования
И держите все на 100% с открытым исходным кодом!
Этот репозиторий обеспечивает тестовую структуру, которая выполняет работу.
Многие показатели базы данных не являются объективными. Другие не делают достаточно, чтобы обеспечить точность и стабильность результатов, что в некоторых случаях нарушает всю идею критериев. Несколько примеров:
https://imply.io/blog/druid-nails-cost-efficiency-challenge-against 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 раза, вы, скорее всего, получите очень высокие коэффициенты вариации для каждого из них. Это означает, что если вы запустите тест через минуту, вы можете получить вариацию 20%. И как воспроизводить тест на собственном оборудовании? К сожалению, я не могу найти, как можно это сделать.
Мы считаем, что справедливый эталон базы данных должен следовать некоторым ключевым принципам:
✅ Проверьте различные базы данных на одинаковом оборудовании
В противном случае вы должны признать маржу ошибки, когда есть небольшие различия.
✅ Тест с полным кэшем ОС, очищенный перед каждым тестом
В противном случае вы не можете проверить холодные запросы.
✅ База данных, которая тестируется
В противном случае вы измеряете производительность кеша.
✅ Лучше всего, если вы измеряете холодный пробег. Это особенно важно для аналитических запросов, где часто случаются холодные запросы
В противном случае вы полностью скрываете, как база данных может обрабатывать ввод/вывод.
✅ Больше ничего не должно работать во время тестирования
В противном случае ваши результаты теста могут быть очень нестабильными.
✅ Вам нужно перезагрузить базу данных перед каждым запросом
В противном случае, предыдущие запросы все еще могут влиять на время отклика запроса текущего запроса, несмотря на очистку внутренних кешей.
✅ Вам нужно подождать, пока база данных не нагрется полностью после ее начала
В противном случае вы можете в конечном итоге конкурировать с процессом разминки базы данных для ввода-вывода, который может сильно испортить ваши результаты теста.
✅ Лучше всего, если вы предоставите коэффициент вариации, поэтому все понимают, насколько стабильны ваши результаты, и убедитесь, что он достаточно низкий
Коэффициент вариации - это очень хороший показатель, который показывает, насколько стабильны результаты ваших тестов. Если он выше n%, вы не можете сказать, что одна база данных на N% быстрее, чем другая.
✅ Лучше всего, если вы тестируете на фиксированную частоту процессора
В противном случае, если вы используете губернатора процессора «по требованию» (который обычно является по умолчанию), он может легко превратить ваше время ответа на 500 мс в 1000+ мс.
✅ Лучше всего, если вы тестируете на SSD/NVME, а не на жестком жестко
В противном случае, в зависимости от того, где ваши файлы расположены на HDD, вы можете получить до 2 раза ниже/более высокой производительности ввода -вывода (мы протестировали), что может сделать неверные результаты ваших холодных запросов.
Тестовая структура, которая используется на бэкэнд https://db-benchmarks.com, полностью открыт (Agplv3 License) и может быть найдена по адресу https://github.com/db-benchmarks/db-benchmarks. Вот что он делает:
--limited )--test сохраняет результаты теста для файла--save сохраняет результаты тестирования из файлов в удаленную базу данных (ни одно из тех, кто был протестирован)select count(*) и select * limit 1 чтобы убедиться, что коллекции данных аналогичны в разных базах данныхcpuset и mem ).Прежде чем развернуть тестовую структуру, убедитесь, что у вас есть следующее:
PHP 8 и:curlmysqli Moduledockerdocker-composesensors для контроля температуры процессора для предотвращения дросселяdstatcgroups v2Для установки:
git clone [email protected]:db-benchmarks/db-benchmarks.git
cd db-benchmarks.env.example to .envmem и cpuset в .env со значением памяти по умолчанию (в мегабайтах) и процессоров, которые платформу тестирования может использовать для вторичных задач (загрузка данных, получение информации о базах данных)ES_JAVA_OPTS для ваших тестов. Обычно размер выделенной памяти для Docker Machine Сначала вам нужно подготовить тест:
Перейдите в каталог конкретного теста (все тесты должны быть в каталоге ./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-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 ограничивает ОЗУ до 32 ГБ, если не указано, что по умолчанию будет использоваться из файла .envcpuset="0,1" : контейнер Elasticsearch будет работать только на ядрах процессоров 0 и 1 (что может быть первым целым физическим процессором) Чтобы остановиться - просто CTRL-C .
Хотите принять участие в проекте? Вот как вы можете внести свой вклад:
Все это ждут вашего вклада!
