, a última versão "a melhor base de dados relacional de código aberto do mundo" será lançada em algumas semanas (se tudo correr bem). Isso se alinha à programação usual — uma nova versão com uma infinidade de novos recursos é lançada uma vez por ano e, honestamente, isso é impressionante. Por isso, me tornei um membro ativo da comunidade PostgreSQL.
Na minha opinião, ao contrário de versões anteriores, o PostgreSQL 12 não possui uma ou duas funções revolucionárias (como, por exemplo, particionamento ou paralelismo de consultas). Brinquei que a principal novidade do PostgreSQL 12 é uma maior estabilidade. E não é isso que precisamos ao gerenciar dados críticos do seu negócio?
Mas o PostgreSQL 12 não se limita a isso: com novos recursos e aprimoramentos, os aplicativos funcionarão melhor, e tudo o que você precisa fazer é fazer o upgrade!
(Bem, talvez seja necessário reconstruir os índices, mas nesta versão isso não é tão assustador quanto estávamos acostumados.)
Vai ser ótimo fazer o upgrade do PostgreSQL e imediatamente desfrutar de melhorias significativas sem muito esforço. Alguns anos atrás, analisei a atualização do PostgreSQL 9.4 para o PostgreSQL 10 e vi como o aplicativo acelerou graças ao melhorado paralelismo de consultas no PostgreSQL 10. E, o mais importante, quase nada foi exigido de mim (apenas definir um parâmetro de configuração max_parallel_workers).
Concorda que é conveniente quando logo após o upgrade os aplicativos funcionam melhor? E nos esforçamos muito para agradar os usuários, pois a comunidade do PostgreSQL está crescendo.
E como um simples upgrade para o PostgreSQL 12 o deixará feliz? Agora eu explico.
Melhorias sérias na indexação
Sem indexação, o banco de dados não vai longe. Como mais encontrar informações rapidamente? O sistema de indexação fundamental do PostgreSQL é chamado de . Este tipo de índice é otimizado para sistemas de armazenamento.
Utilizamos simplesmente o comando CREATE INDEX ON some_table (some_column), e o PostgreSQL faz o trabalho pesado para manter o índice atualizado enquanto continuamos a inserir, atualizar e excluir valores. Tudo funciona por conta própria, como por encanto.
Mas os índices do PostgreSQL têm um problema — eles e ocupam espaço extra no disco, enquanto o desempenho da extração e atualização de dados diminui. Por "inchaço", entendo a manutenção ineficiente da estrutura do índice. Isso pode ou não estar relacionado a tuplas lixo que são removidas. (obrigado pela informação a Peter Geoghegan ()). O inchaço do índice é especialmente notável em cargas de trabalho onde o índice está mudando ativamente.
O PostgreSQL 12 melhora significativamente o funcionamento dos índices de árvore B, e experimentos com testes do tipo TPC-C mostraram que o espaço agora é utilizado, em média, 40% a menos. Agora gastamos menos tempo não apenas na manutenção dos índices de árvore B (ou seja, em operações de gravação), mas também na extração de dados, pois os índices se tornaram muito menores.
Aplicativos que atualizam suas tabelas ativamente — geralmente são aplicativos OLTP () — serão muito mais eficientes no uso do disco e no processamento de consultas. Quanto mais espaço houver no disco, mais espaço a base de dados tem para crescer sem atualização de infraestrutura.
Algumas estratégias de atualização exigem a reconstrução de índices de árvore B para aproveitar essas vantagens (por exemplo, não reconstruirá os índices automaticamente). Em versões anteriores do PostgreSQL, a reconstrução de grandes índices nas tabelas resultava em interrupções significativas, uma vez que, nesse momento, não podiam ser feitas alterações. Mas no PostgreSQL 12 há mais um recurso interessante: agora é possível reconstruir índices em paralelo com o comando , para evitar totalmente as interrupções.
No PostgreSQL 12, há outras melhorias na infraestrutura de indexação. Mais uma coisa, onde não faltou mágica, é , também conhecido como WAL (write-ahead log). O log de gravação antecipada registra cada transação no PostgreSQL para casos de falha e replicação. Os aplicativos o utilizam para arquivamento e . Claro, o log de gravação antecipada é gravado no disco, e isso pode afetar o desempenho.
No PostgreSQL 12, os custos de registros WAL, gerados por índices GiST, GIN e SP-GiST durante a construção do índice, foram reduzidos. Isso traz várias vantagens significativas: os registros WAL ocupam menos espaço em disco e os dados são mais rápidos de serem reproduzidos, por exemplo, durante a recuperação após uma falha ou a recuperação em um ponto no tempo. Se você utiliza esses índices em suas aplicações (por exemplo, aplicações geoespaciais que usam bastante o índice GiST no PostGIS), esta é mais uma funcionalidade que melhorará consideravelmente o desempenho sem nenhum esforço adicional da sua parte.
Particionamento — mais, melhor, mais rápido
No PostgreSQL 10, foi introduzido . No PostgreSQL 11, passou a ser muito mais fácil de usar. No PostgreSQL 12, o tamanho das seções pode ser alterado.
No PostgreSQL 12, o desempenho do sistema de particionamento melhorou significativamente, especialmente se a tabela contém milhares de seções. Por exemplo, se uma consulta afeta apenas algumas seções em uma tabela com milhares, ela será executada muito mais rapidamente. O desempenho melhorou não apenas para esse tipo de consulta. Você também perceberá como as operações de INSERT em tabelas com muitas seções ficaram mais rápidas.
A gravação de dados usando — aliás, é uma excelente maneira e aqui está um exemplo — em tabelas particionadas, no PostgreSQL 12, também ficou mais eficiente. Com o COPY já era rápido, e agora no PostgreSQL 12 está voando.
Graças a essas vantagens, no PostgreSQL é possível armazenar conjuntos de dados ainda maiores, e a extração deles se tornou mais fácil. E sem nenhum esforço da sua parte. Se sua aplicação possui muitas seções, por exemplo, se grava dados de séries temporais, uma simples atualização melhorará consideravelmente o desempenho.
E embora essa melhoria não seja exatamente da categoria "atualizamos e ficamos felizes", no PostgreSQL 12 é possível criar chaves estrangeiras que referenciam tabelas particionadas, tornando o trabalho com particionamento um verdadeiro prazer.
As consultas WITH melhoraram significativamente
Quando (também conhecidas como CTE, que são consultas WITH), eu estava ansioso para escrever um artigo sobre como os desenvolvedores de aplicações se alegraram com o PostgreSQL . Esta é uma daquelas funcionalidades que aceleram o aplicativo. Se, claro, você estiver usando CTE.
Eu frequentemente noto que iniciantes em SQL gostam de usar CTE: se você os escrever de uma certa maneira, sente como se estivesse escrevendo um programa imperativo. Pessoalmente, eu gostava de reescrever essas consultas para evitá-las sem CTE e aumentar o desempenho. Agora é tudo diferente.
O PostgreSQL 12 permite incorporar um tipo específico de CTE sem efeitos colaterais (SELECT), que é usado apenas uma vez, mais para o final da consulta. Se eu mantivesse estatísticas sobre as consultas com CTE que reescrevi, a maioria delas se encaixaria nessa categoria. Isso ajuda os desenvolvedores a escrever código claro que agora também funciona de forma rápida.
Além disso, o PostgreSQL 12 otimiza a execução do SQL automaticamente, você não precisa fazer nada. E embora agora, provavelmente, eu não precise otimizar essas consultas, é ótimo que o PostgreSQL continue a trabalhar na otimização das consultas.
Just-in-Time (JIT) — agora por padrão
Em sistemas PostgreSQL 12 com suporte a A compilação JIT está habilitada por padrão. Primeiro, você obtém suporte à para algumas operações internas, e em segundo lugar, consultas com expressões (o exemplo mais simples é x + y) em listas de seleções (que estão após o SELECT), agregações, expressões nas cláusulas WHERE e outras podem usar JIT para aumentar o desempenho.
Uma vez que o JIT está habilitado no PostgreSQL 12 por padrão, o desempenho melhorará por conta própria, mas eu recomendo testar o aplicativo no PostgreSQL 11, onde o JIT apenas surgiu, para medir o desempenho das consultas e ver se há algo a ser ajustado.
E quanto às outras novas funcionalidades do PostgreSQL 12?
O PostgreSQL 12 traz uma série de novas funcionalidades incríveis — desde a capacidade de explorar dados JSON usando expressões padrão SQL/JSON até autenticação multifator com a opção clientcert=verify-full, colunas geradas e muito mais. Isso merece um post separado.
Assim como o PostgreSQL 10, o PostgreSQL 12 melhorará o desempenho geral logo após a atualização. É claro que você pode ter seu próprio caminho — teste o aplicativo em condições similares em um sistema de produção antes de ativar as melhorias, como eu fiz com o PostgreSQL 10. Mesmo que o PostgreSQL 12 já esteja mais estável do que eu esperava, não se esqueça de testar bem os aplicativos antes de lançá-los em produção.
Fonte: habr.com
