Introdução
A adoção do OCI PostgreSQL oferece aos times de engenharia uma infraestrutura robusta, mas o desempenho depende intrinsecamente da forma como as queries são desenhadas e como o banco é administrado. Para empresas brasileiras que buscam escalar operações sem desperdício de recursos (um pilar fundamental de FinOps), não basta provisionar o serviço; é preciso aplicar práticas de engenharia que reduzam a latência e o consumo de I/O.
1. Query Writing & Code Optimization
O design da query é o primeiro ponto de estrangulamento. Evitar o SELECT * é básico, mas em escala, a seleção explícita de colunas reduz significativamente o overhead de rede e memória. O uso de tipos de dados adequados (ex: INTEGER vs BIGINT) e o alinhamento correto de tipos em JOINs previne implicit casting, que frequentemente anula o benefício dos índices e aumenta o uso de CPU.
- Pagination: Abandone o
OFFSETpara grandes volumes de dados. Use Keyset Pagination (o padrãoWHERE id > X LIMIT Y) para garantir time complexity constante, independentemente da profundidade da página. - Gestão de Transações: Mega-transações são inimigas da estabilidade e geram locking excessivo. Utilize o Batch Pattern para processar grandes volumes, protegendo não só seu throughput, mas também evitando picos no Write Ahead Log (WAL) que afetam a performance do storage.
- Evolução da Estrutura: Para índices, evite UUIDs v4 aleatórios se o volume de escrita for alto; adote o UUID v7 para manter a localidade e minimizar o fracionamento de páginas. Em tabelas gigantes, a estratégia de Partitioning baseada em intervalos (como
RANGEpor data) é indispensável para manter a manutenibilidade.
2. OCI PostgreSQL Indexing
O índice é uma faca de dois gumes: essencial para leitura, custoso para escrita. A escolha do tipo de índice deve casar com o padrão de acesso:
- B-Tree: O padrão para buscas por igualdade e range.
- GIN/GiST: Indispensáveis se o seu stack utiliza colunas
JSONBou busca textual avançada. - BRIN: Uma jóia oculta para tabelas imensas com dados naturalmente ordenados (ex: logs ou séries temporais), oferecendo um footprint de armazenamento minúsculo em comparação a índices B-Tree.
Audite regularmente a utilização de índices com pg_stat_user_indexes. Índices não utilizados (idx_scan = 0) não servem apenas para ocupar espaço; eles penalizam cada operação INSERT ou UPDATE do seu sistema.
3. Resource Monitoring / Troubleshooting
Performance é um exercício contínuo de observabilidade. A combinação de pg_stat_statements e EXPLAIN ANALYZE é o kit básico de qualquer DBA ou engenheiro DevOps. Se a CPU está batendo 85% consistentemente, não tente apenas escalar verticalmente (aumentar o shape); primeiro, verifique se não há queries com full table scans desnecessários.
4. Database Connectivity
No OCI, a disciplina com endpoints é crítica. Jamais utilize IPs hardcoded. Utilize sempre o FQDN, separando claramente o Primary Endpoint para tráfego de CUD (Create, Update, Delete) e o Replica/Reader Endpoint para analytics ou relatórios. Isso escala horizontalmente sua capacidade de leitura e preserva a integridade do nó primário.
Artigo originalmente publicado por Arvind Yadav em cloud-infrastructure.
