Hologres:Stress testing data writes, updates, and point queries

Mecanismo de gravação e atualização

A ferramenta suporta dois modos de gravação:

• Modo Fixed Copy -- Usa a instrução COPY do PostgreSQL, otimizada com Fixed Plan para execução SQL mais rápida.

• Modo Insert -- Usa instruções INSERT padrão, também otimizadas com Fixed Plan.

Em ambos os modos, a ferramenta adiciona automaticamente duas colunas à tabela:

Para cada coluna TEXT configurada, a ferramenta grava uma string do comprimento especificado com o valor de id concatenado. O teste é encerrado quando o número de linhas ou a duração alvo é atingido.

Durante as atualizações, o mesmo padrão incremental de id é utilizado. Para atualizações parciais, apenas um subconjunto das colunas TEXT é reescrito.

Mecanismo de consulta pontual

A ferramenta suporta dois modos de consulta:

• Modo assíncrono -- A API de consulta pontual é não bloqueante. Múltiplas requisições são agrupadas em uma única instrução SQL, maximizando o throughput. Mais indicado para cenários de alto throughput, como junções de tabelas em tempo real baseadas em Flink.

• Modo síncrono -- A API de consulta pontual é bloqueante. Cada requisição corresponde a uma instrução SQL e é concluída antes da próxima iniciar. Recomendado para cenários sensíveis à latência.

Durante o teste, a ferramenta seleciona aleatoriamente uma chave primária dentro do intervalo configurado e executa uma consulta pontual. O teste é encerrado quando a duração alvo é atingida.

Sobre a ferramenta de teste

holo-e2e-performance-tool é uma ferramenta open-source desenvolvida pela equipe do Hologres. Ela integra criação de tabelas, geração de dados de teste e medição de desempenho em um único JAR, dispensando a preparação prévia de dados de teste. A chave primária dos dados gerados é uma sequência de inteiros consecutivos, o que garante taxas de acerto completas durante os testes de atualização e consulta pontual.

Passo 1: Crie o arquivo de configuração

Na instância ECS, crie um arquivo chamado test_insert.conf com o seguinte conteúdo:

# Connection configuration
holoClient.jdbcUrl=jdbc:hologres://<ENDPOINT>:<PORT>/<DBNAME>
holoClient.username=<AccessKey_ID>
holoClient.password=<AccessKey_Secret>
holoClient.writeThreadSize=100

# Write configuration
put.threadSize=8
put.testByTime=false
put.rowNumber=200000000
put.testTime=600000

# Table configuration
put.tableName=kv_test
put.columnCount=20
put.columnSize=20
put.orientation=row

# Other configurations
put.createTableBeforeRun=true
put.deleteTableAfterDone=false
put.vacuumTableBeforeRun=false

Este exemplo cria uma tabela orientada a linha. Para testar uma tabela orientada a coluna ou híbrida linha-coluna, altere orientation para column ou row,column .

Substitua os marcadores pelos valores reais:

Parâmetros de configuração

Passo 2: Execute o teste

# Fixed Copy mode
java -jar holo-e2e-performance-tool-1.0.0.jar test_insert.conf FIXED_COPY

# Or, Insert mode
java -jar holo-e2e-performance-tool-1.0.0.jar test_insert.conf INSERT

Passo 3: Visualize os resultados

cat result.csv

Consulte Campos do resultado para o formato de saída.

Atualização global

1. Crie um arquivo chamado test_update.conf. Use a mesma configuração do teste de gravação, alterando createTableBeforeRun para false:

   A única alteração em relação à configuração do teste de gravação é createTableBeforeRun=false . Isso preserva a tabela e os dados existentes.

      # Connection configuration
      holoClient.jdbcUrl=jdbc:hologres://<ENDPOINT>:<PORT>/<DBNAME>
      holoClient.username=<AccessKey_ID>
      holoClient.password=<AccessKey_Secret>
      holoClient.writeThreadSize=100
   
      # Write configuration
      put.threadSize=8
      put.testByTime=false
      put.rowNumber=200000000
      put.testTime=600000
   
      # Table configuration
      put.tableName=kv_test
      put.columnCount=20
      put.columnSize=20
      put.orientation=row
   
      # Other configurations
      put.createTableBeforeRun=false
      put.deleteTableAfterDone=false
      put.vacuumTableBeforeRun=false

2. Execute o teste:

      java -jar holo-e2e-performance-tool-1.0.0.jar test_update.conf FIXED_COPY

3. Visualize os resultados:

      cat result.csv

Atualização parcial

A atualização parcial grava em um subconjunto das colunas TEXT. O parâmetro writeColumnCount controla quantas colunas são atualizadas.

