Skip to main content
  • Certifique-se de que sua máquina host atenda aos pré-requisitos exigidos pelo QPL
  • deflate_qpl é habilitado por padrão durante a compilação com CMake. Caso você o altere acidentalmente, verifique novamente a flag de compilação: ENABLE_QPL=1
  • Para os requisitos gerais, consulte as instruções gerais de compilação do ClickHouse

Lista de arquivos

A pasta benchmark_sample em qpl-cmake traz exemplos de como executar benchmarks com scripts Python: client_scripts contém scripts Python para executar benchmarks típicos, por exemplo:
  • client_stressing_test.py: Script Python para teste de estresse de consultas com [1~4] instâncias de servidor.
  • queries_ssb.sql: O arquivo lista todas as consultas do Star Schema Benchmark
  • allin1_ssb.sh: Este script shell executa automaticamente todo o fluxo de benchmark em um único processo.
database_files indica que os arquivos do banco de dados serão armazenados de acordo com o codec lz4/deflate/zstd.

Execute automaticamente o benchmark para esquema em estrela:

Após concluir, verifique todos os resultados nesta pasta:./output/ Caso haja alguma falha, execute manualmente o benchmark conforme as seções abaixo.

Definição

[CLICKHOUSE_EXE] significa o caminho para o programa executável clickhouse.

Ambiente

[Autoverificação de IAA]
Saída esperada como esta:
Se nada for exibido, isso significa que o IAA não está pronto para funcionar. Verifique a configuração do IAA novamente.

Gerar dados brutos

Use dbgen para gerar dados com 100 milhões de linhas usando os parâmetros: -s 20 Espera-se que arquivos como *.tbl sejam gerados em ./benchmark_sample/rawdata_dir/ssb-dbgen:

Configuração do banco de dados

Configure o banco de dados com o codec LZ4
Aqui, você deverá ver a mensagem Connected to ClickHouse server no console, o que significa que o cliente configurou com sucesso a conexão com o servidor. Conclua as três etapas abaixo mencionadas em Star Schema Benchmark
  • Criar tabelas no ClickHouse
  • Inserir dados. Aqui, use ./benchmark_sample/rawdata_dir/ssb-dbgen/*.tbl como dados de entrada.
  • Converter o “star schema” em um “flat schema” desnormalizado
Configure o banco de dados com o codec IAA Deflate
Repita as mesmas três etapas do lz4 acima Configure o banco de dados com o codec ZSTD
Conclua as mesmas três etapas do lz4 acima. [self-check] Para cada codec (lz4/zstd/deflate), execute a consulta abaixo para confirmar que os bancos de dados foram criados com sucesso:
Você deverá ver a saída abaixo:
[Autoverificação do codec IAA Deflate] Na primeira vez que você executar uma inserção ou consulta no cliente, o console do ClickHouse server deverá exibir este log:
Se isso nunca aparecer, mas você vir outro log como abaixo:
Isso significa que os dispositivos IAA não estão prontos; verifique a configuração do IAA novamente.

Benchmark com uma única instância

  • Antes de iniciar o benchmark, desative o C6 e defina o governador de frequência da CPU como performance
  • Para eliminar o impacto da vinculação de memória entre soquetes, usamos numactl para fixar o servidor em um soquete e o cliente em outro.
  • Instância única significa um único servidor conectado a um único cliente
Agora execute o benchmark para LZ4/Deflate/ZSTD, respectivamente: LZ4:
IAA deflate:
ZSTD:
Agora, devem ser exibidos três logs, como esperado:
Como verificar as métricas de desempenho: Nosso foco é QPS; procure pela palavra-chave QPS_Final e colete as estatísticas

Benchmark com múltiplas instâncias

  • Para reduzir o impacto da limitação de memória causada pelo excesso de threads, recomendamos executar o benchmark com múltiplas instâncias.
  • Múltiplas instâncias significa usar vários servidores (2 ou 4), cada um conectado ao seu respectivo cliente.
  • Os núcleos de um socket precisam ser divididos igualmente e atribuídos aos respectivos servidores.
  • Para múltiplas instâncias, é necessário criar uma nova pasta para cada codec e inserir os dados seguindo etapas semelhantes às de uma instância única.
Há 2 diferenças:
  • No lado do cliente, você precisa iniciar o ClickHouse com a porta atribuída durante a criação da tabela e a inserção de dados.
  • No lado do servidor, você precisa iniciar o ClickHouse com o arquivo de configuração XML específico no qual a porta foi atribuída. Todos os arquivos de configuração XML personalizados para múltiplas instâncias foram fornecidos em ./server_config.
Aqui, assumimos que há 60 núcleos por socket e usamos 2 instâncias como exemplo. Inicie o servidor para a primeira instância LZ4:
ZSTD:
IAA Deflate:
[Inicie o servidor da segunda instância] LZ4:
ZSTD:
IAA Deflate:
Criação de tabelas && inserção de dados para a segunda instância Criação de tabelas:
Inserção de dados:
  • [TBL_FILE_NAME] representa o nome de um arquivo cujo nome corresponde à expressão regular: *. tbl em ./benchmark_sample/rawdata_dir/ssb-dbgen.
  • --port=9001 indica a porta atribuída à instância do servidor, que também está definida em config_lz4_s2.xml/config_zstd_s2.xml/config_deflate_s2.xml. Para mais instâncias, você precisa substituí-lo pelos valores 9002/9003, que correspondem às instâncias s3/s4, respectivamente. Se você não a definir, a porta padrão será 9000, que já foi usada pela primeira instância.
Benchmark com 2 instâncias LZ4:
ZSTD:
IAA deflate
Aqui, o último argumento, 2, de client_stressing_test.py representa o número de instâncias. Para usar mais instâncias, você precisa substituí-lo pelo valor 3 ou 4. Este script oferece suporte a até 4 instâncias/ Agora, três logs devem ser exibidos, como esperado:
Como verificar as métricas de desempenho: Nosso foco é QPS; pesquise pela palavra-chave QPS_Final e colete as estatísticas. A configuração do benchmark para 4 instâncias é semelhante à das 2 instâncias acima. Recomendamos usar os dados do benchmark de 2 instâncias como relatório final para análise.

Dicas

Antes de iniciar um novo ClickHouse server, certifique-se de que não há nenhum processo do ClickHouse em segundo plano em execução; verifique e finalize o antigo:
Ao comparar a lista de consultas em ./client_scripts/queries_ssb.sql com o Star Schema Benchmark oficial, você verá que 3 consultas não estão incluídas: Q1.2/Q1.3/Q3.4 . Isso ocorre porque a utilização de CPU é muito baixa < 10% nessas consultas, o que significa que elas não demonstram diferenças de desempenho.
Última modificação em 3 de julho de 2026