Opa.
Obrigado pela resposta.
Eu fiz testes com o sistema de particionamento do Postgres mas não obtive resultados satisfatórios.
O problema era que em uma parte era preciso fazer um count nos registros pra fins de paginação e em nenhum dos meus testes eu consegui resultados aceitáveis com o postgres.
Respondendo a "Esse foi um post muito bacana sobre otimização...." dentro da publicação Como otimizei um problema de desempenho de um sistema na empresa.
2
1
Entendo. No caso, eu evitaria usar o "Count" diretamente e, ao invés disso, criaria uma tabela separada para gerenciar a contagem de registros de forma incremental, o que tornaria a operação de paginação muito mais eficiente.
Na realidade eu partiria de algumas premissas de manutenção do banco de dados como:
-
Índices por data (366 por ano) com Time-To-Live (TTL) de 1 ano:
- Os dados com mais de um ano poderiam ser transferidos para Amazon RDS para fins de compliance, sem a necessidade de manter esses índices ativos no banco principal, o que ajuda a evitar o aumento descontrolado do tamanho do banco.
- Como os índices não são interdependentes, acredito que seria mais fácil atualizar um índice por vez, em vez de manter e gerenciar 366 bancos separados. Isso facilita a manutenção e permite um gerenciamento mais eficiente.
-
Sub tabela de contagem para cada índice, para facilitar a paginação sem usar o caro COUNT:
- Caso não haja registros no índice de um determinado dia, começaria a contagem com o valor 0.
- Se já houver registros, utilizaria um COUNT inicial para pegar o valor atual da contagem, e em seguida, a contagem seria mantida e atualizada via transações incrementais para cada novo registro.
Assim, sempre que for necessário realizar paginação, a contagem já estará disponível de forma simples e rápida, com um SELECT.
Mas, obviamente, isso é especulação minha com base nas informações fornecidas. Foi mais um exercício lógico sobre como eu estruturaria a arquitetura no PostgreSQL, do que uma solução definitiva para a sua situação.