db benchmarks
1.0.0
https://db-benchmarks.com visa fazer benchmarks de banco de dados e mecanismos de pesquisa:
⚖️ justo e transparente - deve ficar claro em que condições este ou o banco de dados / mecanismo de pesquisa fornece este ou a esse desempenho
Alta qualidade - controle sobre o coeficiente de variação permite produzir resultados que permaneçam os mesmos se você executar uma consulta hoje, amanhã ou na próxima semana
? Facilmente reproduzível - qualquer um pode reproduzir qualquer teste em seu próprio hardware
Fácil de entender - os gráficos são muito simples
➕ Extendível - A arquitetura flasgável permite adicionar mais bancos de dados para testar
E mantenha tudo 100% de código aberto!
Este repositório fornece uma estrutura de teste que faz o trabalho.
Muitos benchmarks de banco de dados não são objetivos. Outros não fazem o suficiente para garantir a precisão e a estabilidade dos resultados, o que, em alguns casos, quebra toda a idéia de benchmarks. Alguns exemplos:
https://imply.io/blog/druid-nails-cost-eficiente-challenge-against-clickhouse-and-rockset/:
Na verdade, queríamos fazer a referência no mesmo hardware, um M5.8xlarge, mas a única configuração pré-assada que temos para M5.8xlarge é na verdade a M5d.8xlarge ... em vez disso, executamos em uma instância C5.9xlarge
Más notícias, pessoal: quando você executa benchmarks em hardware diferente, pelo menos você não pode dizer que algo é "106,76%" e "103,13%" de outra coisa. Mesmo quando você testa no mesmo servidor de metal, é bastante difícil obter um coeficiente de variação inferior a 5%. Uma diferença de 3% em diferentes servidores provavelmente pode ser ignorada. Dado tudo isso, como se pode garantir que a conclusão final seja verdadeira?
https://tech.marksblogg.com/benchmarks.html
Mark fez um ótimo trabalho fazendo o teste de passeios de táxi em tantos bancos de dados e mecanismos de pesquisa diferentes. Mas como os testes são feitos em hardware diferente, os números na tabela resultante não são realmente comparáveis. Você sempre precisa ter isso em mente ao avaliar os resultados na tabela.
https://clickhouse.com/benchmark/dbms/
Quando você executa cada consulta apenas três vezes, provavelmente terá coeficientes de variação muito altos para cada um deles. O que significa que, se você executar o teste um minuto depois, poderá obter uma variação de 20%. E como se reproduz um teste no próprio hardware? Infelizmente, não consigo encontrar como alguém pode fazer isso.
Nossa crença é que uma referência justa de banco de dados deve seguir alguns princípios importantes:
✅ Teste bancos de dados diferentes exatamente no mesmo hardware
Caso contrário, você deve reconhecer uma margem de erro quando houver pequenas diferenças.
✅ Teste com cache completo do sistema operacional purificado antes de cada teste
Caso contrário, você não pode testar consultas frias.
✅ Banco de dados que está sendo testado deve ter todos os seus caches internos desativados
Caso contrário, você medirá o desempenho do cache.
✅ Melhor se você medir uma corrida fria também. É especialmente importante para consultas analíticas onde as consultas frias podem acontecer com frequência
Caso contrário, você esconde completamente como o banco de dados pode lidar com a E/S.
✅ Nada mais deve estar em execução durante o teste
Caso contrário, os resultados dos seus testes podem ser muito instáveis.
✅ Você precisa reiniciar o banco de dados antes de cada consulta
Caso contrário, as consultas anteriores ainda podem afetar o tempo de resposta da consulta atual, apesar da limpeza de caches internos.
✅ Você precisa esperar até que o banco de dados se aqueça completamente depois de iniciar
Caso contrário, você pode acabar competindo com o processo de aquecimento do banco de dados para E/S, que pode estragar os resultados dos testes.
✅ Melhor se você fornecer um coeficiente de variação, então todo mundo entende o quão estável são seus resultados e verifique se é baixo o suficiente
O coeficiente de variação é uma métrica muito boa, que mostra o quão estável os resultados dos seus testes são. Se for superior a N%, você não pode dizer que um banco de dados é n% mais rápido que outro.
✅ Melhor se você testar em uma frequência fixa da CPU
Caso contrário, se você estiver usando o governador da CPU "sob demanda" (que normalmente é padrão), ele poderá transformar facilmente seu tempo de resposta de 500ms em mais de 1000 ms.
✅ Melhor se você testar no SSD/NVME em vez de HDD
Caso contrário, dependendo de onde seus arquivos estão localizados em HDD, você pode obter até 2x desempenho de E/S mais baixo/superior (testado), o que pode complicar pelo menos os resultados de suas consultas frias erradas.
A estrutura de teste que é usada no back-end de https://db-benchmarks.com é totalmente de código aberto (licença AGPLV3) e pode ser encontrada em https://github.com/db-benchmarks/db-benchmarks. Aqui está o que faz:
--limited )--test salva os resultados dos testes para arquivar--save salva os resultados dos testes de arquivos para um banco de dados remoto (nenhum dos que foram testados)select count(*) e select * limit 1 para garantir que as coleções de dados sejam semelhantes em diferentes bancos de dadoscpuset e mem ).Antes de implantar a estrutura de teste, verifique se você tem o seguinte:
PHP 8 e:curlmysqlidockerdocker-composesensors para controlar a temperatura da CPU para evitar limitardstatcgroups v2Para instalar:
git clone [email protected]:db-benchmarks/db-benchmarks.git
cd db-benchmarks.env.example para .envmem e cpuset em .env com o valor padrão da memória (em megabytes) e CPUs que a estrutura de teste pode usar para tarefas secundárias (carregamento de dados, obtendo informações sobre bancos de dados)ES_JAVA_OPTS para seus testes. Geralmente é o tamanho da memória alocada para a máquina Docker Primeiro você precisa preparar um teste:
Vá para o diretório de um teste específico (todos os testes devem estar no diretório ./tests ), por exemplo, "hn_small":
cd tests/hn_smallExecute o script init:
./initIsso irá:
Em seguida, corra ../../test (está na pasta da raiz do projeto) para ver as opções:
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.E execute o teste:
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 Se você executar seus testes no modo local (desenvolvimento) e não se importa com a imprecisão dos testes, você pode evitar os discos calmo e as verificações da CPU definindo o parâmetro --skip_inaccuracy
../../test --test=hn_small --engines=elasticsearch,clickhouse --memory=16384 --skip_inaccuracy Agora você tem resultados de teste em ./results/ (na raiz do repositório), por exemplo:
# ls results/
220401_054753Agora você pode fazer o upload dos resultados para o banco de dados para obter mais visualização. A ferramenta de visualização, usada em https://db-benchmarks.com/, também é de código aberto e pode ser encontrado em https://github.com/db-benchmarks/ui.
Veja como você pode salvar os resultados:
username=login password=pass host=db.db-benchmarks.com port=443 save=./results ./testou
./test --username=login --password=pass --host=db.db-benchmarks.com --port=443 --save=./results
Estamos ansiosos para ver os resultados dos seus testes. Se você acredita que eles devem ser adicionados ao https://db-benchmarks.com, faça uma solicitação de tração dos seus resultados para este repositório.
Por favor, lembre -se do seguinte:
./results .Nós iremos então:
.
|-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 elasticsearchvai:
suffix=_tuned : maps ./tests/logs10m/es/data/idx_tuned como diretório de dadosmem=32768 Limita a RAM a 32 GB, se não for especificado, o padrão será usado do arquivo .envcpuset="0,1" : o contêiner do Elasticsearch estará sendo executado apenas nos núcleos da CPU 0 e 1 (que podem ser a primeira CPU física inteira) Para parar - apenas CTRL-C .
Quer se envolver no projeto? Veja como você pode contribuir:
Tudo isso está aguardando sua contribuição!
