, a versão mais recente do “melhor banco de dados relacional de código aberto do mundo” será lançada em algumas semanas (se tudo correr conforme o planejado). Isso segue o cronograma usual de lançamento de uma nova versão com muitos novos recursos uma vez por ano e, francamente, isso é impressionante. É por isso que me tornei um membro ativo da comunidade PostgreSQL.
Na minha opinião, diferentemente das versões anteriores, o PostgreSQL 12 não contém um ou dois recursos revolucionários (como particionamento ou paralelismo de consulta). Certa vez brinquei que a principal característica do PostgreSQL 12 é maior estabilidade. Não é disso que você precisa ao gerenciar os dados críticos do seu negócio?
Mas o PostgreSQL 12 não para por aí: com novos recursos e melhorias, os aplicativos terão melhor desempenho, e tudo que você precisa fazer é atualizar!
(Bem, talvez reconstrua os índices, mas nesta versão não é tão assustador como estamos acostumados.)
Será ótimo atualizar o PostgreSQL e desfrutar imediatamente de melhorias significativas sem complicações desnecessárias. Há alguns anos, revisei uma atualização do PostgreSQL 9.4 para o PostgreSQL 10 e vi como o aplicativo acelerou graças ao paralelismo de consulta aprimorado no PostgreSQL 10. E, o mais importante, quase nada foi exigido de mim (basta definir um parâmetro de configuração max_parallel_workers).
Concordo, é conveniente quando os aplicativos funcionam melhor imediatamente após uma atualização. E nos esforçamos muito para agradar os usuários, porque o PostgreSQL tem cada vez mais deles.
Então, como uma simples atualização para o PostgreSQL 12 pode deixar você feliz? Eu vou te contar agora.
Principais melhorias de indexação
Sem indexação, um banco de dados não irá longe. De que outra forma você pode encontrar informações rapidamente? O sistema de indexação fundamental do PostgreSQL é chamado . Este tipo de índice é otimizado para sistemas de armazenamento.
Simplesmente usamos o operador CREATE INDEX ON some_table (some_column), e o PostgreSQL trabalha muito para manter o índice atualizado enquanto inserimos, atualizamos e excluímos valores constantemente. Tudo funciona sozinho, como num passe de mágica.
Mas os índices do PostgreSQL têm um problema - eles e ocupar espaço extra em disco e reduzir o desempenho de recuperação e atualização de dados. Por "inchaço", quero dizer manter a estrutura do índice de forma ineficaz. Isso pode - ou não - estar relacionado às tuplas de lixo que ele remove (obrigado a Peter Gaghan pela informação))). O inchaço do índice é especialmente perceptível em cargas de trabalho em que o índice está mudando ativamente.
O PostgreSQL 12 melhora muito o desempenho dos índices de árvore B, e experimentos com benchmarks como TPC-C mostraram que, em média, 40% menos espaço é usado agora. Agora gastamos menos tempo não apenas na manutenção dos índices da árvore B (ou seja, nas operações de gravação), mas também na recuperação de dados, porque os índices são muito menores.
Aplicativos que atualizam ativamente suas tabelas - normalmente aplicativos OLTP () - usará o disco e processará solicitações com muito mais eficiência. Quanto mais espaço em disco, mais espaço o banco de dados terá para crescer sem atualizar a infraestrutura.
Algumas estratégias de atualização exigem a reconstrução de índices de árvore B para aproveitar esses benefícios (por exemplo, não reconstruirá os índices automaticamente). Nas versões anteriores do PostgreSQL, a reconstrução de grandes índices em tabelas resultava em um tempo de inatividade significativo porque não era possível fazer alterações nesse meio tempo. Mas o PostgreSQL 12 tem outro recurso interessante: agora você pode reconstruir índices em paralelo com o comando para evitar completamente o tempo de inatividade.
Existem outras melhorias na infraestrutura de indexação no PostgreSQL 12. Outra coisa onde havia alguma magia - , também conhecido como WAL (registro de gravação antecipada). Um log write-ahead registra todas as transações no PostgreSQL em caso de falha e replicação. Os aplicativos o utilizam para arquivamento e . Obviamente, o log write-ahead é gravado no disco, o que pode afetar o desempenho.
O PostgreSQL 12 reduziu a sobrecarga dos registros WAL criados pelos índices GiST, GIN e SP-GiST durante a construção do índice. Isso oferece vários benefícios tangíveis: os registros WAL ocupam menos espaço em disco e os dados são reproduzidos mais rapidamente, como durante a recuperação de desastres ou recuperação pontual. Se você usar esses índices em seus aplicativos (por exemplo, aplicativos geoespaciais baseados em PostGIS usam muito o índice GiST), esse é outro recurso que melhorará significativamente a experiência sem nenhum esforço de sua parte.
Particionamento – maior, melhor, mais rápido
PostgreSQL 10 introduzido . No PostgreSQL 11 ficou muito mais fácil de usar. No PostgreSQL 12 você pode alterar a escala das seções.
No PostgreSQL 12, o desempenho do sistema de particionamento tornou-se significativamente melhor, especialmente se houver milhares de partições na tabela. Por exemplo, se uma consulta afetar apenas algumas partições em uma tabela com milhares delas, ela será executada muito mais rapidamente. O desempenho não é melhorado apenas para esses tipos de consultas. Você também notará como as operações INSERT são mais rápidas em tabelas com múltiplas partições.
Gravando dados usando - a propósito, esta é uma ótima maneira e aqui está um exemplo — as tabelas particionadas no PostgreSQL 12 também se tornaram mais eficientes. Com COPY tudo já era rápido, mas no PostgreSQL 12 voa absolutamente.
Graças a essas vantagens, o PostgreSQL permite armazenar conjuntos de dados ainda maiores e torná-los mais fáceis de recuperar. E nenhum esforço de sua parte. Se o aplicativo tiver muitas partições, como gravação de dados de série temporal, uma simples atualização melhorará significativamente seu desempenho.
Embora isso não seja exatamente uma melhoria do tipo “atualizar e aproveitar”, o PostgreSQL 12 permite que você crie chaves estrangeiras que fazem referência a tabelas particionadas, tornando o trabalho com particionamento um prazer.
As consultas COM ficaram muito melhores
Quando (também conhecido como CTE, também conhecido como consultas COM), mal podia esperar para escrever um artigo sobre . Esse é um daqueles recursos que vão agilizar a aplicação. A menos, é claro, que você use CTE.
Muitas vezes descubro que os novatos em SQL adoram usar CTEs; se você os escrever de uma determinada maneira, realmente parece que você está escrevendo um programa imperativo. Pessoalmente, gostei de reescrever essas consultas para contornar sem CTE e aumentar a produtividade. Agora tudo é diferente.
O PostgreSQL 12 permite incorporar um tipo específico de CTE sem efeitos colaterais (SELECT), que é usado apenas uma vez próximo ao final da solicitação. Se eu acompanhasse as consultas CTE que reescrevi, a maioria delas se enquadraria nesta categoria. Isso ajuda os desenvolvedores a escrever um código claro que agora também é executado rapidamente.
Além disso, o PostgreSQL 12 otimiza a própria execução do SQL, sem que você precise fazer nada. E embora provavelmente não precise otimizar essas consultas agora, é ótimo que o PostgreSQL continue trabalhando na otimização de consultas.
Just-in-Time (JIT) – agora padrão
Em sistemas PostgreSQL 12 com suporte A compilação JIT está habilitada por padrão. Primeiro de tudo, você recebe suporte para algumas operações internas e, em segundo lugar, consultas com expressões (o exemplo mais simples é x + y) em listas de seleção (que você tem após SELECT), agregações, expressões com cláusulas WHERE e outras podem usar JIT para melhorar o desempenho.
Como o JIT está habilitado por padrão no PostgreSQL 12, o desempenho melhorará por si só, mas recomendo testar o aplicativo no PostgreSQL 11, que introduziu o JIT, para medir o desempenho da consulta e ver se você precisa ajustar alguma coisa.
E quanto ao restante dos novos recursos do PostgreSQL 12?
O PostgreSQL 12 tem vários novos recursos interessantes, desde a capacidade de examinar dados JSON usando expressões de rota SQL/JSON padrão até autenticação multifator com um parâmetro clientcert=verify-full, colunas criadas e muito mais. O suficiente para uma postagem separada.
Assim como o PostgreSQL 10, o PostgreSQL 12 melhorará o desempenho geral imediatamente após a atualização. Você, é claro, pode ter seu próprio caminho - testar o aplicativo em condições semelhantes no sistema de produção antes de habilitar melhorias, como fiz com o PostgreSQL 10. Mesmo que o PostgreSQL 12 já seja mais estável do que eu esperava, não seja preguiçoso nos testes aplicativos completamente, antes de liberá-los para produção.
Fonte: habr.com