A Evans Data Corporation realizou uma pesquisa com 1400 usuário de bancos de dados em todo o mundo para saber o que eles acham dos principais SGDBs do mercado. A pesquisa virou matéria na InformationWeek que por sua vez foi comentada pelo Sr. Lewis Cunningham.

A pesquisa envolveu os seguintes bancos de dados:

• Informix Dynamic Server
• IBM DB2
• Microsoft SQL Server
• MySQL
• Oracle Database 10g or later
• PostgreSQL
• Sybase Adaptive Server

Os critérios de avaliação foram:

• Performance
• Funcionalidades de segurança
• Scalabilidade vertical
• Atomicidade
• Consistência
• Isolação de transações
• Durabilidade das transações
• Qualidade das ferramentas de modelagens
• Suporte ao XML
• Suporte a Multiplatforma
• Qualidade das ferramentas de gerenciamento inclusas no banco de dados
• Qualidade das ferramentas de gerenciamento avaliáveis por outros fornecedores
• Suporte a linguagens de programação

Antes de comentar sobre os resultados, é preciso dizer que a pesquisa é sobre a percepção dos usuários e não sobre testes de laboratório. portanto não reflete características reais dos softwares em questão e sim o que os seus usuários pensam deles.

Os resultados:

• A Oracle ficou em primeiro lugar em todos os critérios. Com o lançamento do 11g no ano passado eu imagino que toda a campanha de marketing esteja ainda viva na memória das pessoas, mas a posição não é de toda desmerecida. Particularmente, acredito que as ferramentas de monitoramento e gerenciamento da Oracle sejam realmente excelentes. Mas acredito que nos itens relativos a ACID (Atomicidade, Consistência, Isolação e Durabilidade) o DB2 rodando em mainframes ainda seja lider absoluto. O DB2 ficou em segundo lugar, mostrando que a Oracle realmente conseguiu cativar os corações do pessoal de TI. Também senti falta da Teradata como competidor, que é líder na área de Data Warehouse e teriam batido a Oracle e o DB2 nesta área. Pelos ítens da pesquisa, o foco foi avaliar os competidores que se destacam na area de OLTP.

• O MySQL foi o terceiro SGDB mais bem avaliado no geral. Apesar disso ter ficado longe no ranking no que diz respeito a ACID, escalabilidade e funcionalidades de segurança. O que puxou sua nota para cima foi a sua avaliação em suporte multiplataforma (2º lugar), performance (3º lugar), qualidade de ferramentas fornecidas por 3ºs (3º lugar) e suporte a linguagens de programação. Acho que a avaliação reflete bem o status do MySQL, sua popularidade e suas características de bicicleta de velódromo: é leve e rápido, mas não tem freios, câmbio, etc. O lançamento do falcon é a promessa de mudar isso. Particularmente eu gostaria que o MySQL continuasse exatamente do jeito que ele é, pois se torna uma ótima opção em sites web dinâmicos, que não se preocupam muito com transações.

• O MS SQL Server foi mal em suporte multiplataforma (ok, isso é óbvio) e performance. Se destacou na parte das ferramentas de modelagem, gerenciamento e suporte a XML.

• O PostgreSQL não foi muito bem… foi mal avaliado nas ferramentas de gerenciamento, modelagem, suporte a XML. No entanto foi bem avaliado em ACID e em funcionalidades de segurança. Estas avaliações positivas são importantes, pois demonstram a percepção dos usuários de que o PostgreSQL é confiável. Uma zebra ocorreu na parte de suporte a plataformas, pois o PostgreSQL deveria ser melhor avaliado aqui. Veja por exemplo que ele roda em FreeBSD uma plataforma para poucos.

O PostgreSQL foi o que teve a segunda pior avaliação Mas estamos em 2008 e apesar do nome da pesquisa, ela foi conduzida em dezembro de 2007. Com o lançamento do PostgreSQL 8.3 algumas coisas mudam na avaliação: a performance melhorou muito e o suporte a XML também. Isto já seria motivo para o PostgreSQL subir vários pontos e encostar no Oracle e no DB2.

