PostgreSQL x MySQL. Qual Escolher?

Olá caros amigos. Mais um artigo que estou publicando e gostaria desta vez de falar sobre dois excelentes SGBDs, fazendo as devidas comparações.

São dois SGBDs, ambos gratuitos. O MySQL está disponível sob a GPL (Licença Pública GNU), além de possuir uma licença convencional, para quem não quiser estar limitado aos termos da GPL. Já o PostgreSQL está disponível sob a flexível licença BSD.

O MySQL é o mais utilizado no desenvolvimento de aplicações onde a velocidade é importante (porém isto tem mudado com versões mais recentes do PostgreSQL), enquanto que o PostgreSQL se destaca por ser mais robusto e possuir muito mais recursos que o MySQL. Esses recursos tornam o PostgreSQL um “banco de dados” no conceito de muita gente.

Nas últimas versões do MySQL, os desenvolvedores acrescentaram diversos recursos que já existiam no PostgreSQL como transações (confirmação e cancelamento de operações realizadas COMMIT e ROLLBACK), triggers (gatilhos), Stored Procedures (Procedimentos Armazenados), views (visões), lock line (bloqueio em nível de  linha) e constraints (cláusulas de integridade).

No entanto, o PostgreSQL continua sendo mais eficiente em vários aspectos. Possui um sofisticado mecanismo de bloqueio (MVCC veremos a seguir), suporta tamanhos ilimitados de linhas, bancos de dados e tabelas (até 16TB), aceita vários tipos de sub-consultas, possui mais tipos de dados e conta com um bom mecanismo de FAILSAVE (Segurança contra falhas, por exemplo no desligamento repentino do sistema).

Como já foi dito no início deste artigo, a vantagem do MySQL ainda é a velocidade de acesso (que às vezes nem é notada pois está na escala de milésimos de segundo). Para bases de dados muito grandes, complexas e que exige confiabilidade e escalabilidade vale a pena usar o PostgreSQL. Para base de dados menores, não há diferença na velocidade ou pode se desconsiderar os milésimos de segundos entre os dois SGBDs.

A Técnica MVCC – PostgreSQL

Multi-Version Concurrency Control (MVCC) é uma técnica avançada do PostgreSQL que resolve aquele antigo problema de ambientes multiusuários de banco de dados, os LOCKs (bloqueios) que fazem o usuário ficar esperando.

Ao contrário de outros SGBDs que utilizam que utilizam LOCKs para controle de concorrência, o PostgreSQL mantém a consistência dos dados usando um modelo multiversão. Neste modelo, cada transação terá sua versão do banco de dados, estando protegidas de acessar dados inconsistentes que poderiam ser gerados por outras transações. Portanto, o MVCC oferece o isolamento de transações, alem de garantir que leituras nunca aguardarão escritas e vice-versa.

Isolamento das Transações

O Padrão SQL ANSI/ISSO define quatro níveis de isolamento de transações baseados nas seguintes situações:

Dirty Reads: ocorre quando uma transação lê dados escritos por uma transação corrente que ainda não foi confirmada (COMMIT).

Non-Repeatable Reads: uma transação lê um dado que ela já havia lido anteriormente, e descobre que aqueles dados foram modificados por outra transação (confirmada após a primeira leitura).

Phantom Read: uma transação lê um conjunto de linhas que satisfaça algum critério de pesquisa. Outra transação insere uma linha que satisfaça o critério da anterior. Se a primeira transação executar novamente o comando de pesquisa, ela receberá um conjunto diferente de linhas.

Os quadros de níveis de isolamentos são descritos a seguir para você entender melhor.

A tabela a seguir mostra quais situações podem ocorrer em cada um dos níveis de isolamento:

Obs.: No PostgreSQL estão disponíveis os níveis de isolamento READ, COMMITTED e SERIALIZABLE.

Para Finalizar um Bate–bola rápido...

Características do MySQL

Foco em facilidade de administração e baixo consumo de recursos do hardware. Tornou-se popular graças à Internet, pois os bancos tradicionais tinham tempos de conexão extremamente elevados, inadequados para aplicações CGI. Para atingir seus objetivos, não implementava  funções com grande overhead como integridade referencial, commit, rollback e níveis de isolamento de transação.

