Artigos Banco de Dados Trabalhando com o PostgreSQL: implantação do banco de dados
Por que eu devo ler este artigo:São inúmeras as situações em que o administrador de dados ou sysadmin não dispõe de métricas eficazes para obter a melhor implementação e performance do banco de dados. Algumas vezes isso decorre até da falta de informação sobre as potencialidades oferecidas pelo sistema. Para os que optaram pelo PostgreSQL em sua organização, apresentamos nesse artigo diversos aspectos técnicos, do hardware ao software, da instalação ao tuning, do sistema gerenciador de banco de dados ao sistema operacional, das formas de instalação à configuração do cluster, visando auxiliar na tarefa de implantação para que o leitor obtenha o melhor resultado em sua instalação.

A produção e interpretação de dados relacionados às atividades humanas sempre fomentou a evolução da tecnologia que atualmente constitui como um dos pilares da civilização moderna. Na década de 70, no séc. XX, não era diferente. Os setores comercial e industrial da época já manifestavam o interesse em obter acesso mais rápido aos seus registros em decorrência do armazenamento convencional de arquivos, bem como reduzir a redundância e inconsistência dos dados até que fosse possível compartilhá-los, garantindo certo nível de segurança. Apostando nesse mercado, a IBM (International Business Machines) iniciou suas pesquisas determinada a oferecer uma ferramenta que atendesse à nova demanda. Durante as pesquisas, alguns modelos de bancos de dados foram explorados, dentre eles, o hierárquico, de rede e relacional. Nesse contexto, o modelo de dados deve ser entendido como o conjunto de ferramentas conceituais para a descrição de dados, seus relacionamentos, semântica e restrições que mantenham a consistência. Esses modelos se subdividem em três grupos: lógicos baseados em objetos, lógicos baseados em registros e modelo físicos de dados.

Retornando à pesquisa da IBM, ela batizou o resultado do projeto inicial com o nome System R, visionário na implementação de sistemas de bancos de dados relacionais e na implementação da SQL (Structured Query Language), embora não fosse integralmente fiel ao proposto por Codd em suas regras para o modelo relacional. Na época seus autores divulgaram generosamente os detalhes de seu objeto de estudos à comunidade por meio de artigos, o que encorajou dois pesquisadores de Berkley, os cientistas Michael Stonebraker e Eugene Wong, a desenvolverem o próprio projeto de banco de dados relacional. Ambos já haviam arrecadado fundos com o projeto INGRES (Interective Graphics Retrieval System) – um banco de dados geográfico que fora desenvolvido para um grupo econômico, implementado por um grupo de estudantes e financiado por órgãos de pesquisa do governo norte-americano – o que garantiria subsídio ao início do projeto. Do projeto “INGRES” derivaram outros sistemas de bancos de dados, tais como SQL Server, Sybase e o próprio PostgreSQL.

O projeto Postgres foi iniciado em 1986 na Universidade de Berkley, e sua proposta era suprir as dificuldades impostas pelo INGRES, como a manipulação de tipos definidos pelo usuário (hoje conhecidos como objetos) pelo sistema relacional e a de grande volume de armazenamento. Através dessa lógica, o nome PostgreSQL veio da aglutinação de “post-INGRES” (após o INGRES).

Em 1994 o PostQUEL, que era a linguagem nativa para interpretação de consultas implementada pelo Postgres, foi substituída pelo interpretador SQL. Esse foi um marco importante na história do projeto, que após isso passou a ser chamado PostgreSQL.

PostgreSQL

O PostgreSQL utiliza o modelo lógico baseado em registros através do modelo relacional. Adicionalmente, o projeto atual permite manipulações diretas análogas ao conceito da orientação a objetos, como herança, polimorfismo e o uso de objetos. É distribuído sob a licença BSD (Berkley Software Distribution), que caracteriza o software como pertencendo ao domínio público e, portanto, livremente personalizável, exigindo somente o reconhecimento autoral para a distribuição do binário, versão original ou alterada. Essa licença é muito permissível e viabiliza o funcionamento de softwares em diferentes formatos de licença trabalhando juntos. Não se pode dizer que a licença BSD é necessariamente melhor que a licença “concorrente”, GPL (Gnu General Public License). A questão é que a primeira é menos restritiva. Note que tanto a licença BSD quanto o Postgres tiveram origem no mesmo local, a Universidade de Berkley.