1. Crie um arquivo chamado test_update_part.conf. Adicione o parâmetro writeColumnCount à seção de configuração de tabela:

   writeColumnCount=10 atualiza 10 das 20 colunas TEXT (50%). Ajuste essa proporção de acordo com sua carga de trabalho.

      # Connection configuration
      holoClient.jdbcUrl=jdbc:hologres://<ENDPOINT>:<PORT>/<DBNAME>
      holoClient.username=<AccessKey_ID>
      holoClient.password=<AccessKey_Secret>
      holoClient.writeThreadSize=100
   
      # Write configuration
      put.threadSize=8
      put.testByTime=false
      put.rowNumber=200000000
      put.testTime=600000
   
      # Table configuration
      put.tableName=kv_test
      put.columnCount=20
      put.columnSize=20
      put.writeColumnCount=10
      put.orientation=row
   
      # Other configurations
      put.createTableBeforeRun=false
      put.deleteTableAfterDone=false
      put.vacuumTableBeforeRun=false

2. Execute o teste:

      java -jar holo-e2e-performance-tool-1.0.0.jar test_update_part.conf FIXED_COPY

3. Visualize os resultados:

      cat result.csv

Passo 1: Crie o arquivo de configuração

Crie um arquivo chamado test_get.conf:

# Connection configuration
holoClient.jdbcUrl=jdbc:hologres://<ENDPOINT>:<PORT>/<DBNAME>
holoClient.username=<AccessKey_ID>
holoClient.password=<AccessKey_Secret>
holoClient.readThreadSize=32

# Test configuration
get.threadSize=8
get.testTime=300000
get.tableName=kv_test
get.async=true
get.vacuumTableBeforeRun=true
get.keyRangeParams=L1-200000000

# Table initialization configuration (used only in PREPARE_GET_DATA mode)
prepareGetData.rowNumber=200000000
prepareGetData.orientation=row
put.columnCount=20
put.columnSize=20

Este exemplo configura consultas pontuais assíncronas em uma tabela orientada a linha. Para testar consultas síncronas, defina get.async=false e ajuste threadSize e readThreadSize conforme necessário (consulte a tabela de parâmetros abaixo).

Parâmetros de consulta pontual

Passo 2: Execute o teste

Se a tabela já contém dados dos testes de gravação ou atualização, pule a preparação de dados e execute a consulta pontual diretamente:

# (Optional) Prepare data -- only if the table has no data
java -jar holo-e2e-performance-tool-1.0.0.jar test_get.conf PREPARE_GET_DATA

# Run the point query test
java -jar holo-e2e-performance-tool-1.0.0.jar test_get.conf GET

Para usar dados reais de negócio em vez de dados gerados, a tabela deve ter uma chave primária de coluna única do tipo INT ou BIGINT com valores consecutivos.

Passo 3: Visualize os resultados

cat result.csv

Escolha um formato de armazenamento

Antes de analisar os números, use este guia para selecionar o formato de armazenamento adequado à sua carga de trabalho:

20 colunas

50 colunas

100 colunas

Principais conclusões

• Tabelas orientadas a linhas oferecem o maior throughput de gravação — aproximadamente 3x mais rápido que tabelas orientadas a colunas para o mesmo número de colunas.

• Atualizações parciais superam as atualizações globais em tabelas orientadas a linhas porque menos colunas são reescritas. Em tabelas orientadas a colunas e híbridas linha-coluna, as atualizações globais podem igualar ou superar o throughput das atualizações parciais.

• A latência de consultas pontuais é semelhante entre tabelas orientadas a linhas e híbridas linha-coluna, normalmente abaixo de 10 ms para tabelas de 20 colunas.

• Consultas pontuais assíncronas atingem QPS mais alto do que consultas síncronas, porém com latência ligeiramente maior.

• O throughput de gravação e atualização diminui conforme o número de colunas aumenta — uma tabela orientada a linhas com 100 colunas atinge cerca de 28% do QPS de gravação de uma tabela com 20 colunas. O throughput de consultas pontuais é menos afetado, mantendo de 50% a 60% do QPS com 100 colunas em comparação com 20 colunas.

O cliente ECS se torna o gargalo

Sintoma: O QPS atinge um platô mesmo com baixa utilização de CPU na instância Hologres.

Causa: A instância ECS que executa a ferramenta de teste atingiu o limite de CPU ou de largura de banda de rede.

Solução: Monitore as métricas de CPU e rede da ECS durante o teste. Se alguma estiver saturada, faça upgrade para um tipo de instância ECS maior ou reduza o threadSize.

QPS abaixo do esperado

Sintoma: O QPS é significativamente inferior aos resultados de benchmark listados acima.

Possíveis causas e soluções:

1. Concorrência insuficiente — Se a utilização de CPU do Hologres estiver baixa, aumente o threadSize (para gravações e atualizações) ou o readThreadSize (para consultas pontuais).

2. Instância passou por upgrade ou downgrade — As características de desempenho diferem entre instâncias novas e redimensionadas. Crie uma nova instância para executar os benchmarks.

3. Latência de rede — Confirme que a instância ECS e a instância Hologres estão no mesmo VPC e na mesma zona.

4. Distorção de dados — Ao usar dados personalizados, valores desbalanceados na chave de distribuição podem concentrar a carga em um subconjunto de shards.

Erros de conexão

Sintoma: A ferramenta de teste falha com exceções relacionadas à conexão.

Solução: Verifique a string de conexão JDBC, o AccessKey ID e o segredo do AccessKey. Confirme que a instância Hologres permite conexões originadas do VPC da instância ECS.