a. Servidor multithreaded:
b. Um único processo mysqld atende a todos os clientes.
c. Tabelas e índices correspondem à arquivos físicos e bancos de dados correspondem à diretórios.
d. Distribuição de dados em múltiplos discos deve ser feita manualmente, por meio de links simbólicos.
e. Segurança via SSL
f. Com suporte à transações
g. Recursos SQL mais sofisticados, como agregados, COMMIT e ROLLBACK, triggers (gatilhos), Stored Procedures (Procedimentos Armazenados), views (visões), lock line (bloqueio em nível de linha) e constraints (cláusulas de integridade).
h. Maior compatibilidade com o padrão ANSI.

Plataformas Plataformas Suportadas pelo MySQL

a. Servidor
b. Sistemas Unix-Like:
c. GNU/Linux, FreeBSD, Solaris, AIX, HP-UX,...
d. Win32: Windows 95/98/ME, Windows NT/2000/XP/NET
e. OS/2 (em desenvolvimento para BeOS e LynxOS)
f. Cliente: Drivers ODBC e dbExpress para Unix e Windows Várias ofertas de drivers JDBC 2.0 100% Java.

Quando Usar o MySQL

a. Back-end para geração de conteúdo de web sites
b. Aplicação envolvendo basicamente consultas e adição de dados. Sugiro não usar para aplicações com fortes demandas transacionais, especialmente se houverem atualizações concorrentes!
c. Empresas como o Yahoo Finance combinam o MySQL (aplicações web) com um outro banco de dados (retaguarda financeira).

Características do PostgreSQL

O PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional (SGBDOR), baseado no PostgreSQL desenvolvido pelo Departamento de Ciência da Computação da Universidade da Califórnia em Berkeley. O POSTGRES foi pioneiro em vários conceitos que somente se tornaram disponíveis muito mais tarde em alguns sistemas de banco de dados comerciais.

O PostgreSQL é um descendente de código fonte aberto deste código original de Berkeley. É suportada grande parte do padrão SQL:2003, além de serem oferecidas muitas funcionalidades modernas, como:

. comandos complexos
. chaves estrangeiras
. gatilhos
. visões
. integridade transacional
. controle de simultaneidade multiversão

Além disso, o PostgreSQL pode ser estendido pelo usuário de muitas maneiras como, por exemplo, adicionando novos:

. tipos de dado
. funções
. operadores
. funções de agregação
. métodos de índice
. linguagens procedurais

Devido à sua licença liberal, o PostgreSQL pode ser utilizado, modificado e distribuído por qualquer pessoa para qualquer finalidade, seja privada, comercial ou acadêmica, livre de encargos.

g. Implementação completa dos padrões ANSI para o SQL, como selects aninhados, integridade referencial, views, triggers,...
h. Extensões orientadas a objeto, como tipos abstratos de dados, herança, atributos multivaluados...
i. Funções definidas pelo usuário, mas que não podem retornar registros, portanto não tem ainda a mesma funcionalidade dos procedimentos armazenados em outros bancos
j. Servidor em múltiplos processos: um único processo postmaster recebe as conexões de rede, e inicia um processo postgres para cada cliente
l. Uso intensivo de memória compartilhada e semáforos – pode ser necessário ajustar parâmetros do kernel para melhorar o desempenho ou para atender a cargas de trabalho maiores
m. Tabelas e índices correspondem à arquivos físicos e bancos de dados correspondem à diretórios. Podem ser configurados vários diretórios diferentes para hospedar (arquivos de) bancos de dados
n. Segurança via Kerberos e/ou SSL
o. Views funcionais
p. Funções definidas pelo usuário em TCL, Perl, C,...
q. Outer joins
r. Postgres file system, para suporte a raw devices
s. Máquina Virtual Java integrada ao banco
t. Backups on-line rápidos
u. Two-phase commit.

Plataformas Plataformas Suportadas Pelo PostgreSQL

a. Sistemas Unix-like
b. GNU/Linux, FreeBSD, Solaris, AIX, HP-UX,...
c. Windows NT/2000/XP/NET (Cygwin) e MacOS X
d. Cliente
e. Bibliotecas nativas C para Unix, Win95/NT e OS/2
f. Drivers ODBC (2.5) e dbExpress nativos para Unix e Windows Driver JDBC 1.0 (2.0 parcial) 100% Java

Quando Usar o PostgreSQL

Aplicações com fortes componentes transacionais. Aplicações que necessitem de tipos de dados especializados, como Sistemas de Informações Geográficas (SIG) e repositórios de meta-dados Projetos baseados em metodologias Orientadas Objeto – perda de compatibilidade com o padrão ANSI SQL Aplicações OLAP “light”, que não necessitem do nível de sofisticação de um DataWarehouse.

Agora é com você! Grande Abraço!