Novidades do PostgreSQL 9.2

Estamos muitos próximos do lançamento da nova versão do PostgreSQL, a versão 9.2. Já no segundo beta da versão,...

Dextra

View posts by Dextra
Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes. A Dextra faz parte da Mutant, empresa B2B líder no mercado brasileiro e especialista em Customer Experience para plataformas digitais.
Data de publicação: 26/06/2012


Estamos muitos próximos do lançamento da nova versão do PostgreSQL, a versão 9.2. Já no segundo beta da versão, esperamos que a versão oficial seja lançada até o final de Setembro de 2012. Várias novidades estarão presentes nesta versão, como a tão esperada replicação em cascata, novos tipos de dados, index-only scans, o novo processo “background checkpointer”, entre muitas outras. Neste artigo vamos dar uma olhada nas principais novidades do PostgreSQL 9.2.

Replicação em cascata

Talvez essa seja a funcionalidade mais esperada do PostgreSQL 9.2: a possibilidade de realizar replicação em cascata.
As melhorias no gerenciamento de log de transações para servidores slaves de uma replicação, torna possível a execução de processos “wal sender” nestes servidores, permitindo que um servidor slave se conecte à outro servidor slave para realizar a replicação em cascata.
A replicação em cascata é especialmente útil para sistemas distribuídos, conseguindo fazer com que cada servidor slave seja sincronizado a partir de outro servidor mais próximo, seja este um slave ou master. Além disso, a distribuição da replicação faz com que o uso de recursos seja reduzido no servidor master.
Além da replicação em cascata, a nova versão traz a possibilidade de realização de backup incremental a partir de um servidor slave. Com isso, ganha-se tanto em distribuição de tarefas quanto em segurança, podendo realizar o mesmo backup em vários pontos distintos.

Novos tipos de dados

Três novos tipos de dados nativos foram incluídos na nova versão do PostgreSQL.
Depois do sucesso da inclusão do tipo de dados XML na versão 8.3 do PostgreSQL, agora é possível armazenar tipo de dados JSON. É claro que o conteúdo do JSON já podia ser armazenado num campo tipo text, entretanto o tipo de dados específico para JSON é capaz de validar e auxiliar no processamento desse tipo de informação.
Vários tipos de dados para representação de intervalos foram adicionados. Estes tipos de dados são capazes de adicionar valor inicial e final de um intervalo, podendo este intervalo ser: inteiro, decimal, data/hora ou data. Além disso, novos tipos de dados de intervalo podem ser criados com o comando CREATE TYPE.
Além da representação, vários operadores e funções foram definidos para realizar o processamento desses tipos de dados de forma mais ágil. Outro ponto importante é a possibilidade de indexação desses dados com índices GiST e a criação de restrições (“constraints”) para estes (por exemplo, para garantir que não há interseções entre intervalos).

Index-only scans

Nas versões anteriores do PostgreSQL, os índices eram usados apenas como referência para a tabela, ou seja, para recuperar o valor buscado, sempre era necessária a busca do registro na tabela após a varredura do índice.
Com a funcionalidade de “index-only scans” ou “varreduras apenas em índice”, o PostgreSQL não precisa mais buscar o valor de um campo na tabela, agora ele é capaz de buscar esse valor diretamente no índice. No caso de um SELECT executado numa tabela que contém um índice com todos os campos que serão retornados (em qualquer parte da cláusula), o PostgreSQL não precisará mais buscar na tabela para devolver o resultado, este será capaz de retornar o resultado com o valor presente no índice.
Exemplo:
Criação de uma tabela para teste:

postgres=# CREATE TABLE teste AS
SELECT id, md5(random()::text) AS valor1, md5(random()::text) AS valor2
FROM generate_series(1, 100000) AS id;
SELECT 100000
Time: 2639.959 ms

Criação de um índice com o campo id e valor1:

postgres=# CREATE INDEX idx_teste ON teste (id, valor1);
CREATE INDEX
Time: 1336.790 ms

Busca pelo id = 90000 e retornando todos os campos:

postgres=# EXPLAIN ANALYZE SELECT id,
valor1, valor2 FROM teste WHERE id = 90000;
               QUERY PLAN
-----------------------------------------------------------------------
 Index Scan using idx_teste on teste  (cost=0.00..8.56 rows=1 width=70)
(actual time=29.077..29.081 rows=1 loops=1)
   Index Cond: (id = 90000)
 Total runtime: 29.165 ms
(3 rows)
Time: 239.084 ms

O “Index Scan”, usado acima pelo PostgreSQL, é capaz de filtrar os registros pelo índice, mas deve buscar o valor na tabela.
Agora, buscando também pelo id = 90000, mas sem retornar o campo valor2 (que não está indexado):

postgres=# EXPLAIN ANALYZE SELECT id, valor1 FROM teste WHERE id = 90000;
                                                      QUERY PLAN
----------------------------------------------------------------------------
 Index Only Scan using idx_teste on teste  (cost=0.00..8.56 rows=1 width=37)
(actual time=8.331..8.335 rows=1 loops=1)
   Index Cond: (id = 90000)
   Heap Fetches: 1
 Total runtime: 8.419 ms
(4 rows)
Time: 68.973 ms

Nesta consulta o otimizador do PostgreSQL decidiu usar a nova funcionalidade, o “Index Only Scan”, para evitar a busca dos dados na tabela.

Novo utilitário: “pg_receivexlog”

O backup incremental é uma funcionalidade presente no PostgreSQL desde a versão 8.0. Esta forma de backup permite o arquivamento de logs de transação logo após um processo de CHECKPOINT. A grande vantagem dessa funcionalidade é que a mesma permite o uso da técnica de PITR (Point-In-Time Recovery), que torna possível restaurar o estado exato do servidor PostgreSQL em qualquer ponto no tempo. Para que isso aconteça, um backup base (backup dos arquivos físicos) é necessário, e o arquivamento dos logs de transação (Write-ahead-logs) a partir deste backup base.
O backup incremental acontece após o CHECKPOINT, que por sua vez aguarda o preenchimento dos arquivos de log de transação (checkpoint_segments) ou um timeout (checkpoint_timeout). Dessa forma, o backup permanece em atraso equivalente a algumas transações.
Com a versão 9.0 do PostgreSQL surgiu o conceito de replicação por fluxo de dados (streaming replication). Na 9.2, essa técnica pode ser utilizada não somente para replicação, mas também para execução do backup incremental. A ferramenta pg_receivexlog passa a fazer parte do conjunto de ferramentas administrativas do PostgreSQL, para permitir o uso do protocolo de replicação por fluxo de dados na estratégia de backup, garantindo um backup fiel ao ambiente de produção.

Melhorias na contrib “pg_stat_statements”

A extensão “pg_stat_statements”, presente desde a versão 8.4 do PostgreSQL, possui uma funcionalidade de grande utilidade. Esta extensão é capaz de capturar os comandos mais lentos e mais executados no banco de dados. A grande vantagem desta extensão, se comparada à interpretadores de log de atividades, como o pgFouine, é o fato da mesma conseguir os resultados sempre em tempo real, por ser uma biblioteca carregada pelo servidor do PostgreSQL e apresentar os resultados na view pg_stat_statements.
Entretanto, esta não era uma extensão muito adotada, pelo fato de considerar os comandos SQL com as constantes, não agregando comandos semelhantes. Ou seja, as consultas abaixo eram consideradas diferentes para a pg_stat_statements:

SELECT * FROM teste WHERE valor2 LIKE 'a%';
SELECT * FROM teste WHERE valor2 LIKE 'b%';

A versão dessa extensão para o PostgreSQL 9.2, passa a ignorar as constantes, tratando as consultas acimas como equivalentes por considerar apenas a estrutura do comando. O valor apresentado na view pg_stat_statements para a consulta acima é o seguinte:

SELECT * FROM teste WHERE valor2 LIKE ?;

Background Checkpointer

O PostgreSQL é um sistema multi-processo, o que significa que vários processos são usados para o gerenciamento do banco de dados e conexões. Para cada conexão de usuário um processo filho é criado para gerenciar a mesma, e além disso, também são criados processos filhos para a execução de tarefas administrativas, como o “autovacuum launcher”, responsável por iniciar processos (novos filhos) automáticos de VACUUM.
No Linux, uma forma simples de encontrar todos os processos do PostgreSQL sendo executados é com o utilitário “ps”, filtrando pelos processos que são executados pelo usuário “postgres” (no caso de uma instalação padrão do PostgreSQL):

$ ps f -u postgres
  PID TTY    STAT    TIME COMMAND
 2878 ?      S      53:51 /usr/local/pgsql9.2/bin/postgres -D /usr/local/pgsql9.2/data/
 3079 ?      Ss      9:10  _ postgres: logger process
 3174 ?      Ss     37:28  _ postgres: writer process
 3175 ?      Ss     27:13  _ postgres: checkpointer process
 3176 ?      Ss     27:13  _ postgres: wal writer process
 3177 ?      Ss    573:38  _ postgres: autovacuum launcher process
 3178 ?      Ss      5:50  _ postgres: archiver process   last was 000000010000000100000073
 3179 ?      Ss   1578:05  _ postgres: stats collector process
14359 ?      Ss      0:00  _ postgres: postgres postgres 172.16.129.122(34176) idle
14387 ?      Ss      0:00  _ postgres: postgres postgres 172.16.129.122(34184) idle
14395 ?      Ss      0:00  _ postgres: postgres postgres 172.16.129.122(34190) idle

Um outro processo administrativo, presente desde a versão 8.0, é o “writer” ou também conhecido como “background writer”. Este é um processo essencial para o PostgreSQL, e, até a versão 9.1 era responsável pela realização de duas tarefas:

  • Escrita de páginas sujas no buffer de memória para o disco;
  • Execução do processo de CHECKPOINT.

A partir da versão 9.2 do PostgreSQL, o “background writer” foi divido em dois processos, passando agora a ser responsável apenas pela escrita de páginas sujas em disco. Essa divisão criou um novo processo filho, o “background checkpointer”, agora responsável pela execução do CHECKPOINT.
Com essa divisão, espera-se melhorar a distribuição nas operações de escrita. Com isso, pode-se esperar também um ganho em desempenho, principalmente em sistemas com uso intensivo de entrada/saída (I/O bound).

Melhor escalabilidade vertical

Na versão 9.2 algumas mudanças no código-fonte do PostgreSQL trouxeram grandes melhorias de desempenho, aprimorando ainda mais a escalabilidade vertical. Esta melhoria no PostgreSQL aliado à algumas atualizações no kernel 3.2 do Linux tornou esse ganho muito expressivo nessa versão. Testes comparando a escalabilidade do PostgreSQL 9.1 e 9.2 comprovaram que um grande ganho em servidores com processadores multi-núcleos de 32 e 64 núcleos.
 

Dextra

View posts by Dextra
Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes. A Dextra faz parte da Mutant, empresa B2B líder no mercado brasileiro e especialista em Customer Experience para plataformas digitais.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

vinte − dez =

Posts relacionados

  1. Sobre a Dextra

    Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes.

  2. Categorias

Scroll to top