O que temos que perceber é que o PostgreSQL vem se desenvolvendo sobre terreno firme. Com a parte de ACID bem resolvida, é possível crescer sem ter que abrir mão da segurança. A performance do PostgreSQL vem crescendo numa taxa que o coloca entre os líderes desta categoria. Algumas funcionalidades que precisam ser melhoradas como a parte de particionamento de tabelas já estão sendo trabalhadas para a versão 8.4. Assim, o que os usuários ainda sentem falta (veja o histórico das listas do PostgreSQL e você verá que isto é recorrente) são de ferramentas de monitoramento, gerenciamento e modelagem. Ainda há muito o que se trabalhar nesta área. Mas acredito que isto seja uma questão que se resolverá. O PostgreSQL tem evoluído muito na quantidade de funções e tabelas de sistemas capazes de fornecer informações úteis para o DBA. O pgsnmpd deverá abrir as portas para o gerenciamento corporativo. O que falta são ferramentas mais amigáveis. Isto não será problema. Já vemos coisas muito promissoras neste sentido. O PostgreSQL está sedimentado sobre uma base sólida, a parte do acabamento virá naturalmente.

Eu acompanho o do Avi Alkalay há algum tempo e já o vi em alguns eventos por aí. Acho interessante acompanhar os posts de alguém bem antenado, com um bom nível cultural e… bem, e ver um pouco da IBM nas suas postagens. Neste em especial, acho que a visão da IBM no mercado de Software Livre ficou mais transparente, e gostaria de comentar um pouco. Antes de mais nada eu gostaria de dizer que respeito profundamente o trabalho deste profissional, e acredito que estou aqui discordando em alguns pontos sobre o que ele escreveu, mas estou discordando fraternamente.

Enfim, uma coisa que fica claro quando lemos o Guia Livre do governo federal (ver cap. 2.2.2 “Razões para adoção de Software Livre”) é que se você migra para Linux pensando apenas em cortar custos, você terá problemas no caminho. Uma das grandes vantagens costuma ser a independência de um único fornecedor. Ficar dependente de um fornecedor é ruim por natureza. É um princípio de mercado. Seus negócios não devem depender totalmente de um único fornecedor, seja de matéria-prima, serviços ou máquinas. Software Livre ainda tem haver com liberdade. Eu realmente admiro por exemplo o Oracle e o DB2, mas prefiro o PostgreSQL onde eu tenho liberdade de escolher quem vai me dar suporte. As distribuições como Debian, Gentoo, Slackware e os BSDs livres, tem comunidades muito sérias atrás. Eu sei, o pessoal sempre diz: “mas eu preciso de alguém para segurar o rojão quando tiver um problema sério. Não posso contar com a comunidade apenas!”. Bom, eu gostaria de dizer que o suporte de algumas empresas (IBM, Oracle, Red Hat, Novell) nem sempre é bom. São incontáveis as vezes em que a comunidade me oferece respostas mais rápidas. Se fosse realmente bom, eles não precisariam atrelar as atualizações de segurança a um contrato de suporte. Muitos acabam pagando o suporte somente por causa das atualizações, todos sabem.

Estas empresas ainda competem pela qualidade do produto e não do serviço. Eu estou preocupado com a qualidade do serviço. Mas como estas empresas tem o monopólio dos serviços prestados sobre seus produtos, a qualidade e as opções tendem a cair. Algumas empresas não permitem que você utilize uma “versão não homologada” do software deles. Isto significa não poder recompilar o Kernel ou outra aplicação por exemplo. Vou lhe dizer que existem excelentes opções de suporte pago para as distribuições mantidas por comunidades. Mas o interessante, é que as empresas que prestam suporte soluções realmente livres, só sobrevivem se prestarem serviços de excelente qualidade. A competitividade é maior e isto já está acontecendo também no Brasil. Conheço empresas que fornecem soluções de alta qualidade para seus clientes, com compilações de software especiais para as necessidades dos seus clientes a custos muito atraentes e utilizando profissionais altamente qualificados. E o melhor de tudo é que você tem o direito de não gostar da empresa e chamar outra para prestar exatamente o mesmo serviço.

