O PostgreSQL 12 , a versão mais recente do "melhor banco de dados relacional de código aberto do mundo", sai em algumas semanas (se tudo correr conforme o planejado). Isso corresponde à programação usual - uma nova versão com muitos recursos novos é lançada uma vez por ano e, francamente, é impressionante. Portanto, eu me tornei um membro ativo da comunidade PostgreSQL.
Na minha opinião, diferentemente das versões anteriores, o PostgreSQL 12 não contém uma ou duas funções revolucionárias (como particionamento ou simultaneidade de consultas). Uma vez, brinquei que a principal característica do PostgreSQL 12 é mais estabilidade. Não é isso que você precisa ao gerenciar dados corporativos críticos?
Mas o PostgreSQL 12 não se limita a isso: com novos recursos e aprimoramentos, os aplicativos funcionam melhor e você só precisa atualizar!
(Bem, talvez até reconstrua os índices, mas nesta versão não é tão assustador quanto costumávamos.)
Será ótimo atualizar o PostgreSQL e desfrutar imediatamente de melhorias significativas sem gestos desnecessários. Alguns anos atrás, analisei a atualização do PostgreSQL 9.4 para o PostgreSQL 10 e vi como o aplicativo acelerava devido ao aprimoramento do paralelismo de consultas no PostgreSQL 10. E, o mais importante, quase nada era necessário para mim (basta definir o max_parallel_workers configuração max_parallel_workers ).
Concordo, é conveniente quando, logo após a atualização, os aplicativos funcionam melhor. E estamos tentando muito agradar os usuários, porque o PostgreSQL tem mais deles.
E como uma atualização simples para o PostgreSQL 12 o faz feliz? Eu vou te contar agora.
Principais melhorias na indexação
Sem indexação, o banco de dados não irá longe. E de que outra forma encontrar rapidamente informações? O sistema de indexação fundamental do PostgreSQL é chamado de árvore B. Esse tipo de índice é otimizado para sistemas de armazenamento.
Nós apenas usamos a CREATE INDEX ON some_table (some_column) e o PostgreSQL faz um ótimo trabalho em manter o índice atualizado enquanto constantemente inserimos, atualizamos e excluímos valores. Tudo funciona por si só, como se por mágica.
Porém, os índices do PostgreSQL têm um problema: eles incham e ocupam espaço em disco extra, e o desempenho da recuperação e atualização de dados é reduzido. Por "inchaço", quero dizer manter ineficazmente a estrutura do índice. Pode ou não ser devido a tuplas de lixo removidas pelo VACUUM (obrigado pela informação a Peter Geoghegan ). O inchaço do índice é particularmente visível nas cargas de trabalho em que o índice está mudando ativamente.
O PostgreSQL 12 melhora seriamente o desempenho dos índices da árvore B, e experimentos com testes como o TPC-C mostraram que o espaço agora é usado, em média, 40% menos. Agora, gastamos menos tempo não apenas na manutenção de índices da árvore B (isto é, nas operações de gravação), mas também na extração de dados, porque os índices se tornaram muito menores.
Os aplicativos que atualizam ativamente suas tabelas - normalmente aplicativos OLTP ( processamento de transações em tempo real ) - são muito mais eficientes no uso do disco e nas solicitações de processamento. Quanto mais espaço em disco, mais espaço o banco de dados possui para crescer sem atualizar a infraestrutura.
Algumas estratégias de atualização exigem a reconstrução de índices da árvore B para tirar proveito deles (por exemplo, pg_upgrade não reconstruirá os índices automaticamente). Nas versões anteriores do PostgreSQL, a reconstrução de grandes índices em tabelas levava a um tempo de inatividade significativo, porque naquele momento era impossível fazer alterações. Mas o PostgreSQL 12 tem outro truque interessante: agora você pode reconstruir índices em paralelo com o comando REINDEX CONCURRENTLY para evitar completamente o tempo de inatividade.
O PostgreSQL 12 possui outras melhorias na infraestrutura de indexação. Outra coisa que não poderia ser feita sem mágica é o log de gravação antecipada, que também é o WAL (log de gravação antecipada). Um log de gravação antecipada registra todas as transações no PostgreSQL em caso de falha e replicação. Os aplicativos o utilizam para backup e restauração em um determinado momento . Obviamente, o log write-ahead é gravado no disco, e isso pode afetar o desempenho.
O PostgreSQL 12 reduziu a sobrecarga dos WALs criados pelos índices GiST, GIN e SP-GiST ao criar o índice. Isso oferece várias vantagens tangíveis: os registros WAL ocupam menos espaço em disco e os dados são reproduzidos mais rapidamente, por exemplo, durante a recuperação de uma falha ou recuperação em um determinado momento. 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 o desempenho sem nenhum esforço de sua parte.
Particionamento - maior, melhor e mais rápido
O PostgreSQL 10 introduziu o particionamento declarativo . O PostgreSQL 11 tornou muito mais fácil o uso. No PostgreSQL 12, você pode alterar a escala das seções.
No PostgreSQL 12, o desempenho do sistema de particionamento é muito melhor, especialmente se houver milhares de seções na tabela. Por exemplo, se uma consulta afeta apenas algumas seções da tabela, onde existem milhares delas, ela será executada muito mais rapidamente. O desempenho foi aprimorado não apenas para esses tipos de consultas. Você também observará como as operações INSERT foram aceleradas em tabelas com muitas partições.
Escrever dados usando COPY - a propósito, esta é uma ótima maneira de carregar dados em massa e aqui está um exemplo de recebimento de JSON - em tabelas particionadas no PostgreSQL 12 também se tornou mais eficiente. Com o COPY, tudo foi muito rápido, mas no PostgreSQL 12 ele voa.
Graças a esses benefícios, o PostgreSQL pode armazenar conjuntos de dados ainda maiores e facilitar a recuperação. E nenhum esforço de sua parte. Se o aplicativo tiver muitas seções, por exemplo, ele registra dados de séries temporais, uma atualização simples melhorará significativamente seu desempenho.
Embora essa melhoria não seja inteiramente da categoria “atualizar e se alegrar”, no PostgreSQL 12, você pode criar chaves estrangeiras que fazem referência a tabelas particionadas, para que trabalhar com o particionamento seja um prazer.
Com consultas são muito melhores
Quando o patch foi aplicado às expressões de tabela generalizada incorporadas (elas são CTE e também com consultas), eu estava ansioso para escrever um artigo sobre como os desenvolvedores de aplicativos com o PostgreSQL estavam satisfeitos . Esse é um desses recursos que acelera o aplicativo. A menos, é claro, que você esteja usando o CTE.
Costumo notar que os recém-chegados ao SQL gostam de usar o CTE: se você os escreve de uma certa maneira, sente diretamente que está escrevendo um programa imperativo. Pessoalmente, adorei reescrever essas consultas para dispensar o CTE e aumentar o desempenho. Agora tudo está diferente.
O PostgreSQL 12 permite incorporar um tipo específico de CTE sem efeitos colaterais ( SELECT ), que é usado apenas uma vez perto do final da consulta. Se eu mantivesse estatísticas de solicitações com CTEs que eu reescrevesse, a maioria delas entraria nessa categoria. Isso ajuda os desenvolvedores a escrever código compreensível que agora também funciona rapidamente.
Além disso, o PostgreSQL 12 otimiza a execução do próprio SQL, você não precisa fazer nada. E embora agora, provavelmente, não precise otimizar essas consultas, é ótimo que o PostgreSQL continue trabalhando na otimização de consultas.
Just-in-Time (JIT) - agora padrão
Nos sistemas PostgreSQL 12 com suporte a LLVM , a compilação JIT é ativada por padrão. Primeiramente, você obtém suporte JIT para algumas operações internas e, em segundo lugar, consultas com expressões (o exemplo mais simples é x + y) nas listas de seleção (que você possui após SELECT), agregados, expressões com cláusulas WHERE e outras pode usar o JIT para melhorar o desempenho.
Como o JIT é incluído no PostgreSQL 12 por padrão, o desempenho melhora por conta própria, mas eu recomendo testar o aplicativo no PostgreSQL 11, onde o JIT apareceu para medir o desempenho da consulta e ver se você precisa ajustar alguma coisa.
Mas e os outros novos recursos do PostgreSQL 12?
O PostgreSQL possui 12 toneladas de recursos novos e interessantes - desde a capacidade de examinar dados JSON usando expressões de rota SQL / JSON padrão até a autenticação de vários fatores com o clientcert=verify-full , colunas criadas e muito mais. O suficiente para um post separado.
Como o PostgreSQL 10, o PostgreSQL 12 melhorará o desempenho geral logo após a atualização. Obviamente, você pode fazer o que quiser - teste o aplicativo em condições semelhantes no sistema de trabalho antes de ativar as melhorias, como fiz no PostgreSQL 10. Mesmo que o PostgreSQL 12 já seja mais estável do que eu esperava, não tenha preguiça de testar a qualidade dos aplicativos, antes de liberá-los na produção.