A norma ACID, acrônimo para os conceitos de Atomicidade, Consistência, Isolamento e Durabilidade, que representam os critérios básicos para transações e recuperações a falhas, é integralmente implementada pelo PostgreSQL. Essas propriedades asseguram aspectos essenciais para a qualidade das operações, tais como controle de integridade referencial e de concorrência de multi-versão, ou MVCC (Multiversion Concurrency Control), além de ser premissa do modelo relacional.

Existem muitas implementações maduras no PostgreSQL, tais como replicação síncrona e assíncrona, segurança SSL(Secure Socket Layer) e criptografia nativos, utilização de clusters de dados, operação com multithreads, multiplataforma, suporte a 24 idiomas, backups PITR (Point-In-Time Recovery), áreas de armazenamento (tablespaces), pontos de salvamento (savepoins), subconsultas e visões atualizáveis, controle de locking, suporte à definição de funções em PL/PgSQL, Perl, Python, Ruby, dentre outras linguagens de programação, foreign data-wrappers, alerta e failover automatizado para ambientes de missão crítica, além de inúmeras características vantajosas. Existe também o interesse crescente da comunidade em apoiar o desenvolvimento do software através de contribuições e patrocínios, como é o caso da Hewlett-Packard, VMware, EnterpriseDB, Fujitsu, Google, Skype e RedHat, para citar algumas. Por isso, o PostgreSQL é frequentemente apontado como ótima opção em projetos que demandem estabilidade e facilidade de uso conjugada a boa curva de aprendizado, visto que ostenta a reputação de ser o sistema gerenciador de banco de dados de código livre mais sofisticado disponível. Como dito anteriormente, o PostgreSQL é um projeto comunitário, open source, coordenado pelo PostgreSQL Global Development Group, e que não limita o escopo de suas capacidades, recursos e funcionalidades aos usuários, ou seja, está totalmente à disposição para qualquer um, a qualquer momento.

Um aspecto que corrobora o alinhamento às demandas mais atuais, como a disponibilidade de serviços em nuvem e a escalabilidade vertical, é o fato de que o PostgreSQL não é somente relacional: é multi-paradigma, agregando também funcionalidades No-SQL (Not Only SQL). Aqui temos um bom exemplo de como o uso de extensões pode ampliar a gama de possibilidades do sistema. O PGXN (PostgreSQL Extension Network) é um sistema de distribuição central para bibliotecas open source de extensão para o PostgreSQL. De forma similar, também existe o pgFoundry, que reúne diversos projetos relativos ao PostgreSQL.

A maioria das linguagens de programação modernas proveem interface nativa para conexões com o PostgreSQL. Como alternativa em caso de ausência, há disponibilidade de acesso através da interface ODBC (Open Database Connectivity), que permitiriam acesso por produtos da Microsoft como Access e Excel. Aplicações desenvolvidas em Java contam com o suporte oferecido pelo driver JDBC (Java Database Connectivity). Já para o PHP, teríamos o PDO (PHP Data Objects) como opção. O acesso aos dados ocorre de várias formas, podendo ser através de linha de comando (psql), pelo código SQL embutido na aplicação/framework, por cliente gráfico (pgAdmin III) ou via navegador web (phpPgAdmin), por exemplo.

Arquitetura e versionamento

Outro ponto forte do projeto é a sua arquitetura cliente-servidor (ver Figura 1), fazendo com que o acesso aos dados seja distribuído a clientes que não os acessam diretamente mas via processo no servidor (postmaster), mesmo que o cliente esteja acessando na mesma máquina onde o serviço está instalado. A seguir, uma forma simplificada de como esse acesso se dá, através de TCP/IP (Transfer Control Protocol/Internet Protocol) ou Internet, via tunelamento.

Arquitetura cliente-servidor implementada no PostgreSQL

Figura 1. Arquitetura cliente-servidor implementada no PostgreSQL.

A Tabela 1 indica algumas das limitações para as capacidades de armazenamento.

Tamanho máximo de um banco

Ilimitado

Tamanho máximo de uma tabela

32 TB

Tamanho máximo de uma linha

1,6 TB

Tamanho máximo de um campo

1 G ...

Quer ler esse conteúdo completo? Tenha acesso completo