Protocolo: Qual o impacto do volume de consultas simultâneas do Metabase sobre uma réplica PostgreSQL carregada com dados extraídos do Protheus?
Este protocolo mede como o desempenho da réplica PostgreSQL é afetado por diferentes quantidades de consultas simultâneas do Metabase. O objetivo é identificar o ponto de saturação antes de ocorrer degradação perceptível de latência.
Roteiro para estudo em ambiente de laboratório ou de teste. Execute apenas em equipamentos, redes e contas que você tenha autorização para usar, com backup e homologação próprios. Comandos podem causar indisponibilidade ou perda de dados. Software e marcas citados pertencem aos seus titulares. Termos de Uso.
Até quantas consultas simultâneas do Metabase a réplica PostgreSQL suporta sem ultrapassar 1 segundo de latência média por consulta?
Hipótese
Aumentar o número de consultas simultâneas do Metabase eleva a latência média das respostas do PostgreSQL, mas até um certo limite a variação é tolerável.
Variáveis
| Independentes (o que varia) | número de consultas simultâneas (threads) |
|---|---|
| Dependentes (o que se mede) | latência média da consulta (ms); taxa de erro (%) |
| Controladas (o que fica fixo) | hardware do servidor PostgreSQL; versão do PostgreSQL (exemplo: 16); versão do Metabase (exemplo: 0.48.0); tipo de consulta executada (query SELECT padronizada sobre fato_venda); volume de dados (exemplo: 1 milhão de linhas em fato_venda); rede entre Metabase e PostgreSQL |
Ambiente
Servidor PostgreSQL dedicado com réplica dos dados extraídos do Protheus para o esquema bi_varejo. Metabase instalado em container Docker na mesma rede local. Ferramenta de teste: pgbench (open source) para simular consultas concorrentes. Monitoramento opcional com Prometheus.
Procedimento
- Preparação dos dados
Garanta que o esquema bi_varejo está carregado com volume representativo de dados extraídos do Protheus.
- Configuração do Metabase
Conecte o Metabase à réplica PostgreSQL, sem cache de consultas habilitado.
- Definição da consulta padrão
Escolha uma query SELECT típica usada em dashboards (exemplo: soma de vendas por loja no último mês).
- Execução do teste com pgbench
Execute pgbench simulando diferentes números de threads (exemplo: 1, 5, 10, 20, 50, 100) usando a query definida.
pgbench -h <host> -U <user> -d <database> -c <threads> -T 60 -f consulta.sql - Coleta dos resultados
Registre latência média, desvio padrão e taxa de erro em cada rodada.
- Repita cada rodada
Execute cada configuração de concorrência pelo menos 5 vezes para obter média e variância.
Planilha de coleta
| threads (unidades) | latencia_media_ms (milissegundos) | desvio_padrao_ms (milissegundos) | taxa_erro_pct (porcentagem) |
|---|---|---|---|
| EXEMPLO: 20, 850, 120, 0 | |||
Repetições recomendadas: 5. Baixe a planilha vazia em CSV: colunas prontas.
Análise
Calcule a média e o desvio padrão da latência para cada nível de concorrência. Identifique o ponto em que a latência média ultrapassa 1000 ms ou a taxa de erro supera 1%. Compare os resultados entre as rodadas para avaliar consistência.
Critérios de decisão
- Latência média por consulta não pode ultrapassar 1000 ms em mais de 3 das 5 repetições por nível de concorrência.
- Taxa de erro deve permanecer abaixo de 1%.
Fontes de erro e mitigação
- Variação de carga no servidor durante o teste; mitigue executando testes em horários controlados.
- Cache do PostgreSQL pode influenciar resultados; reinicie o serviço ou limpe o cache entre rodadas se possível.
- Rede instável pode distorcer latência; use rede local dedicada.
Referências
- fonte oficial · PostgreSQL Global Development Group (postgresql.org)
- fonte oficial · Metabase (metabase.com)
- fonte oficial · Tdn.totvs (tdn.totvs.com)
- Publicado
- 11/09/2026
- Última revisão
- 14/09/2026
- Versão do conteúdo
- 1.0
- Referências
- 3 oficiais
- Revisão técnica
- redação e revisão por IA, URLs conferidas na publicação
- Status
- Atual
