Database Overkill

Há algum tempo eu escrevi sobre a lei dos 80-20 por aqui. Mas após uma conversa com o Everaldo Canuto, fiquei com vontade de escrever novamente sobre isso. Existem dezenas de linguagens disponíveis e utilizadas com frequência. Algumas tem nichos específicos de mercado como LISP, LUA ou AWK. E várias outras concorrem por fatias semelhantes de mercado. Em Banco de Dados, as coisas mudam, existem poucos fornecedores de SGDB que se destacam no mercado. Além disso, existe uma vontade mais que justificada de centralizar todos os dados de uma instituição no mesmo banco de dados. Administrar um ambiente com vários SGDBs de fornecedores diferentes é uma grande dor de cabeça, embora isto quase sempre ocorra. Mesmo assim, usar a ferramenta adequada para cada problema parece algo que merece ponderação. Existem inúmeros projetos em que a escolha do SGDB utilizado sequer passa por uma verificação das características realmente desejadas. Vejamos algumas opções que podemos utilizar e nem sempre são citadas:

Arquivos texto

Quem disse que não dá para fazer um monte de coisas bacanas guardando as informações apenas em arquivos texto? Por trás da cortina, há uma infinidade de programas que guardam seus dados em arquivos texto. Em aplicações de desktop, monousuário com uma quantidade de dados pequena e pouco complexos, os arquivos texto podem ser muito vantajosos. Arquivos de configuração são um exemplo comum, mas aplicações que trabalham com um pequeno volume de dados e poucas tabelas podem utilizar arquivos texto com tranquilidade.

Vantagens:

  • Tecnologia de domínio público
  • Praticamente toda linguagem de programação possui funções embutidas para ler e gravar dados em arquivos texto
  • Com um volume de até alguns milhares de linhas, o acesso pode ser bem mais rápido e simples que em um SGDB tradicional;
  • Você pode utilizar formatos como XML, CVS e outros que podem ser importados e exportados por outros programas facilmente.
  • Ocupa pouco espaço, é simples de realizar backup e consome poucos recursos da máquina.

Se você precisa usar uma quantidade maior de dados e quer o poder de uma linguagem SQL na mão, o SQLite pode ser a solução! Não é um SGDB, é uma biblioteca leve que você utiliza junto com o seu programa. Se você tem uma aplicação local como um site web com até 100 mil hits por dia, até 1GB de dados e poucas gravações concorrentes, o SQLite uma opção imbatível.

Vantagens:

  • Licenciado como Domínio Público
  • SQL e ACID
  • Apenas um arquivo para todo o banco de dados
  • Ocupa pouco espaço em disco (cerca de 250Kb)
  • Consome poucos recursos da máquina

Você tem uma estrutura de dados mais rígida e está preocupado com velocidade, transações concorrentes, replicação e precisa fazer tudo isso com hardware limitado? O BDB é uma biblioteca assim como o SQLite, mas com características menos flexíveis e mais robustas. É excelente em aplicações embarcadas e uma opção natural para serviços de diretório e outras aplicações, Você não tem uma linguagem de consultas como o SQL, tudo tem de ser definido via programação, você tem liberdade de definir estruturas totalmente adaptadas para a sua aplicação. Se você pode abrir mão da flexibilidade do SQL e precisa de desempenho e robustez, o BDB é uma escolha imbatível.

Vantagens:

  • Licença permite uso sem custos para aplicações com licenças livres ou para uso local
  • ACID, controle de transações avançado com MVCC
  • Replicação
  • Consome poucos recursos com bom desempenho

Ok, você precisa de um SGDB com todas a flexibilidade do SQL, funções, gatilhos, ACID, índices avançados e suportar diferentes aplicações com confiabilidade e robustez. O PostgreSQL é provavelmente um bom candidato. O PostgreSQL tem crescido com muita força nos últimos 10 anos e já provou que é capaz de suportar aplicações pesadas com bom desempenho.

Vantagens:

  • Licença BSD
  • Excelente conformidade com o padrão SQL
  • PL/pgSQL, PL/python, PL/Perl, PL/Ruby, PL/Java e outras linguagens procedurais
  • Replicação com Slony, pgPool e Hot Stand By
  • Particionamento de tabelas, MVCC, GiST, Tablespaces, Point In Time Recovery e outras funções avançadas

Há casos em que nenhuma destas soluções pode servir… em aplicações muito específicas, com grandes exigências de clusterização ou onde as demandas de integração com SGDBs já existentes são impressindíveis. Antes de pensar em sair comprando licenças da Oracle, DB2 ou Teradata, verifique quais são as suas reais necessidades. O fato é que muitas pessoas tem medo de adotar uma solução de um fornecedor que não gaste milhões de dólares em propaganda todos os anos. Antes de dizer que determinada solução não serve, teste e homologue. Mesmo no mundo lento e conservador dos bancos de dados as coisas mudam. Mudar pode significar uma implementação mais rápida, simples ou até um diferencial no mercado para o seu produto.

