Ajustes de performance são uma parte importante do trabalho dos DBAs. Este trabalho de conclusão de curso de Qiang Wang mostra diversas opções que podem ser empregadas para melhorar o desempenho do Postgresql.
O texto está em um inglês de fácil compreensão e as soluções sugeridas são bastante simples, o que torna o material bastante prático.
quinta-feira, 28 de junho de 2012
quarta-feira, 27 de junho de 2012
Pesquisas sobre PostgreSQL: Ambientes Escaláveis para SGBD em Software Livre
O Serpro está investindo em convênios para pesquisas sobre ambientes escaláveis implementados com o Postgresql.
O artigo de Flávio Gomes Lisboa, publicado na edição de maio de 2012 da revista Tema (p. 12 e 13), é uma boa referência de como o Governo e Universidades podem estabelecer parcerias para pesquisas avançadas envolvendo teoria, prática e tecnologias livres.
O artigo de Flávio Gomes Lisboa, publicado na edição de maio de 2012 da revista Tema (p. 12 e 13), é uma boa referência de como o Governo e Universidades podem estabelecer parcerias para pesquisas avançadas envolvendo teoria, prática e tecnologias livres.
terça-feira, 26 de junho de 2012
Desenvolva suas Aplicações de Bancos Postgres com Wavemaker
Tela 1: Servidor do Wavemaker Online
É uma ferramenta livre com código aberto através de licença Apache. Neste post a preocupação não é mostrar em profundidade os recursos da ferramenta, nem criar um tutorial, mas sim apresentar as funcionalidades básicas.
Tela 2: Interface do Wavemaker
A instalação é relativamente simples, e o programa pode ser baixado em http://www.wavemaker.com. O wavemaker é compatível com windows, linux e macintosh.
Tela 3: Criação de Projeto no Wavemaker
O Wavemaker apresenta uma interface bastante simplificada e ao mesmo tempo prática, e as operações são todas feitas dentro do navegador web. Basta se selecionar um objeto para suas propriedades estarem disponibilizadas para edição à direita da tela. A interface de programação é WYSIWYG. É uma ferramenta cliente-servidor, o que exige os devidos cuidados com a segurança em rede.
Abaixo, alguns recursos associados ao PostgreSQL:
* Importar Database
Por meio do menu "Services/ Import database" é possível recuperar todas as informações em um banco já existente. A interface é intuitiva para quem tem alguma experiência de desenvolvimento.
Tela 4: Importar Database
Entre com os dados do banco de dados, teste a conexão utilizando a opção "Test connection" e acione a importação do banco de dados com o botão "Import".
As tabelas importadas aparecem à esquerda da tela, na pasta "Database Widgets". É possível utilizar estas tabelas para criar formulários CRUD, consultas e relatórios, entre outras possibilidades.
* Projetar Database
Acione a opção "Services/ Design Database" para criar suas bases de dados, tabelas e para estabelecer os relacionamentos entre as mesmas.
Tela 5: Projetar Database
Ao disparar esta opção, você define o nome do banco a ser criado e confirma. O banco aparecerá no menu à esquerda da tela.
Selecione o banco e na parte central da tela aparecerão as opções de criação das tabelas do seu banco. A interface realmente é bem agradável. Clique no ícone do disquete para salvar as tabelas que for desenvolvendo.
Tela 6: Criação de Tabela
* Consultar
O menu "Services/ Query" permite que se realize e salve consultas às tabelas.
Tela 7: Construção de Consultas
A ferramenta apresenta ainda grids, treeviews, charts para apreentação dos dados, entre outras funcionalidades. É possível definir o dataset de uma grid e indicar as colunas a serem mostradas, o que facilita muito o desenvolvimento.
Tela 8: Dados de Uma Tabela
* Pontos fortes:
- Boa interface
- Visual WYSIWYG
- Facilidade de instalação (segui o tutorial e não houve qualquer incidente)
- Código aberto com licença Apache
- Tutoriais no sítio da ferramenta
- A desenvolvedora foi adquirida recentemente pela VMWare, o que pode garantir mais recursos para a evolução desta ferramenta
* Pontos fracos
- Compatibilidade boa com Postgresql, mas não excepcional. Recursos específicos como herança de tabelas e indexação avançada não são abordados na ferramenta e tem de ser codificados manualmente no banco.
- A desenvolvedora foi adquirida recentemente pela VMWare, e o impacto desta mudança no desenvolvimento da ferramenta não pode ser previsto de antemão
* Avaliação Pessoal
A primeira impressão que me causou foi bastante positiva, mas não recomendo a utilização em ambientes de produção sem vários testes com prototipação e simulações de carga.
quinta-feira, 3 de maio de 2012
Questões de concurso sobre o PostgreSQL!
Este link mostra um site com questões de vários concursos no Brasil sobre o postgres coletadas desde 2007.
É interessante ver que esta tecnologia já está sendo utilizada em diversos órgãos órgãos como MPU, MEC, TJ, INFRAERO, EMBASA, entre outros, a ponto de fazer parte dos processos seletivos.
É interessante ver que esta tecnologia já está sendo utilizada em diversos órgãos órgãos como MPU, MEC, TJ, INFRAERO, EMBASA, entre outros, a ponto de fazer parte dos processos seletivos.
terça-feira, 1 de maio de 2012
Acesse: Revista Internacional de PostgreSQL
A revista PostgreSQL Magazine tem sua primeira edição lançada. Minha primeira impressão foi bastante positiva!
Abaixo, uma visão geral dos conteúdos:
- PostgreSQL 9.1 : 10 incríveis novos recursos
- NoSQL : Implementação com Postgres
- Entrevista : Stefan Kaltenbrunner
- Opinião: Financiamento de Funcionalidades do PostgreSQL
- A espera pela versão 9.2 : Cascading Streaming Replication
- Dicas e Truques: PostgreSQL no Mac OS X Lion
O acesso está disponível em três formas:
* Leitura online gratuita: http://pgmag.org/01/read
* Pela aquisição da edição impressa: http://pgmag.org/01/buy
* Versão em PDF: http://pgmag.org/01/download
A revista apresenta abertura para escritores, tradutores e outros interessados.
Espero que haja fôlego para a produção de mais revistas com este nível. Confira!
Abaixo, uma visão geral dos conteúdos:
- PostgreSQL 9.1 : 10 incríveis novos recursos
- NoSQL : Implementação com Postgres
- Entrevista : Stefan Kaltenbrunner
- Opinião: Financiamento de Funcionalidades do PostgreSQL
- A espera pela versão 9.2 : Cascading Streaming Replication
- Dicas e Truques: PostgreSQL no Mac OS X Lion
O acesso está disponível em três formas:
* Leitura online gratuita: http://pgmag.org/01/read
* Pela aquisição da edição impressa: http://pgmag.org/01/buy
* Versão em PDF: http://pgmag.org/01/download
A revista apresenta abertura para escritores, tradutores e outros interessados.
Espero que haja fôlego para a produção de mais revistas com este nível. Confira!
quinta-feira, 26 de abril de 2012
Faça Você Mesmo: Mapas Mentais Gerados Via SQL!
A criação de diagramas é um processo que exige paciência e bastante tempo. No entanto, se estes diagramas são de natureza hierárquica, fica mais fácil se pensar em um certo grau de automatização. Mas o que isso tem a ver com o postgresql? Este post mostra a geração automatizada de um diagrama hierárquico estilo mind map, através de uma consulta ao postgres!
Basicamente, este post apresenta duas utilidades práticas:
- A criação de mapas mentais sobre o banco de dados, importante para DBAs e útil para o gerenciamento dos bancos de dados;
- A geração de mapas mentais baseados nas informações contidas nos bancos de dados, o que pode ser uma alternativa relevante aos tradicionais relatórios tabulares.
Mapas mentais são diagramas que mostram uma hierarquia de conceitos, ideias ou objetos quaisquer. O Freemind é uma das ferramentas livres mais conhecidas para a construção intuitiva de mapas mentais, e será utilizado neste texto. A ferramenta permite a exportação de mapas mentais para vários formatos, pesquisas e várias outras funcionalidades.
Baixe-a e instale a partir deste site.
O formato interno do freemind é uma linguagem de marcação similar ao HTML ou ao XML, então é razoavelmente fácil criar diagramas através de consultas sql.
Os passos são os seguintes:
- Criar uma consulta que retorne o valor no formato do Freemind;
- Salvar o resultado da consulta em um arquivo .mm (mm de Mind Map);
- Abrir o diagrama gerado no Freemind e fazer as eventuais customizações.
A consulta abaixo realiza uma consulta aos metadados do postgresql e apresenta o resultado ao usuário (tive de salvar como imagem por ter caracteres não aceitos pelo Blogger):
Veja abaixo o resultado final obtido:
Agora é a sua vez! Tente executar a consulta no seu banco de dados, salve o resultado em um arquivo .mm e aprimore o script!
Alguns desafios para você:
- Aprimore o script deste post e compartilhe fazendo um comentário. Podes organizar de forma distinta, aninhar informações, acrescentar mais dados ou ainda melhorar o aspecto visual;
- Utilize mapas mentais na gestão dos seus BDs;
- Tente gerar diagramas não hierárquicos utilizando as setas. Não é tão fácil, mas você consegue;
- Produza relatórios no mundo real utilizando o Freemind e os dados gravados no postgresql.
Basicamente, este post apresenta duas utilidades práticas:
- A criação de mapas mentais sobre o banco de dados, importante para DBAs e útil para o gerenciamento dos bancos de dados;
- A geração de mapas mentais baseados nas informações contidas nos bancos de dados, o que pode ser uma alternativa relevante aos tradicionais relatórios tabulares.
Mapas mentais são diagramas que mostram uma hierarquia de conceitos, ideias ou objetos quaisquer. O Freemind é uma das ferramentas livres mais conhecidas para a construção intuitiva de mapas mentais, e será utilizado neste texto. A ferramenta permite a exportação de mapas mentais para vários formatos, pesquisas e várias outras funcionalidades.
Baixe-a e instale a partir deste site.
O formato interno do freemind é uma linguagem de marcação similar ao HTML ou ao XML, então é razoavelmente fácil criar diagramas através de consultas sql.
Os passos são os seguintes:
- Criar uma consulta que retorne o valor no formato do Freemind;
- Salvar o resultado da consulta em um arquivo .mm (mm de Mind Map);
- Abrir o diagrama gerado no Freemind e fazer as eventuais customizações.
A consulta abaixo realiza uma consulta aos metadados do postgresql e apresenta o resultado ao usuário (tive de salvar como imagem por ter caracteres não aceitos pelo Blogger):
Veja abaixo o resultado final obtido:
Agora é a sua vez! Tente executar a consulta no seu banco de dados, salve o resultado em um arquivo .mm e aprimore o script!
Alguns desafios para você:
- Aprimore o script deste post e compartilhe fazendo um comentário. Podes organizar de forma distinta, aninhar informações, acrescentar mais dados ou ainda melhorar o aspecto visual;
- Utilize mapas mentais na gestão dos seus BDs;
- Tente gerar diagramas não hierárquicos utilizando as setas. Não é tão fácil, mas você consegue;
- Produza relatórios no mundo real utilizando o Freemind e os dados gravados no postgresql.
quinta-feira, 19 de abril de 2012
Webcast: Por que PostgreSQL?
sexta-feira, 25 de novembro de 2011
Criação de Crosstabs no PostgreSQL
Você já criou uma tabela cruzada, ou crosstab, utilizando SQL? Você sabia que era possível? Possivelmente você nunca precisou, mas criar crosstabs é um recurso à disposição que pode ser bastante útil!
Tabelas cruzadas apresentam mais de uma dimensão de forma integrada aos usuários, sendo uma forma importante para a melhor visualização de dados consolidados. Geralmente o cruzamento de dados neste tipo de tabela é feito na camada de apresentação das aplicações ou em componentes geradores de relatórios, mas isso não impede que você também possa implementar crosstabs via banco de dados.
Vamos exemplificar a criação de crosstabs no postgresql utilizando as tabelas abaixo:
* Tabela Loja - Basicamente apresenta a descrição da loja
-- Tabela Loja
CREATE TABLE loja (codigo integer, nomeloja varchar(20), observacao varchar(250));
INSERT INTO loja VALUES (1, 'Loja 1', 'Matriz');
INSERT INTO loja VALUES (2, 'Loja 2', 'Filial 1');
INSERT INTO loja VALUES (3, 'Loja 3', 'Filial 2');
INSERT INTO loja VALUES (4, 'Loja 4', 'Filial 3');
* Tabela Vendas - Apresenta as vendas realizadas para cada mês em cada loja.
-- Tabela Vendas
CREATE TABLE vendas (seqvenda integer, codloja integer, mesvenda integer, valor integer);
INSERT INTO vendas VALUES (1, 1, 1, 100);
INSERT INTO vendas VALUES (2, 1, 2, 100);
INSERT INTO vendas VALUES (3, 1, 3, 100);
INSERT INTO vendas VALUES (4, 1, 1, 100);
INSERT INTO vendas VALUES (5, 2, 2, 100);
INSERT INTO vendas VALUES (6, 2, 3, 100);
INSERT INTO vendas VALUES (7, 2, 1, 100);
INSERT INTO vendas VALUES (8, 2, 2, 100);
INSERT INTO vendas VALUES (9, 4, 3, 100);
INSERT INTO vendas VALUES (10, 4, 1, 100);
INSERT INTO vendas VALUES (11, 4, 2, 100);
INSERT INTO vendas VALUES (12, 4, 3, 100);
Vamos fazer consultas para mostrar as vendas com base em duas dimensões: a loja que fez a vendas e o período (mês) das vendas.
Em primeiro lugar, vamos colocar como colunas as lojas da tabela pai (loja), e como linhas as vendas da tabela filha, agrupando os dados por mês. A cláusula CASE é importante para atribuir o valor 0 (zero) quando a venda não for da loja a ser apresentada na coluna.
-- CROSSTAB
-- COLUNAS - LOJAS
-- LINHAS - Vendas em cada Mês
SELECT
(CASE vendas.mesvenda WHEN 1 THEN 'JAN' WHEN 2 THEN 'FEV' WHEN 3 THEN 'MAR' ELSE 'ERRO' END) AS MES,
SUM (CASE vendas.codloja WHEN 1 THEN vendas.valor ELSE 0 END) AS MATRIZ,
SUM (CASE vendas.codloja WHEN 2 THEN vendas.valor ELSE 0 END) AS FILIAL_1,
SUM (CASE vendas.codloja WHEN 3 THEN vendas.valor ELSE 0 END) AS FILIAL_2,
SUM (CASE vendas.codloja WHEN 4 THEN vendas.valor ELSE 0 END) AS FILIAL_3
FROM loja
INNER JOIN vendas
ON loja.codigo = vendas.codloja
GROUP BY vendas.mesvenda
ORDER BY vendas.mesvenda;
O resultado da consulta mostra inclusive a filial 2, que esteve fechada durante o período:
mes | matriz | filial_1 | filial_2 | filial_3
-----+--------+----------+----------+----------
JAN | 200 | 100 | 0 | 100
FEV | 100 | 200 | 0 | 100
MAR | 100 | 100 | 0 | 200
(3 registros)
Agora vamos fazer uma inversão: vamos colocar como colunas as lojas da tabela filha, vendas, e como linhas as informações da tabela pai, loja, com os dados agrupados por loja. A cláusula CASE é importante para atribuir o valor 0 (zero) quando a venda não for do mês a ser apresentado na coluna.
-- CROSSTAB 2
-- COLUNAS - Vendas em cada Mês
-- LINHAS - LOJAS
SELECT
(CASE loja.codigo WHEN 1 THEN 'MATRIZ' WHEN 2 THEN 'FILIAL 1' WHEN 3 THEN 'FILIAL 2' WHEN 4 THEN 'FILIAL 3' ELSE 'ERRO' END) AS LOJA,
SUM (CASE vendas.mesvenda WHEN 1 THEN vendas.valor ELSE 0 END) AS JAN,
SUM (CASE vendas.mesvenda WHEN 2 THEN vendas.valor ELSE 0 END) AS FEV,
SUM (CASE vendas.mesvenda WHEN 3 THEN vendas.valor ELSE 0 END) AS MAR
FROM loja
INNER JOIN vendas
ON loja.codigo = vendas.codloja
GROUP BY loja.codigo
ORDER BY LOJA;
Resultado da consulta:
loja | jan | fev | mar
----------+-----+-----+-----
FILIAL 1 | 100 | 200 | 100
FILIAL 3 | 100 | 100 | 200
MATRIZ | 200 | 100 | 100
(3 registros)
O exemplo acima pode ser incrementado e melhorado de várias formas (por exemplo, as tabelas não têm índices). Se você tem alguma sugestão ou forma alternativa de fazer crosstabs ou de melhorar os exemplos abaixo, não deixe de postar um comentário neste post!
Obs.: Existe um módulo do postgresql já bastante estável, chamado tablefunc que apresenta funções para a criação de tabelas cruzadas. É uma forma de criar crosstabs com menos trabalho, mas também com menos diversão e portabilidade! Mais informações sobre o tablefunc aqui.
Tabelas cruzadas apresentam mais de uma dimensão de forma integrada aos usuários, sendo uma forma importante para a melhor visualização de dados consolidados. Geralmente o cruzamento de dados neste tipo de tabela é feito na camada de apresentação das aplicações ou em componentes geradores de relatórios, mas isso não impede que você também possa implementar crosstabs via banco de dados.
Vamos exemplificar a criação de crosstabs no postgresql utilizando as tabelas abaixo:
* Tabela Loja - Basicamente apresenta a descrição da loja
-- Tabela Loja
CREATE TABLE loja (codigo integer, nomeloja varchar(20), observacao varchar(250));
INSERT INTO loja VALUES (1, 'Loja 1', 'Matriz');
INSERT INTO loja VALUES (2, 'Loja 2', 'Filial 1');
INSERT INTO loja VALUES (3, 'Loja 3', 'Filial 2');
INSERT INTO loja VALUES (4, 'Loja 4', 'Filial 3');
* Tabela Vendas - Apresenta as vendas realizadas para cada mês em cada loja.
-- Tabela Vendas
CREATE TABLE vendas (seqvenda integer, codloja integer, mesvenda integer, valor integer);
INSERT INTO vendas VALUES (1, 1, 1, 100);
INSERT INTO vendas VALUES (2, 1, 2, 100);
INSERT INTO vendas VALUES (3, 1, 3, 100);
INSERT INTO vendas VALUES (4, 1, 1, 100);
INSERT INTO vendas VALUES (5, 2, 2, 100);
INSERT INTO vendas VALUES (6, 2, 3, 100);
INSERT INTO vendas VALUES (7, 2, 1, 100);
INSERT INTO vendas VALUES (8, 2, 2, 100);
INSERT INTO vendas VALUES (9, 4, 3, 100);
INSERT INTO vendas VALUES (10, 4, 1, 100);
INSERT INTO vendas VALUES (11, 4, 2, 100);
INSERT INTO vendas VALUES (12, 4, 3, 100);
Vamos fazer consultas para mostrar as vendas com base em duas dimensões: a loja que fez a vendas e o período (mês) das vendas.
Em primeiro lugar, vamos colocar como colunas as lojas da tabela pai (loja), e como linhas as vendas da tabela filha, agrupando os dados por mês. A cláusula CASE é importante para atribuir o valor 0 (zero) quando a venda não for da loja a ser apresentada na coluna.
-- CROSSTAB
-- COLUNAS - LOJAS
-- LINHAS - Vendas em cada Mês
SELECT
(CASE vendas.mesvenda WHEN 1 THEN 'JAN' WHEN 2 THEN 'FEV' WHEN 3 THEN 'MAR' ELSE 'ERRO' END) AS MES,
SUM (CASE vendas.codloja WHEN 1 THEN vendas.valor ELSE 0 END) AS MATRIZ,
SUM (CASE vendas.codloja WHEN 2 THEN vendas.valor ELSE 0 END) AS FILIAL_1,
SUM (CASE vendas.codloja WHEN 3 THEN vendas.valor ELSE 0 END) AS FILIAL_2,
SUM (CASE vendas.codloja WHEN 4 THEN vendas.valor ELSE 0 END) AS FILIAL_3
FROM loja
INNER JOIN vendas
ON loja.codigo = vendas.codloja
GROUP BY vendas.mesvenda
ORDER BY vendas.mesvenda;
O resultado da consulta mostra inclusive a filial 2, que esteve fechada durante o período:
mes | matriz | filial_1 | filial_2 | filial_3
-----+--------+----------+----------+----------
JAN | 200 | 100 | 0 | 100
FEV | 100 | 200 | 0 | 100
MAR | 100 | 100 | 0 | 200
(3 registros)
Agora vamos fazer uma inversão: vamos colocar como colunas as lojas da tabela filha, vendas, e como linhas as informações da tabela pai, loja, com os dados agrupados por loja. A cláusula CASE é importante para atribuir o valor 0 (zero) quando a venda não for do mês a ser apresentado na coluna.
-- CROSSTAB 2
-- COLUNAS - Vendas em cada Mês
-- LINHAS - LOJAS
SELECT
(CASE loja.codigo WHEN 1 THEN 'MATRIZ' WHEN 2 THEN 'FILIAL 1' WHEN 3 THEN 'FILIAL 2' WHEN 4 THEN 'FILIAL 3' ELSE 'ERRO' END) AS LOJA,
SUM (CASE vendas.mesvenda WHEN 1 THEN vendas.valor ELSE 0 END) AS JAN,
SUM (CASE vendas.mesvenda WHEN 2 THEN vendas.valor ELSE 0 END) AS FEV,
SUM (CASE vendas.mesvenda WHEN 3 THEN vendas.valor ELSE 0 END) AS MAR
FROM loja
INNER JOIN vendas
ON loja.codigo = vendas.codloja
GROUP BY loja.codigo
ORDER BY LOJA;
Resultado da consulta:
loja | jan | fev | mar
----------+-----+-----+-----
FILIAL 1 | 100 | 200 | 100
FILIAL 3 | 100 | 100 | 200
MATRIZ | 200 | 100 | 100
(3 registros)
O exemplo acima pode ser incrementado e melhorado de várias formas (por exemplo, as tabelas não têm índices). Se você tem alguma sugestão ou forma alternativa de fazer crosstabs ou de melhorar os exemplos abaixo, não deixe de postar um comentário neste post!
Obs.: Existe um módulo do postgresql já bastante estável, chamado tablefunc que apresenta funções para a criação de tabelas cruzadas. É uma forma de criar crosstabs com menos trabalho, mas também com menos diversão e portabilidade! Mais informações sobre o tablefunc aqui.
A Função initcap()
A função initcap() é ao mesmo tempo simples e útil, e muitos desenvolvedores não a conhecem. Basicamente, a initcap() recebe como parâmetro uma string e a retorna de volta, colocando a primeira letra de cada palavra maiúscula, e as demais em letras minúsculas.
É bem prático para formatar strings de nomes de pessoas e lugares utilizando o próprio banco de dados.
Exemplo 1:
teste=# SELECT initcap('ALFA BETA GAMA');
initcap
----------------
Alfa Beta Gama
(1 registro)
Exemplo 2:
teste=# SELECT initcap('alfa beta gama');
initcap
----------------
Alfa Beta Gama
(1 registro)
A função initcap não altera caracteres numéricos, mas atua em qualquer "palavra" começada por caracteres, ainda que contenha números.
Exemplo 3:
teste=# SELECT initcap('123 123');
initcap
---------
123 123
(1 registro)
teste=# SELECT initcap('a123a A123A');
initcap
-------------
A123a A123a
(1 registro)
Esta função pode ser empregada na criação de índices(!), embora eu não veja nisso qualquer utilidade para a maioria das aplicações de banco de dados. Bom, se você conhece algum uso criativo desta função, não deixe de registrar nos comentários!
Exemplo 4:
teste=# CREATE TABLE simples(codi integer, nome varchar(50));
CREATE TABLE
teste=# CREATE UNIQUE INDEX indexnome ON simples((initcap(nome)));
CREATE INDEX
Outras funções similares mas mais conhecidas, são UPPER() e LOWER(), que passam a string passada como parâmetro para maiúsculas e minúsculas, respectivamente.
É bem prático para formatar strings de nomes de pessoas e lugares utilizando o próprio banco de dados.
Exemplo 1:
teste=# SELECT initcap('ALFA BETA GAMA');
initcap
----------------
Alfa Beta Gama
(1 registro)
Exemplo 2:
teste=# SELECT initcap('alfa beta gama');
initcap
----------------
Alfa Beta Gama
(1 registro)
A função initcap não altera caracteres numéricos, mas atua em qualquer "palavra" começada por caracteres, ainda que contenha números.
Exemplo 3:
teste=# SELECT initcap('123 123');
initcap
---------
123 123
(1 registro)
teste=# SELECT initcap('a123a A123A');
initcap
-------------
A123a A123a
(1 registro)
Esta função pode ser empregada na criação de índices(!), embora eu não veja nisso qualquer utilidade para a maioria das aplicações de banco de dados. Bom, se você conhece algum uso criativo desta função, não deixe de registrar nos comentários!
Exemplo 4:
teste=# CREATE TABLE simples(codi integer, nome varchar(50));
CREATE TABLE
teste=# CREATE UNIQUE INDEX indexnome ON simples((initcap(nome)));
CREATE INDEX
Outras funções similares mas mais conhecidas, são UPPER() e LOWER(), que passam a string passada como parâmetro para maiúsculas e minúsculas, respectivamente.
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!
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.
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.
segunda-feira, 12 de setembro de 2011
PostgreSQL 9.1 Lançado Oficialmente!
A muito aguardada versão 9.1 do PostgreSQL está disponível para download. O destaque são as mudanças relacionadas a performance e replicação, mas existem melhorias em praticamente todos os campos. É baixar, instalar e usar!
Abaixo o texto do anúncio oficial:
The PostgreSQL Global Development Group announces the release of
PostgreSQL 9.1. This latest version of the leading open source database
offers innovative technology, unmatched extensibility, and new features
such as synchronous replication, K-Nearest Neighbor indexing, and
foreign data wrappers.
"PostgreSQL 9.1 provides some of the most advanced enterprise
capabilities of any open source database, and is backed by a vibrant and
innovative community with proven customer success. PostgreSQL is well
positioned for building and running applications in the cloud," said
Charles Fan, Sr. VP R&D, VMware.
Responding to Users
Version 9.1 delivers several features which users have been requesting
for years, removing roadblocks to deploying new or ported applications
on PostgreSQL. These include:
* Synchronous Replication: enable high-availability
with consistency across multiple servers
* Per-Column Collations: support linguistically-correct
sorting per database, table or column.
* Unlogged Tables: greatly improves performance for ephemeral data
"Heroku runs the largest PostgreSQL database-as-a-service in the world,"
said James Lindenbaum, Heroku co-founder. "The release of synchronous
data replication with 9.1 provides our customers with innovative new
ways of protecting mission-critical data, and validates PostgreSQL as
one of the fastest-moving datastores available."
Advancing the State of the Art
Our community of contributors innovates with cutting-edge features.
Version 9.1 includes several which are new to the database industry,
such as:
* K-Nearest-Neighbor Indexing: index on "distance" for
faster location and text-search queries
* Serializable Snapshot Isolation: keeps concurrent transactions
consistent without blocking, using "true serializability"
* Writeable Common Table Expressions: execute complex multi-stage
data updates in a single query
* Security-Enhanced Postgres: deploy military-grade security
and Mandatory Access Control
"OpenERP has always relied on the enterprise-class features of
PostgreSQL to provide a fast, reliable and scalable foundation for the
Business Applications supporting our customers' operations every day.
Data integrity in highly concurrent and transactional contexts is a
critical topic for us, and we're very enthusiastic about the new
Serializable Snapshot Isolation of PostgreSQL 9.1!" said Olivier Dony,
OpenERP Community Manager.
Extending the Database Engine
PostgreSQL's extensibility enables users to add new functionality to a
running production database, and use them for tasks no other database
system can perform. Version 9.1 adds new extensibility tools, including:
* Foreign Data Wrappers: attach and query other databases
from PostgreSQL
* Extensions: easily create, load, and manage new database features
In PostgreSQL's 25th year of database development, our community
continues to advance database technology with every annual release.
Download version 9.1 now and experience the most advanced open source
database system in the world.
More information on PostgreSQL 9.1:
* Release notes
http://www.postgresql.org/docs/9.1/static/release-9-1
* Presskit
http://www.postgresql.org/about/press/presskit91
* Guide to 9.0:
http://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.1
Download 9.1 now:
* Main download page:
http://www.postgresql.org/download
* Source code:
http://www.postgresql.org/ftp/source/v9.1.0
* One-click installer, including Windows installer:
http://www.enterprisedb.com/products/pgdownload.do
Abaixo o texto do anúncio oficial:
------------------------------------------------------------------------------------
The PostgreSQL Global Development Group announces the release of
PostgreSQL 9.1. This latest version of the leading open source database
offers innovative technology, unmatched extensibility, and new features
such as synchronous replication, K-Nearest Neighbor indexing, and
foreign data wrappers.
"PostgreSQL 9.1 provides some of the most advanced enterprise
capabilities of any open source database, and is backed by a vibrant and
innovative community with proven customer success. PostgreSQL is well
positioned for building and running applications in the cloud," said
Charles Fan, Sr. VP R&D, VMware.
Responding to Users
Version 9.1 delivers several features which users have been requesting
for years, removing roadblocks to deploying new or ported applications
on PostgreSQL. These include:
* Synchronous Replication: enable high-availability
with consistency across multiple servers
* Per-Column Collations: support linguistically-correct
sorting per database, table or column.
* Unlogged Tables: greatly improves performance for ephemeral data
"Heroku runs the largest PostgreSQL database-as-a-service in the world,"
said James Lindenbaum, Heroku co-founder. "The release of synchronous
data replication with 9.1 provides our customers with innovative new
ways of protecting mission-critical data, and validates PostgreSQL as
one of the fastest-moving datastores available."
Advancing the State of the Art
Our community of contributors innovates with cutting-edge features.
Version 9.1 includes several which are new to the database industry,
such as:
* K-Nearest-Neighbor Indexing: index on "distance" for
faster location and text-search queries
* Serializable Snapshot Isolation: keeps concurrent transactions
consistent without blocking, using "true serializability"
* Writeable Common Table Expressions: execute complex multi-stage
data updates in a single query
* Security-Enhanced Postgres: deploy military-grade security
and Mandatory Access Control
"OpenERP has always relied on the enterprise-class features of
PostgreSQL to provide a fast, reliable and scalable foundation for the
Business Applications supporting our customers' operations every day.
Data integrity in highly concurrent and transactional contexts is a
critical topic for us, and we're very enthusiastic about the new
Serializable Snapshot Isolation of PostgreSQL 9.1!" said Olivier Dony,
OpenERP Community Manager.
Extending the Database Engine
PostgreSQL's extensibility enables users to add new functionality to a
running production database, and use them for tasks no other database
system can perform. Version 9.1 adds new extensibility tools, including:
* Foreign Data Wrappers: attach and query other databases
from PostgreSQL
* Extensions: easily create, load, and manage new database features
In PostgreSQL's 25th year of database development, our community
continues to advance database technology with every annual release.
Download version 9.1 now and experience the most advanced open source
database system in the world.
More information on PostgreSQL 9.1:
* Release notes
http://www.postgresql.org/docs/9.1/static/release-9-1
* Presskit
http://www.postgresql.org/about/press/presskit91
* Guide to 9.0:
http://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.1
Download 9.1 now:
* Main download page:
http://www.postgresql.org/download
* Source code:
http://www.postgresql.org/ftp/source/v9.1.0
* One-click installer, including Windows installer:
http://www.enterprisedb.com/products/pgdownload.do
Assinar:
Postagens (Atom)