Reduz o consumo de memória na acumulação diária de acessos

[pitangainnovare]

O que esse PR faz?

Reduz o consumo de memória durante o processamento diário de logs, substituindo a retenção de milhões de dicionários e estruturas repetidas por uma representação compacta.

A implementação:

• interna strings, sessões, fontes e documentos repetidos;
• utiliza chaves binárias compactas para identificar acessos e sessões;
• mantém URL e timestamp diretamente no registro no caso mais frequente;
• promove a estrutura de timestamps somente quando existem múltiplos valores;
• materializa os dicionários apenas durante a conversão das métricas;
• preserva o caminho legado baseado em dict.

No benchmark com o log SCL completo de 24/08/2026, o pico de memória caiu de 10.405,8 MiB para 6.985,0 MiB, uma redução de 32,9%. Ao final do parsing, a redução foi de 55,9%, de 6.029,7 MiB para 2.661,1 MiB.

O tempo total até a geração do payload permaneceu praticamente estável: 532,886 segundos antes e 533,506 segundos depois.

O payload permaneceu byte a byte idêntico:

1da947e9db472e08292fcac3dbd0fd9b557efd653bf47bac6dd7a0e5cbf99bc1

Onde a revisão poderia começar?

A revisão pode começar em:

metrics/counter/access/daily_accumulator.py

Depois, verificar a integração em:

• metrics/counter/access/accumulation.py
• metrics/counter/indexing/converter.py
• metrics/tests/counter/access/test_accumulation.py

Como este poderia ser testado manualmente?

Executar:

docker compose -f local.yml run --rm django \
  pytest metrics/tests/counter/access -q

docker compose -f local.yml run --rm django \
  pytest metrics/tests -q

docker compose -f local.yml run --rm django pytest -q

Resultados obtidos localmente:

• testes focados: 24 aprovados;
• suíte de métricas: 134 aprovados e 2 ignorados;
• suíte completa: 191 aprovados e 2 ignorados;
• nenhuma migration detectada;
• flake8 e git diff --check sem erros.

Para validar o ganho de memória, processar isoladamente um log SCL completo, sem exportar para índices canônicos, e comparar pico de RSS, contagens e SHA-256 do payload.

Algum cenário de contexto que queira dar?

Um log diário SCL possui aproximadamente 2,9 milhões de linhas e gerava cerca de 2,7 milhões de registros brutos no acumulador. Aproximadamente 98% dos eventos válidos criavam um registro próprio, normalmente contendo apenas uma URL e um timestamp, mas repetindo estruturas completas de documento, fonte e sessão.

A otimização ataca essa duplicação interna sem alterar as regras COUNTER, os mappings do OpenSearch ou o formato dos documentos exportados.

A fila parse_xlarge deve continuar com concorrência 1. Esta alteração reduz a pressão de memória, mas não torna seguro processar vários dias SCL simultaneamente.

Screenshots

Não aplicável.

Quais são os tickets relevantes?

Relaciona-se a #128.

Referências

• Benchmark local com o log SCL de 24/08/2026.
• Payload de referência com 2.173.212.349 bytes.
• Comparação byte a byte por SHA-256.

---

Segurança da informação (NSI.04)

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Não aplicável a este PR — não há dependências ou componentes de infraestrutura novos; os checks do repositório serão executados no PR.

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Não

Este PR expõe novos endpoints, telas ou serviços?

• Não

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado