Relações Tabelas temporárias Tabelas não registradas Partições Arquivos temporários Sequências Objetos grandes Limites aproximados

Gerenciar contagens altas de objeto no Amazon RDS para PostgreSQL

Embora as limitações do PostgreSQL sejam teóricas, ter contagens de objetos extremamente altas em um banco de dados causará um impacto perceptível no desempenho de várias operações. Esta documentação aborda vários tipos comuns de objeto que podem causar vários impactos possíveis quando a contagem total é alta.

A seguinte tabela apresenta um resumo dos tipos de objeto e dos possíveis impactos.

Tipos de objeto e possíveis impactos
Tipo de objeto	Autovacuum	Replicação lógica	Atualização de versão principal	pg_dump/pg_restore	Desempenho geral	Reinicialização da instância
Relações	x		x	x	x
Tabelas temporárias	x				x
Tabelas não registradas		x				x
Partições					x
Arquivos temporários					x
Sequências		x
Objetos grandes		x	x

Relações

Não há um limite rígido específico em relação ao número de tabelas em um banco de dados PostgreSQL. O limite teórico é extremamente alto, mas há outros limites práticos que precisam ser considerados na fase de design do banco de dados.

Impacto: atraso do autovacuum

O autovacuum pode ter dificuldade de acompanhar o aumento de IDs de transação ou o inchaço de tabela devido à falta de operadores em comparação à quantidade de trabalho.

Ação recomendada: há vários fatores que permitem ajustar o autovacuum para acompanhar adequadamente determinado número de tabelas e determinada workload. Consulte Práticas recomendadas para trabalhar com o autovacuum do PostgreSQL para ver sugestões sobre como determinar as configurações apropriadas do autovacuum. Use o utilitário postgres_get_av_diag utility para monitorar problemas de aumento de IDs de transação.

Impacto: atualização da versão principal/pg_dump e pg_restore

O Amazon RDS usa a opção “--link” durante a execução do pg_upgrade para evitar a necessidade de fazer cópias dos arquivos de dados. Os metadados do esquema ainda assim precisam ser restaurados na nova versão do banco de dados. Mesmo com o pg_restore paralelo, se houver um número significativo de relações, isso aumentará o tempo de inatividade.

Impacto: degradação geral do desempenho

Degradação geral do desempenho devido ao tamanho do catálogo. Cada tabela e as colunas correspondentes aumentarão as tabelas pg_attribute, pg_class e pg_depend que são frequentemente usadas em operações normais de banco de dados. Não haverá um evento de espera específico visível, mas a eficiência do buffer compartilhado será afetada.

Ação recomendada: verifique regularmente o inchaço dessas tabelas específicas e, ocasionalmente, execute VACUUM FULL nessas tabelas. Lembre-se de que VACUUM FULL nas tabelas de catálogo exigem um bloqueio ACCESS EXCLUSIVE, o que significa que nenhuma outra consulta poderá acessá-las enquanto a operação não for concluída.

Impacto: esgotamento do descritor de arquivo

Error: “out of file descriptors: Too many open files in system; release and retry”. O parâmetro max_files_per_process do PostgreSQL determina quantos arquivos cada processo pode abrir. Se houver um grande número de conexões unindo um grande número de tabelas, esse limite provavelmente será atingido.

Ação recomendada:

Reduzir o valor do parâmetro max_files_per_process pode ajudar a mitigar esse erro. Cada processo e subprocesso (por exemplo, consulta paralela) pode abrir essa quantidade de arquivos e, se as consultas estiverem unindo várias tabelas, esse limite provavelmente se esgotará.
Reduza o número de conexões e use um agrupador de conexões, como o Amazon RDS Proxy ou outras soluções, como o PgBouncer. Para saber mais, consulte o site do PgBouncer.

Impacto: esgotamento de inodes

Error: “No space left on device”. Se isso for observado quando houver bastante espaço livre de armazenamento, a causa é a falta de inodes. O Monitoramento aprimorado do Amazon RDS oferece visibilidade sobre os inodes em uso e o número máximo disponível para o host.

Limite aproximado: milhões.

Tabelas temporárias

O uso de tabelas temporárias, que é útil para dados de teste ou resultados intermediários, é um padrão comum visto em muitos mecanismos de banco de dados. É necessário entender as implicações do uso intenso no PostgreSQL para evitar algumas das armadilhas. Cada tabela temporária criada e descartada adicionará linhas às tabelas de catálogo do sistema, o que causará problemas gerais de desempenho quando essas tabelas ficarem inchadas.

Impacto: atraso do autovacuum

As tabelas temporárias não são limpas pelo autovacuum. Elas ficarão atreladas aos IDs de transação enquanto existirem e poderão provocar wraparound se não forem removidas.

Ação recomendada: manter as tabelas temporárias durante a sessão que as criou ou eliminá-las manualmente. Evitar transações de longa duração com tabelas temporárias é uma prática recomendada que impedirá que essas tabelas contribuam para o aumento máximo de IDs de transação usados.

Impacto: degradação geral do desempenho

Degradação geral do desempenho devido ao tamanho do catálogo. Quando as sessões criam e eliminam continuamente tabelas temporárias, elas aumentam as tabelas pg_attribute, pg_class e pg_depend tabelas que são frequentemente usadas em operações normais de banco de dados. Não haverá um evento de espera específico visível, mas a eficiência do buffer compartilhado será afetada.

Ação recomendada:

Verifique regularmente o inchaço dessas tabelas específicas e, ocasionalmente, execute VACUUM FULL nessas tabelas. Lembre-se de que VACUUM FULL nas tabelas de catálogo exigem um bloqueio ACCESS EXCLUSIVE, o que significa que nenhuma outra consulta poderá acessá-las enquanto a operação não for concluída.
Se forem usadas muitas tabelas temporárias, é altamente recomendável executar VACUUM FULL nessas tabelas de catálogo específicas antes de uma atualização de versão principal para reduzir o tempo de inatividade.

Práticas recomendadas gerais:

Reduza o uso de tabelas temporárias utilizando expressões de tabela comuns para produzir resultados intermediários. Às vezes, isso pode complicar as consultas necessárias, mas eliminará os impactos listados acima.
Reutilize as tabelas temporárias usando o comando TRUNCATE para limpar o conteúdo em vez de executar as etapas de descartar/criar. Isso também eliminará o problema de aumento de IDs de transação provocado por tabelas temporárias.

Limite aproximado: dezenas de milhares.

Tabelas não registradas

Tabelas não registradas em log podem oferecer ganhos de desempenho, pois não geram nenhuma informação de registro em log com gravação antecipada (WAL). Visto que elas não oferecerão durabilidade durante a recuperação de falhas no banco de dados porque estarão truncadas, é necessário usá-las com cautela. Essa é uma operação cara no PostgreSQL, pois cada tabela não registrada e log é truncada em série. Embora essa operação seja rápida para um pequeno número de tabelas não registradas em log, quando o número atinge a casa de milhares, isso pode começar a causar um atraso notável durante a inicialização.

Impacto: replicação lógica: As tabelas não registradas em log geralmente não são incluídas na replicação lógica, inclusive em implantações azuis/verde, porque a replicação lógica depende do WAL para capturar e transferir alterações.

Impacto: tempo de inatividade prolongado durante a recuperação

Durante qualquer estado do banco de dados que envolva recuperação de falhas no banco de dados, como reinicialização multi-AZ com failover, recuperação para um ponto no tempo do Amazon RDS e atualização da versão principal do Amazon RDS, ocorrerá a operação serializada de truncamento das tabelas não registradas em log. Isso pode levar a uma experiência de tempo de inatividade bem maior do que o esperado.

Ação recomendada:

Minimize o uso de tabelas não registradas em log somente para dados que possam ser perdidos durante as operações de recuperação de falhas no banco de dados.
Minimize o uso de tabelas não registradas em log, pois o comportamento atual de truncamento em série pode aumentar significativamente o tempo de inicialização de um banco de dados.

Práticas recomendadas gerais:

As tabelas não registradas em log não são à prova de falhas. Iniciar uma recuperação para um ponto no tempo, o que envolve recuperação de falhas, leva um tempo significativo no PostgreSQL porque esse é um processo em série que trunca cada tabela.

Limite aproximado: milhares.

Partições

O particionamento pode aumentar o desempenho da consulta e oferecer uma organização lógica dos dados. Em cenários ideais, o particionamento é organizado para que a remoção de partições possa ser usada durante o planejamento e a execução da consulta. Usar muitas partições pode provocar impactos negativos no desempenho das consultas e na manutenção do banco de dados. A escolha de como particionar uma tabela deve ser feita com cuidado, pois o desempenho do planejamento e da execução da consulta pode ser afetado negativamente por um design ineficiente. Consulte a documentação do PostgreSQL para obter detalhes sobre particionamento.

Impacto: degradação geral do desempenho

Algumas vezes os custos indiretos do tempo de planejamento aumentarão e a explicação dos planos referentes às consultas se tornarão mais complexa, dificultando a identificação de oportunidades de ajuste. Em versões do PostgreSQL anteriores à 18, muitas partições com alta workload podem provocar esperas LWLock:LockManager.

Ação recomendada: determine um número mínimo de partições que permita concluir a organização dos dados e, ao mesmo tempo, oferecer uma execução de consulta eficiente.

Impacto: manutenção complexa

Um número muito alto de partições provocará dificuldades de manutenção, como predefinição e remoção. O autovacuum tratará as partições como relações normais e deverá realizar uma limpeza regular, exigindo, portanto, operadores suficientes para concluir a tarefa.

Ação recomendada:

