PostgreSQL 11: A evolução do particionamento do Postgres 9.6 para o Postgres 11

Grande sexta-feira a todos! Menos e menos tempo resta até o lançamento do curso Relational DBMS , então hoje estamos compartilhando a tradução de outro material útil sobre o assunto.



Durante o processo de desenvolvimento do PostgreSQL 11 , um trabalho impressionante foi feito para melhorar o particionamento de tabelas. O particionamento de tabela é uma função que existe no PostgreSQL há algum tempo, mas, por assim dizer, ele realmente não existia até a versão 10, na qual se tornou uma função muito útil. Anteriormente, declaramos que a herança de tabela é a nossa implementação de particionamento, e é verdade. Somente esse método forçou você a fazer a maior parte do trabalho manualmente. Por exemplo, se você queria que as tuplas fossem inseridas em seções durante INSERTs, era necessário configurar gatilhos para fazer isso por você. Particionar usando herança era muito lento e difícil de desenvolver funções adicionais.

No PostgreSQL 10, vimos o nascimento do "particionamento declarativo", um recurso projetado para resolver muitos problemas que eram insolúveis ao usar o método antigo com herança. Isso levou ao surgimento de uma ferramenta muito mais poderosa que nos permite dividir os dados horizontalmente!

Comparação de recursos

O PostgreSQL 11 apresenta uma impressionante variedade de novos recursos que ajudam a melhorar o desempenho e tornar as tabelas particionadas mais transparentes para os aplicativos.




1. Usando exceções restritivas
2. Adiciona apenas nós
3. Somente para uma tabela particionada que se refere a uma tabela não particionada
4. Os índices devem conter todas as colunas principais de uma seção
5. A restrição na seção de ambos os lados deve corresponder

Desempenho

Aqui também temos boas notícias! Um novo método para excluir seções foi adicionado. Esse novo algoritmo pode determinar seções adequadas observando a condição de consulta WHERE . O algoritmo anterior, por sua vez, verificou cada seção para determinar se poderia corresponder à WHERE . Isso levou a um aumento adicional no tempo de planejamento, à medida que o número de seções aumentou.

Na 9.6, com o particionamento por herança, as tuplas de roteamento em uma seção geralmente eram feitas escrevendo uma função de gatilho que continha uma série de instruções IF para inserir a tupla na seção correta. Essas funções podem ser muito lentas para executar. Com o particionamento declarativo adicionado na versão 10, isso se tornou muito mais rápido.

Usando uma tabela particionada com 100 seções, podemos estimar o desempenho do carregamento de 10 milhões de linhas em uma tabela de 1 coluna BIGINT e 5 colunas INT.



O desempenho de uma consulta nesta tabela para procurar um registro indexado e executar o DML para manipular um registro (usando apenas 1 processador):



Aqui vemos que o desempenho de cada operação aumentou significativamente após a PG 9.6. SELECT consultas SELECT parecem muito melhores, especialmente aquelas que podem excluir várias seções durante o agendamento de consultas. Isso significa que o planejador pode pular a maior parte do trabalho que deveria ter feito antes. Por exemplo, caminhos para seções desnecessárias não são mais construídos.

Conclusão

O particionamento de tabelas está começando a se tornar um recurso muito poderoso no PostgreSQL. Ele permite que você produza dados rapidamente on-line e traduza-os off-line, sem esperar pela conclusão de operações DML massivas e lentas . Isso também significa que os dados relacionados podem ser armazenados juntos, o que significa que os dados necessários podem ser acessados ​​com muito mais eficiência. As melhorias feitas nesta versão não seriam possíveis sem desenvolvedores, revisores e confirmadores que trabalharam incansavelmente em todos esses recursos.
Obrigado a todos! O PostgreSQL 11 parece fantástico!

Aqui está um artigo tão curto, mas bastante interessante. Compartilhe seus comentários e não se esqueça de se inscrever para um dia de casa aberta , na qual o programa do curso será descrito em detalhes.

Source: https://habr.com/ru/post/pt452280/


All Articles