Vender licenças de softwares amplamente utilizados parece estar saindo de moda. É um movimento lento mas inflexível, particularmente nas grandes empresas (que se preocupam mais com a independência de fornecedor). O modelo onde os custos dos serviços amortizam os custos do desenvolvimento pode também não sobreviver para sempre. Ao fim e ao cabo, o Software Livre traz na sua liberdade a questão de remunerar melhor a competência, e não o papel. Entenda por papel um certificado, uma licença, uma patente outros conjuntos de átomos que não precisam se converter obrigatoriamente em bytes. Isto coloca em cheque grandes empresas e dá oportunidade para profissionais talentosos. O modelo de negócios baseado em soluções livres precisa de pessoas que pensem diferente. A IBM é um exemplo de como a liberdade é importante. Ao lançar o IBM-PC com um barramento aberto, proporcionou o florescimento de um ecossistema fantástico a sua volta. Depois, quando lançou um barramento proprietário, o MCA, perdeu espaço rapidamente no mercado que criou novos padrões abertos.

Estes dias li documentos da IBM propondo a migração do PostgreSQL e MySQL para o DB2. Vejam por vocês mesmos os links aqui e aqui. É claro que o DB2 tem qualidades fantásticas. Algumas das quais eu sei que os SGDBs livres terão muito trabalho para implementar. O DB2 é um excelente SGDB e praticamente inventou o SQL, não sendo a toa que é um dos que tem melhor conformidade com o padrão - vale lembrar que a equipe do PostgreSQL nunca pode participar do comitê que normatiza o padrão SQL, apesar de serem os que mais investem na conformância com o seu padrão. Mas veja bem, você migraria?

No entanto eu não acredito que as grandes empresas vão deixar de existir, mas acredito que a concorrência os farão rever seus conceitos e melhorar seus serviços. Assim ocorreu a liberação das versões gratuitas do Oracle, DB2 e do SQL Server, assim como a Microsoft lançou versões mais baradas do seu SO. Assim será com a prestação de serviços, conforme outras empresas ganhem terreno na qualidade dos serviços prestados. Quem ganha com este movimento são os bons profissionais de informática que tem seus serviços valorizados em detrimento de valores construídos sobre pilhas de papel. Ganham também os tomadores de serviço que terão serviços de melhor qualidade, com opções mais diversificadas e custos mais compatíveis com a qualidade dos serviços contratados.

Hoje um e-mail na lista do PostgreSQL me levou inspirou a escrever este texto. A questão é que muitas pessoas confundem replicação com clustering. A confusão não é a tôa… a palavra Cluster possui vários significados diferentes dependendo do contexto. Temos a idéia de tabelas clusterizadas, que possuem significado diferente no Oracle e PostgreSQL por exemplo e por sua vez não tem nada haver com o conceito de cluster de SGDB. O PostgreSQL chama de Cluster o conjunto de banco de dados gerenciados por uma única instância (conjunto de datafiles, arquivos de controle e processos no servidor que formam um SGDB). O PGCluster apesar do nome, é uma solução de replicação e não de clustering! Algumas soluções proprietárias também gostam de adotar o status de Cluster, quando na verdade se tratam de soluções de replicação. O princípio da replicação é a de ter cópias de dados em mais de um banco de dados que possam ser sincronizadas entre si. O princípio do cluster é ter vários SGDBs se comportando como se fossem uma só instância de forma transparente para a aplicação. Veja por exemplo que o conceito de Grid, que a Oracle adotou como buzz word, não existe de fato em banco de dados!

Quando falamos em Cluster de banco de dados, pensamos em 3 tipos de clusters:

