Vamos falar de Banco de Dados e seu uso em aplicações WEB

Vamos falar de Banco de Dados e seu uso em aplicações WEB

Chegou a hora de apanhar dos DBAs e dos desenvolvedores Backend, mas preciso dizer a verdade, nua e crua: Vocês estão usando o banco de dados de forma errada!

Pelo menos 65% dos programadores e 100% dos DBAs que conheço usam o banco de dados (qualquer um deles: Oracle, MS-SQL, MySQL, PostgreSQL) de forma errada quando falamos de aplicações WEB. Vamos aos motivos…

Banco de dados é uma tecnologia antiga – eu mesmo, quando programava lá nos idos dos anos 80, já usava banco de dados (https://en.wikipedia.org/wiki/MAPPER). No decorrer dos anos, à medida em que as empresas demandavam mais funcionalidades, novas características foram agregadas aos produtos.

Iniciamente, o banco de dados nada mais era do que…. Um Banco de Dados! Ele simplesmente armazenava as informações e possuia índices para facilitar a busca destes dados. Com o aumento da massa de dados, alguns processos de manutenção foram criados e as Store Procedure nasceram.

Nos anos 2000, algum “cara” muito antenado (ou um cliente com muito dinheiro), inventou de se armazenar imagens dentro do banco de dados… E nasceu a armazenagem de binários em tabelas de banco… Veio também a busca FullText, que “varre” tabelas em busca de um trecho de texto…

Para as intranets, este era o melhor dos mundos!

Mas aí veio a internet e a demanda por aplicações conectadas e disponíveis cresceu… Mas o conceito de desenvolvimento continuava o mesmo.

A empresa contratava um datacenter, colocava seu servidor (com 32 cores, 64Gb de RAM e 3Tb de storage) e disponibilizava a mesma aplicação para o mundo. Com o passar do tempo, o número de usuários aumentava, o consumo de banco crescia exponencialmente (disco e CPU) e a máquina de frontend (com a aplicação monolítica) “pedia arrego”. Solução? Mais CPU, mais disco e mais Memória – o tal de crescimento vertical.

A aplicação faz sucesso e o servidor não tem mais para onde crescer: atingiu o limite de hardware para mais CPU, memória e disco… A solução era o crescimento horizontal, colocando mais um servidor ao lado do primeiro.

E o banco? Como fica?

Busca FullText, imagens blob, armazenamento de sessão, autenticação… Ufa!!! Hoje o banco de dados é um misto de Superman, Flash, Arrow e “MacGyver”; Ele faz de tudo, o que demanda cada vez mais hardware e storage de disco.

O que fazer nesta situação? Voltar aos primórdios da era de ouro dos banco de dados!!!!

E o que isto quer dizer?

Precisamos aliviar o banco de dados, deixando-o somente com o que ele faz bem: armazenar dados. O restante das funções deve ser entregue para produtos especializados. Vamos aos exemplos:

1) Cache de Sessão de Aplicação: Todas as aplicações hoje possuem métodos/objetos para uso de cache em memória (memcached, redis) para armazenamento de sessão. Quando falamos em ambientes escaláveis, devemos evitar de armazenar sessões em FileSystem ou dentro do servidor (podemos ter mais de um servindo o conteúdo simultaneamente)

2) Busca: Mais de 70% do consumo de CPU e memória de um banco de dados é gasto atendendo querys de aplicação (isto quando a aplicação não força um pouco mais executando uma store procedure!). Migre suas buscas para um engine de busca, como ElasticSearch, Solr ou similar. Eles possuem muito mais recursos do que um banco de dados para te entregar o conteúdo – GeoLocalização, FullText com relevância são alguns exemplos.

3) Imagens: Nunca, mas nunca use um banco de dados para armazenamento de imagens. Além de aumentar o consumo – imagens em banco são armazenadas como binário, aumentando o tamanho em até 40% – a área de armazenamento de banco de dados é uma “área nobre”, com um custo alto (storage, licenciamento, CPU e memória). Opte por usar uma solução Stateless, via REST (S3 da AWS, por exemplo). o custo é infinitamente menor e possibilita a escalabilidade da aplicação. Não salve no filesystem, pois você não terá condições de escalar rapidamente em caso de gargalo da aplicação.

4) Autenticação: Utilize sempre um LDAP. Se você gosta de windows, use o AD; se é um adepto de linux, use o OpenLDAP. Ele foi feito para crescer, possui replicação automática e particionamento – além de que todas as aplicações possuem métodos/objetos prontos para autenticação nele.

Estas 4 ações irá reduzir, no mínimo, em 60% o consumo de seu banco de dados (isto eu falo por experiência própria) e fará com que ele deixe de ser o ponto único de falha e o gargalo de seu ambiente.

Há várias outras técnicas para melhorar a performance de seu ambiente e reduzir custos, mas ficam para um outro artigo!