Temperatura de dado

Como otimizar custos, performance e manutenção do seu produto

Todo novo sistema um dia se tornara um legado, todo novo sistema terá dados históricos, alguns sistemas chegam a ter milhões de registros em uma única tabela, claro que hoje em dia o contexto mudou, mas do mesmo jeito que era há 20 anos atrás, fazer uma gestão eficiente da sua base de dados ainda contínua um desafio.

Mesmo pensando em empresas que rodavam software em seus datacenters privados ou empresas que atuam com provedores cloud, quantas vezes fizemos perguntas como:

Quantas horas vai levar o alter table?

Quantas horas vai levar o update?

Essa consulta esta lenta, tem index nessa tabela?

Essa engine de banco suporta essa volumetria?

Por que eu pago tão caro com o serviço de banco de dados?

E se eu mudar de engine?

E se eu mudar de provedor cloud?

Se você tem algum tempo no mundo de tecnologia, com certeza já se fez essas perguntas. Grandes empresas como Netflix, Google, Amazon, Facebook, Microsoft e até mesmo os grandes bancos tradicionais já entendem que o particionamento dos dados é uma necessidade e não uma opção, aliais, você já tentou tirar seu extrato com um período superior há 24 meses e recebeu na hora?

Uma boa estratégia de temperatura de dados, pode não apenas facilitar a manutenção de seus sistemas, ela pode melhorar sua performance e ser melhor custo eficiente. Podemos classificar os dados da seguinte forma:

• Quente: geralmente é aquele dado instantâneo, que é acessado com freqüência e exige um tempo de resposta em milésimos de segundos, nesse caso o dado pode ser armazenado em um bancos de dados in memory como o Redis ou Cassandra.
• Morno: geralmente é aquele dado que é acessado com uma freqüência média, com um tempo de resposta médio de até 2 segundos, nesse caso o dado pode ser armazenado em um banco de dados convencional como o PostgreSQL, MongoDB ou MySQL.
• Frio: geralmente são dados históricos, raramente são acessados e quando requisitados, o retorno não precisa ser instantâneo, nesse caso o dado pode ser armazenado até mesmo em um servidor de arquivos.

A teoria é bem simples, mas na pratica é algo trabalhoso, pois trás uma complexidade maior para o desenvolvimento, geralmente mudar a temperatura de um dado quente é algo simples, engines como a do Redis expiram esses dados automaticamente por configuração, agora variar para temperatura fria é um desafio, pois essa estratégia de temperatura, precisa respeitar todas as necessidades de negócio.

Como o maior volume de dados acaba saindo do banco de dados convencional, fica muito mais fácil realizar a manutenção desta base, também existem ganhos financeiros, pois os dados frios são enviados para serviços de gerenciamento de arquivos, que geralmente possuem um custo menor e regras de potenciais economia baseadas na freqüência do acesso.

Exemplo prático

Vamos supor que sua empresa possua um aplicativo de entrega de comida, e o seu backend execute no EKS (Serviço gerenciado de Kubernetes da AWS) que ja escala conforme a necessidade, armazena os seus dados numa base MySQL no AWS RDS e utiliza o Elastic Cache com Redis, para armazenar os pedidos ativos por 1 hora.

Esse aplicativo realiza cerca de 20 milhões de pedidos por dia, e isso representa um acréscimo diário 200 GB na base de dados, pensando em uma volumetria mensal, a base desse micro serviço teria cerca de 6 TB no primeiro mês e em 1 ano teria 72 TB de armazenamento.

Lidar com uma base de dados que cresce 6 TB por mês realmente é desafiador para qualquer time de desenvolvimento, mas e se implementássemos uma estratégia de temperatura de dados da seguinte forma:

• Dado Quente: Sempre que um novo pedido for realizado, o dado fica armazenado no Elastic Cache com Redis por 1 hora
• Dado Morno: Sempre que um novo pedido for realizado, o dado fica armazenado no AWS RDS com MySql por 5 dias
• Dado Frio: Sempre que o pedido passar de 5 dias, o dado fica armazenado no S3 por 30 dias, após isso o dado é enviado para o S3 Glacier por 360 dias e depois disso o dado é expurgado

Mesmos com as melhorias de usabilidade, gerar uma estimativa de custos com a calculadora da AWS ainda é complexo, são muitos detalhes e variações que exigem um conhecimento relativamente alto sobre o comportamento do seu produto e sobre os serviços da AWS, mas geralmente os serviços de armazenamento como o RDS estão entre os mais caros da AWS, por isso utilizar o S3 para persistir os dados frios e o usar o modo Glacier para os dados que quase não possuem acesso, pode ser uma oportunidade de redução de custos.

Com isso também vem o ganho técnico, pois ao invés de lidar com uma base que cresce 6 TB ao mês, o time de desenvolvimento teria de lidar com uma base ativa de 6 TB, o que facilitaria a manutenção.

Conclusão

Não importa o tamanho da sua empresa, se o seu produto esta ativo, e dia após dia continua recebendo novos dados, você precisara de uma estratégia de temperatura de dados, não só para oferecer uma melhora experiencia para o seu usuário final, mas também para facilitar a manutenção e fazer com que seu produto seja o melhor custo e eficiente possível.