Escolhendo o banco de dados da sua aplicação

Como escolher o banco de dados que irá armazenar os dados de sua aplicação? Esta é uma pergunta que vários fazem ao iniciar um novo sistema e acaba optando as vezes por marcas apenas porque conhece a confiabilidade da empresa, porém não escolhe realizando testes realmente nativos.

Estive trabalhando recentemente em um novo projeto do qual será uma aplicação web utilizando o conceito de fazenda de processos (pool in work farm) e tive que escolher entre o melhor banco de dados.

Lembre-se: Nem sempre um banco de dados para um determinado tipo de aplicativo, será melhor para outro, ou seja, cada banco de dados pode ser melhor em determinadas tarefas que outros não são.

Ao iniciar a escolha entre o melhor banco, foram escolhidos os bancos de dados mais populares para se utilizar para um ambiente Web: SQL Server e MySQL. A tecnologia escolhida foi ASP Classic, porque é a que trabalho atualmente e sei fazer conexões com o banco sem receitas de bolo; o que preciso testar é a quantidade de querys executadas por banco, não importando de momento a aplicação front-end.

Em um processo de loop, foram realizadas mais de 1 milhão de inserção que querys do tipo insert em uma tabela, e no meio do processo realizando-se também processos de consulta e de remoção de dados.

Tanto SQL Server e MySQL foram submetidos ao mesmo teste, utilizando sempre consulta SQL dentro dos padrões ANSI, para garantir que diferenças não afetem o resultado. (Ex.: SQL Server precisa do elemento TOP, enquanto MySQL utiliza-se do comando LIMIT, dos quais não foram usados nos testes).

Em todos os testes, MySQL superou em cerca de 3 segundos em relação ao SQL Server. Um tempo baixo no qual permitiria escolher o SQL Server, se o quesito fosse marca, porém para uma aplicação web onde inúmeros usuários acessam ao mesmo tempo, quanto menor o tempo melhor, e além disto, a maioria dos planos de hospedagem (internacionais e brasileiros) não impõem limites de tamanho e de utilização de várias bases de dados ao mesmo tempo.

Continuando os testes, hoje ainda fizemos um teste para provar quem é melhor:

- File System (Sistema de Arquivos)

- MySQL utilizando LONGBLOB para salvar os arquivos em células.

Parece até piada, mas sim, MySQL superou em 0,25 segundos e foi mais rápido que o sistema de arquivos NTFS de um servidor.

Ao fazer um download de uma imagem estática de 4Mb, o servidor entregou em média em 4,45 segundos.

Ao chamar a conexão com o banco MySQL e realizar a consulta para trazer a célula contendo uma cópia desta imagem com os mesmos 4Mb, a imagem chegou no navegador em média em 4,15 segundos, sempre abaixo da média trazida por download.

Nem perdemos tempo em fazer o teste com o SQL Server (que depende do sistema de arquivos para gerenciar o banco de dados).

MySQL foi eleito para esta aplicação, porque além de ser um pouco mais rápido que o SQL Server, também foi excelente para armazenar e recuperar arquivos gravados em LONGBLOB (tentamos com Blob mas o mesmo não permitia subir imagens muito grandes).

Para quem não sabe o que é web-farm ou um aplicativo para fazenda, vamos lá as dicas de como é em geral uma aplicação web tradicional:

Aplicação web tradicional (Plataforma Windows, IIS):

- Aplicação é executada em apenas 1 work process (w3wp.exe).

- Sessão do usuário (e suas variáveis) ficam armazenadas na memória RAM do servidor (junto ao processo w3wp.exe).

- Variáveis de aplicação ficam também armazenadas na memória RAM do servidor (junto ao processo w3wp.exe).

- Quando um usuário faz login, o w3wp.exe coordena a execução da aplicação, sempre uma página por vez em fila, ou seja, há um pipeline de processamento das páginas da aplicação para todos os usuários em um gargalo só.

- Só funciona em um computador.

- Não permite distribuir a aplicação entre outras máquinas.

- Distribuir apenas com conceito de máquina virtual distribuída, que depende de servidores próprios e de uma boa infra para garantir os serviços sempre em funcionamento.

Aplicação para web-farm:

- Aplicação roda em 1 ou milhares de work process (w3wp.exe múltiplos em execução paralela).

- Sessão do usuário precisa ser mantida em banco, pois cada processo da página pode ou não passar pelo w3wp.exe que tem as informações do usuário, ou seja, não se pode usar o formato de sessão do usuário padrão da linguagem de programação.

- Variáveis de aplicação devem ser carregadas do banco de dados, como da mesma forma, se a página for executada em um processo diferente em execução, os dados da aplicação podem mudar.

- Não depende de w3wp.exe nem da memória RAM do servidor para segurar a sessão do usuário.

- Alto uso do banco de dados.

- Permite distribuir a aplicação entre vários computadores front-end e utilizar qualquer tipo de linguagem de programação compatíveis com o servidor web em execução.

- Permite deixar um usuário logado no sistema para sempre, até que ele saia ou por um período (realizado na programação capturando data do último login de acesso).

- Permite computar um status refinado dos usuários realmente logados na aplicação.

- Permite espalhar entre outros países e utilizar servidores próximos dos usuários usando geo-localização.

- Permite utilizar servidores genéricos, baratos, fáceis de encontrar em qualquer plano de hospedagem.

- Exige um bom servidor de banco de dados com potencial para suportar muitas transações.

Como eu disse, nem sempre uma base de dados escolhida para um tipo de aplicação, será sempre a ideal para outros tipos, porém em nosso caso, por exemplo, não realizamos testes em base de dados da Oracle, Postgre ou DB2 da IBM, pois os mesmos não são facilmente encontrados nos planos de hospedagens para pequenos negócios (Locaweb, UOL Host, etc), que inclusive cobram valores adicionais para bases como SQL Server, e no caso do MySQL sempre disponibilizam em média 10 bases gratuitas para uso sem restrição de tamanho.

Observação com relação ao teste de upload de arquivos em banco: Teste de arquivos de imagem foram realizados com arquivos de até 5 Mb em formato JPEG.