segunda-feira, 17 de outubro de 2011

201 Posts! Obrigado!

Em 2007 comecei a estudar mais sobre o Postgres, e criei este blog.

Estamos em 2011 e este é o post número 201.

Ainda há muito a estudar, muito mesmo!

Ainda há muito para postar, muitas ideias.

O tempo diminuiu. Bastante.

E nem ensino mais banco de dados.

Mas cada acesso, cada comentário feito, atestam que valeu a pena.

E continua valendo.

Agradeço a Deus!

Obrigado aos amigos da comunidade, muitos dos quais admiro sem conhecer pessoalmente.

Obrigado a quem acessa este site.

Obrigado aos brasileiros.

Obrigado aos paulistas, aos paranaenses e ao povo do Rio Grande do Sul pelos acessos! A todos os estados e ao meu Ceará!

E também aos americanos, portugueses e holandeses (!) que acessam.

E a todos os demais!

Obrigado por cada comentário, ainda que anônimo!

Este site é sobre uma ferramenta técnica.

Nunca vai chegar a um milhão de acessos.

Mas esse não era o objetivo.

Tampouco vender consultorias.


Espero ter tempo para continuar estudando e compartilhando!


Obrigado!

terça-feira, 11 de outubro de 2011

Unlogged Tables: Funcionalidade para Aumento de Desempenho!

Todos sempre buscamos melhorar o desempenho das operações de banco de dados. E um dos recursos de performance ainda pouco utilizados da versão 9.1 do postgres são as chamadas unlogged tables.

O que são Unlogged Tables?

Unlogged Tables são tabelas que não apresentam suporte a recuperação pós-falha. Não apresentam portanto log de transações (write-ahead-log - WAL). Essa característica possibilita um grande ganho de desempenho em todas as operações realizadas. O ganho de desempenho obtido se deve ao sacrifício da possibilidade de recuperar os dados em caso de falha de sistema.

Uma unlogged table tem seus dados automaticamente perdidos em caso de falha, pois é truncada automaticamente, o que gera um ganho no tempo de recuperação do banco de dados.

Os dados de uma unlogged table não sofrem replicação dentro do postgresql.

Em unlogged tables não há necessidade de se manter o log e sincronizá-lo com o banco de dados, fator importante para o de ganho de desempenho.

Em que situações é recomendado utilizar este tipo de tabela?

Em situações em que a durabilidade dos dados não seja realmente importante:
- Para parâmetros de aplicações web;
- Cache de dados em geral;
- Tabelas de status de aplicações, entre outras possibilidades.


Acredito que apenas uma pequena parte de sistemas de bancos de dados possa ser armazenada em tabelas unlogged.

As operações de inserção, alteração, alteração e consulta a dados de uma "tabela sem log" são diferentes de uma tabela "normal"?
A forma de fazer e os comandos utilizados permanecem os mesmos. No entanto, internamente, não há write-ahead-log (WAL), o que faz com que os dados da tabela seja perdidos em caso de quedas de sistema. A velocidade das operações tende a ser bem maior.

Como criar Unlogged Tables?

A criação de tabelas sem log é bastante simples. Basta colocar a cláusula "UNLOGGED" no comando de criação da tabela.

teste=> CREATE TABLE LOGADA (cod integer, descricao varchar(50));
CREATE TABLE
teste=> CREATE UNLOGGED TABLE NAO_LOGADA (cod integer, descricao varchar(50));
CREATE TABLE
teste=>

É permitido indexar este tipo de tabela?

Não existem restrições à indexação, exceto para índices GIST em que este recurso não está implementado. É possível inclusive reindexar, se for o caso! Os índices de uma unlogged table também são "unlogged", isto é, são truncados em caso de falha do sistema.

teste=> CREATE INDEX UNLOGT ON NAO_LOGADA(cod);
CREATE INDEX
teste=>
teste=> insert into NAO_LOGADA values (1, 'Teste 1');
INSERT 0 1
teste=> insert into NAO_LOGADA values (2, 'Teste 2');
INSERT 0 1
teste=> insert into NAO_LOGADA values (3, 'Teste 3');
INSERT 0 1
teste=> REINDEX TABLE NAO_LOGADA;
REINDEX

De quanto é o ganho esperado em desempenho?

DEPENDE da operações realizada. Veja o link abaixo e depois faça seus próprios testes:
http://pgsnaga.blogspot.com/2011/10/pgbench-on-unlogged-tables.html

Considerações Finais

Unlogged Tables são um recurso válido para ganho de performance em certos casos específicos. No entanto, a definição de que tabelas devem ser unlogged pode gerar erros graves e impossibilitar a recuperação de dados relevantes. Esta decisão deve ser sempre bastante embasada e levar em conta as necessidades de todos os usuários do banco.