Predefina as partições para que a workload não seja bloqueada quando uma nova partição for necessária (por exemplo, partições mensais) e partições antigas forem removidas.
Garanta que haja operadores de autovacuum suficientes para realizar a manutenção de limpeza normal de todas as partições.

Limite aproximado:: centenas.

Arquivos temporários

Diferentemente das tabelas temporárias mencionadas acima, o PostgreSQL cria arquivos temporários na eventualidade de uma consulta complexa executar várias operações de classificação ou de hash simultaneamente e de cada uma dessas operações utilizar a memória da instância para armazenar resultados até o valor especificado no parâmetro work_mem. Quando a memória da instância não é suficiente, arquivos temporários são criados para armazenar os resultados. Consulte Gerenciar arquivos temporários para obter mais detalhes sobre arquivos temporários. Se a workload gerar um grande número desses arquivos, poderá haver vários impactos.

Impacto: esgotamento do descritor de arquivo

Ação recomendada:

Reduzir o valor do parâmetro max_files_per_process pode ajudar a mitigar esse erro. Cada processo e subprocesso (por exemplo, consulta paralela) pode abrir essa quantidade de arquivos e, se as consultas estiverem unindo várias tabelas, esse limite provavelmente se esgotará.
Reduza o número de conexões e use um agrupador de conexões, como o Amazon RDS Proxy, ou outras soluções, como o PgBouncer. Para saber mais, consulte o site do PgBouncer.

Impacto: esgotamento de inodes

Práticas recomendadas gerais:

Monitore o uso de arquivos temporários com o Insights de Performance.
Ajuste as consultas que estão gerando arquivos temporários significativos para ver se é possível reduzir o número total de arquivos temporários.

Limite aproximado: milhares.

Sequências

As sequências são o objeto subjacente usado para acrescentar colunas automaticamente no PostgreSQL e oferecem exclusividade e uma chave para os dados. Elas podem ser usadas em tabelas individuais sem problemas durante operações normais, exceto na replicação lógica.

No momento, no PostgreSQL, a replicação lógica não replica o valor atual de uma sequência para nenhum assinante. Para saber mais, consulte a página Restrictions na documentação do PostgreSQL.

Impacto: tempo de transição estendido

Se você planeja usar implantações azuis/verdes do Amazon RDS para qualquer tipo de alteração ou atualização de configuração, é importante entender o impacto de ter um grande número de sequências na transição. Uma das fases finais da transição sincronizará o valor atual das sequências e, se houver vários milhares, isso aumentará o tempo geral de transição.

Ação recomendada: se a workload do banco de dados permitir o uso de um UUID compartilhado em vez de uma abordagem de sequência por tabela, isso poderá reduzir a etapa de sincronização durante a transição.

Limite aproximado: milhares.

Objetos grandes

Objetos grandes são armazenados em uma única tabela do sistema chamada pg_largeobject. Cada objeto grande também tem uma entrada na tabela do sistema pg_largeobject_metadata. O processo de criação, modificação e limpeza desses objetos é bem diferente do utilizado nas relações padrão. Os objetos grandes não são processados pelo autovacuum e devem ser limpos periodicamente por meio de um processo separado, chamado vacuumlo. Consulte “Gerenciar objetos grandes com o módulo lo” para ver exemplos sobre como gerenciar objetos grandes.

Impacto: replicação lógica: No momento, não é possível replicar objetos grandes no PostgreSQL durante a replicação lógica. Para saber mais, consulte a página Restrictions na documentação do PostgreSQL. Em uma configuração azul/verde, isso significa que objetos grandes no ambiente azul não são replicados no ambiente verde.
Impacto: atualização de versão principal: Uma atualização poderá ficar sem memória e falhar se houver milhões de objetos grandes, e a instância não puder manipulá-los durante uma atualização. O processo de atualização da versão principal do PostgreSQL compreende duas fases amplas: despejar o esquema via pg_dump e restaurá-lo por meio de pg_restore. Se seu banco de dados tiver milhões de objetos grandes, você precisará garantir que sua instância tenha memória suficiente para lidar com o pg_dump e o pg_restore durante uma atualização e escalá-la para um tipo de instância maior.

Práticas recomendadas gerais:

Use regularmente o utilitário vacuumlo para remover qualquer objeto grande órfão que você possa ter.
Considere a possibilidade de usar o tipo de dados BYTEA para armazenar objetos grandes no banco de dados.

Limite aproximado: milhões.

Limites aproximados

Os limites aproximados mencionados neste tópico são usados somente para oferecer uma estimativa de até que ponto determinado recurso pode ser escalado. Eles representam o âmbito geral em que os impactos descritos se tornam mais prováveis, mas o comportamento real depende de fatores específicos, como workload, tamanho da instância e configuração. Embora seja possível exceder essas estimativas, é necessário seguir as operações de cuidado e manutenção para evitar os impactos listados.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Explicação das mensagens de AVISO

Gerenciar a contenção de TOAST OID