• Shared All: Onde a memória (shared buffers) e os discos (datafiles) são compartilhados por cada nó do cluster;
• Shared Disc: Onde apenas os disco são compartilhados pelos nós do cluster;
• Shared Nothing: Onde cada nó tem a sua própria memória e discos;

Quando falamos em Replicação de banco de dados, pensamos em 4 tipos de replicação orientados por 2 paradigmas distintos:

• Replicação sincrona: onde todas as réplicas possuem sempre os mesmo dados;
• Replicação assíncrona: onde as réplicas podem ser sincronizadas depois que um alteração nos dados é realizada;

• Replicação MultiMaster: onde é possível realizar leitura e gravação em qualquer réplica;
• Replicação Master/Slave: onde apenas a réplica master permite gravação, enquanto as demais réplicas só permitem leitura;

Vejamos algumas diferenças entre replicação e cluster:

A replicação pode ser parcial ou total (em relação aos objetos do banco de dados), enquanto o cluster é sempre total em relação a uma instância do banco de dados (no caso do PostgreSQL seria em relação a um cluster criado pelo initdb).

• A replicação pode ocorrer em apenas uma parte dos dados de cada réplica enquanto no cluster toda a instância (datafiles + processos no servidor) do SGDB de cada nó deve fazer parte do cluster;
• A replicação pode ser assincrona ou síncrona enquanto o cluster sempre trabalha de forma síncrona.

• A replicação pode ser MultiMaster ou Master/Slave, e no Cluster todos os nós podem realizar operações de leitura e escrita (o equivalente a um MultiMaster).

• Técnicas de replicação, em geral não são boas para aumentar a escalabilidade horizontal de bancos de dados com alto volume de gravação (OLTP) enquanto os clusters shared all tem esta capacidade;
• A replicação guarda uma cópia dos dados replicados em cada instância do banco de dados enquanto o cluster mantém apenas uma cópia dos dados compartilhado para todos os nós do cluster. Note que, em algumas implementações de clusters, técnicas de replicação são combinadas para se evitar o Storage como ponto vulnerável no caso de tolerância a falha.

Em princípio, parece que uma uma replicação MultiMaster síncrona é equivalente a um Cluster Shared Nothing. No entanto, note que um Cluster Shared Nothing cada nó possui apenas uma fatia do banco de dados em seu storage enquanto na replicação MultiMaster síncrona, cada nó possui uma cópia completa dos dados. Cada técnica de cluster e replicação tem diversos tipos de implementações servindo para diferentes propósitos e com diferentes limitações. Saber distinguir cada um deles é fundamental para saber por onde começar a procurar por uma solução adequada para cada tipo de problema, seja ele de alta disponibilidade, balanceamento de carga ou de bancos de dados distribuídos.

O PostgreSQL conta hoje com várias soluções de Replicação Assíncrona Master/Slave que vai do Stand By (implementado no PostgreSQL padrão), Slony I e outros. O PgPool I e II é não são exatamente soluções de replicação e sim de pool de conexões com suporte a um tipo de replicação síncrona. A única solução de replicação MultiMaster Síncrona existente hoje é o PGCluster. O projeto do Slony II pretendia ser uma nova implementação deste tipo mas foi abandonado devida a alta complexidade do projeto. O PGCluster II pretende ser uma implementação de Cluster Shared All (no mesmo estilo do Oracle RAC), mas o projeto ainda é muito recente para se saber se ele será bem sucedido.

Para saber mais veja:

• PostgreSQL Replication Solutions por Bruce Monjian (um pouco defasado, mas muito didático);
• Replication/Clustering por Josh Berkus (tem uns erros nas últimas páginas, mas é muito interessante também);
• Database Clustering por Neil McAllister (foca a diferença entre as soluções de cluster da Orace e IBM)
• Transformando um Elefante numa Manada (palestra minha realizada no”1° Seminário de Inovações Tecnológicas em Cluster e Grid no Governo Federal“)