Otimiza o processamento de métricas e prepara a versão 2.3.0

[pitangainnovare]

O que esse PR faz?

Consolida as otimizações do processamento de métricas e atualiza a aplicação para usage 2.3.0.

As mudanças incluem:

• atualização para scielo_usage_counter 2.2.0;
• redução das conversões de data no caminho percorrido por cada acesso;
• instrumentação separada de parsing, conversão, serialização e OpenSearch;
• serialização incremental dos payloads com cálculo simultâneo do SHA-256;
• gravação temporária e substituição atômica do payload;
• acumulador diário compacto com compartilhamento de metadados de documento, fonte e sessão;
• remoção da duplicação de timestamps no estado diário;
• conversão sequencial das métricas mensais e anuais;
• atualização da versão pública para 2.3.0.

O formato dos payloads, mappings, transporte e cálculos COUNTER permanecem inalterados.

Onde a revisão poderia começar?

A revisão pode começar em:

• metrics/counter/access/accumulation.py;
• metrics/counter/access/daily_accumulator.py;
• metrics/counter/indexing/converter.py;
• metrics/services/parsing/job_payloads.py;
• metrics/services/daily_payloads.py.

Como este poderia ser testado manualmente?

Executar no ambiente Docker:

pytest -q
python manage.py makemigrations --check --dry-run
python manage.py migrate --check

Resultados locais:

187 passed, 2 skipped
No changes detected
Nenhuma migration pendente

Foram feitas comparações controladas do conteúdo destinado ao OpenSearch:

• Books completo: payload idêntico;
• PRT completo: payload idêntico;
• SCL com 100 mil linhas: payload idêntico;
• mesmo número de linhas válidas, registros acumulados e documentos mensais e anuais.

O log SCL completo de 4,07 milhões de linhas apresentou pico de aproximadamente 9,84 GiB, abaixo da meta de 10 GiB.

Algum cenário de contexto que queira dar?

O acumulador anterior mantinha grande quantidade de estruturas repetidas e a serialização criava uma string JSON completa antes da gravação. Em coleções grandes, especialmente SCL, isso elevava o tempo e o pico de memória do processamento.

A homologação oficial será realizada somente com a versão consolidada 2.3.0, após a publicação de scielo_usage_counter 2.2.0.

Screenshots

Não aplicável.

Quais são os tickets relevantes?

Conclui #128

Referências

Requer scielo_usage_counter 2.2.0.

---

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

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

• Sim — identificadores derivados dos logs são mantidos temporariamente em memória para classificação e deduplicação. Não há nova persistência ou exposição desses valores.
• Não

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

• Sim
• Não

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

• Sim — atualiza a biblioteca interna scielo_usage_counter para 2.2.0.
  • Verificado e aprovado
  • Pendente — validar no SBOM/Trivy do pipeline.
• Não

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

• Sim
• Não aplicável neste momento — aguardando os checks do PR.

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

• Sim
• Não

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

• Sim
• Não

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

• Não, nenhum segredo foi commitado
• Sim