1 comentário

  1. Renan Responder

    Só faltou colocar as desvantagens de cada um e analisar outros SGDB. Fora isso, muito bom o post 😀

  2. jalexandre Responder

    Cenário: Vários bancos de dados com o mesmo volume de dados, mesmas tabelas, mesmas aplicações.
    Resultado: Prós e contras de cada banco em uma apliação específica sobre o seu controle.
    Autor: Você

    Está lançada a idéia.
    O que me diz de fazer um comparativo entre bancos de dados em uma aplicação ou situação sobre seu total controle?

    [ ]’s

  3. Telles Autor do postResponder

    A idéia aqui não é de colocar as desvantagens de cada SGDB, nem compará-los. São ferramentas diferentes que são adequadas para momentos diferentes. Existem chaves de diversos tipos, chave de boca, chave inglesa, chave de fenda, chave Phillips, chave alle, chave torks… e cada uma em diversos tamanhos. Não sei se vale a pena dizer qual ferramenta é melhor, mas dizer que algumas são mais adequadas para determinados tipos de trabalho.

    Confesso que fiz duas omissões propositais: MySQL e Oracle. É uma provocação mesmo… existem coisas mais simples que Oracle (o PostgreSQL) que o substituem em muitos casos, o mesmo acontecendo com o MySQL.

  4. Leandro DUTRA Responder

    Você foi bonzinho demais com as alternativas ao PostgreSQL:

    Arquivo texto: você não define o que é uma uma quantidade de dados pequena — já vi aplicações relativamente pequenas tendo problemas com fechar arquivos texto, por exemplo; e mesmo em arquivos de configuração já se sente necessidade de algo melhor, como provam os registros do AIX, do MS Windows e do Gnome. Creio que o problema aí é pensar na aplicação isolada, sem considerar o sistema como o todo.

    SQLite: você não menciona que o SQLite não suporta concorrência alguma, travando tudo para qualquer escrita — não somente uma tupla ou página.

    BDB: não tenho experiência direta, mas pessoas que respeito como o Lucas Santos dizem que é muito pouco confiável.

    Na minha experiência, são muito poucas as situações que um PostgreSQL não atende melhor que essas opções, se você (1) considerar o sistema como um todo e (2) considerá-lo parte do sistema operacional, como faz a Apple.

  5. Telles Autor do postResponder

    Em resposta:

    Sobre o arquivo texto, eis o trecho do texto: “Com um volume de até alguns milhares de linhas, o acesso pode ser bem mais rápido e simples que em um SGDB tradicional;”

    Pode não ser a melhor forma, mas é simples e direto. Funciona para muita coisa e vai continuar funcionando por muitos anos. O que muda é que muitos hoje optam pelo XML.

    Sobre o SQLite num blogue como este, a concorrência não faria a menor falta. Ninguém lê um artigo que eu não publiquei ainda. Veja que eu recomendei o SQLite num ambiente com “poucas gravações concorrentes”. A indicação é bem clara aqui.

    Sobre o BDB, sei que algumas aplicações como Open LDAP e Mailman utilizam o BDB em ambientes bastante exigentes. Mas sobre a estabilidade dele eu vou pesquisar mais.

    No geral, se você pensar em sistemas que rodam num celular, numa caneta, num mainframe, ou num desktop, as exigências de hardware mudam. Software então nem se fale… cada um com demandas específicas. O PostgreSQL é um banco de uso genérico. Existem versões específicas do PostgreSQL para demandas específicas, mas não para todas as especificidades. Fechar os olhos para isso é muito complicado.

  6. Pingback: SAVEPOINT » Planos de hospedagem para banco de dados

  7. Bruno Responder

    Então, só para confirmar pq acho que não ficou 100% claro.

    O SQLite e o BDB são implementados usando arquivos de texto?
    Ou arquivos de texto são só a primeira opção?

  8. Renato da Silva Responder

    Ótimo post, apesar que acho que alguns colegas não entenderam o objetivo dele. A intenção não é comparar, mas sugerir. Dependendo do que você deseja desenvolver usará um ou outro banco. Tenho uma aplicação Windows que roda no note dos meus vendedores que conecta no servidor Postgresql, via WEB e guarda na máquina cliente em uma base Sqlite, permitindo que a aplicação fique Offline. A decisão de usar SQLite foi muito acertada, pois ele é compatível com Android, o que me permitiu desenvolver a mesma aplicação para Tablets Android.

  9. Pingback: Não use o Postgres… embarcado. | Savepoint

  10. Pingback: Lei do 80 – 20 … | Alex Souza

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *