Em 2012, Martin Fowler escreveu que o futuro não era somente NoSQL, mas persistência poliglota. Eu não me canso de ler o documento original, e me assusto cada vez que profissionais com anos e anos de experiência me perguntam se eu acho o MongoDB melhor que o SQL Server.
A primeira coisa que precisamos lembrar é que os BDs relacionais vêm sendo usados há muitos anos e funcionam! O X da questão é que nem sempre eles atendem à todas as necessidades de forma eficiente e eficaz.
Os bancos de dados relacionais armazenam grandes quantidades de dados e as suas estruturas ainda são desenhadas para minimizar o espaço em disco (este é um dos motivos da normalização), para atender todas (ou quase todas) as consultas que são realizadas usando a linguagem SQL.
Nas grandes empresas as informações precisam ser compartilhadas de forma que existam muitas integrações entre os dados. E isso é legal! Porque dessa forma é possível garantir que as aplicações possuam dados consistentes e atualizados.
Aprendemos o modelo relacional na faculdade! E por isso raros são os profissionais (desejo que sejam raros mesmo!) que não conhecem nada da linguagem SQL e do modelo relacional. Acho muita sandice tentar impor um novo padrão – porque felizmente ou não, este é o padrão que temos, e ele não é ruim. Ter uma linguagem “padrão” facilita o aprendizado e mantém “o universo de BD” familiar para a comunidade.
Uma das coisas que eu mais gosto porque acho genial é o controle de concorrência, porque imagina que muitos usuários acessem a mesma informação simultaneamente. Se as aplicações fossem lidar com a concorrência, seria muito complicado! Gerenciar a concorrência é uma das habilidades fofas dos bancos de dados relacionais, e eles fazem isso com as transações.
Sim! Os BDs relacionais são lindos. Mas se não existissem limitações, os NoSQL não existiriam.
Em um cenário onde o volume de dados cresce exponencialmente, os dados têm vários formatos, vêm de muitas fontes e são gerados em uma velocidade nunca vista. Precisam trazer lucro para as organizações e devem ser verdadeiros – é indispensável termos um ambiente elástico, onde podemos incluir mais poder de processamento e armazenamento quando eles forem necessários.
Dimensionar um ambiente para uma empresa não é uma tarefa fácil! Estamos acostumados a dimensionar um tanto a mais, prevendo o crescimento dos dados. Começa que a previsão raramente tem acurácia, e também, ter mais capacidade do que é necessário significa gastar com algo que não traz lucro. A elasticidade do ambiente é uma necessidade econômica!
Definir o termo NoSQL é um desafio, porque eles são bem diferentes entre si, mas o termo começou com um workshop organizado em 2009, e há algumas características comuns:
- Não usam o modelo de dados relacional e, portanto, não usam a linguagem SQL
- Eles tendem a ser projetados para rodar em um cluster
- Normalmente são Open Source
- Não têm um esquema fixo (o que não significa que você não vai precisar modelar os dados – fica a dica)
Por que os BDs NoSQL são legais?
Reduzem o esforço do desenvolvimento
Um grande esforço no desenvolvimento de aplicativos está ligado ao trabalho com bancos de dados relacionais.
Muitas vezes, podemos reduzir esse esforço escolhendo um banco de dados alternativo mais adequado ao domínio do problema.
Quantos projetos já vimos ou participamos onde o BD Relacional é usado apenas por ser o padrão e não porque são a melhor escolha para o trabalho? Muitas vezes pagamos um alto custo no desempenho da aplicação e no desempenho do desenvolvedor simplesmente porque não escolhemos o recurso correto.
Big data não é futuro: é o nosso presente!
Com o processamento e armazenamento em cluster, torna-se mais barato, mais rápido e mais simples processar e armazenar grandes quantidades de dados.
Modelos de dados alternativos também nos permitem realizar muitas tarefas com mais eficiência, permitindo-nos minimizar e até acabar com problemas que teríamos ao usar somente bancos de dados relacionais. Por exemplo: a diferença na estrutura dos dados armazenados no BD e nos objetos da aplicação.
A persistência poliglota
Os bancos de dados relacionais não vão morrer! E nem os bancos de dados NoSQL vão dominar o mundo!
A sacada agora é usar várias tecnologias de armazenamento de dados, escolhidas com base na maneira como os dados estão sendo usados pelas aplicações.
Por que armazenar imagens binárias no banco de dados relacional, quando há sistemas de armazenamento melhores? JSON sendo manipulado em BD relacional? Cópia do BD relacional no banco de dados NoSQL? Esperar integridade referencial em BD NoSQL? O recurso certo para a necessidade certa, esta que precisa ser a visão do arquiteto!
A persistência do poliglota ocorrerá na empresa, pois diferentes aplicativos usam/usarão diferentes tecnologias de armazenamento de dados. Ele também ocorrerá em um único aplicativo, pois diferentes partes do armazenamento de dados de um aplicativo têm características de acesso diferentes (neste caso, pense em microsserviços, por exemplo).
Nem tudo são flores na persistência poliglota
Até este momento, eu espero que você tenha entendido que:
BDs relacionais
- Não morreram
- Não são monstros maldosos
- Devem ser usados no momento certo
BDs NoSQL
- Não são a salvação do mundo
- Processam grandes quantidades de dados
- Devem ser usados no momento certo
Falamos até este momento sobre as facilidades para os times de desenvolvimento, sobre a recuperação dos dados e sobre o armazenamento de grandes volumes.
Precisamos lembrar que um software precisa evoluir (existe deployment), precisa ser monitorado – os dados devem estar seguros (você já leu meus artigos no portal iMasters sobre Lei Geral de Proteção de Dados e GDPR?), usar infraestrutura e governança de dados é uma necessidade. Ou seja, e os times que garantem a operação, como ficam em um cenário de persistência poliglota?
Meus amigos, na minha opinião, este é o maior desafio! Quando optamos por usar um banco de dados relacional, temos ferramentas para auxiliar a operação, temos um schema que “favorece” a governança e temos o conhecimento das equipes.
E no caso dos NoSQL? É preciso avaliar! É preciso analisar e alinhar para garantir que não precisaremos triplicar (ok, estou exagerando um pouquinho) as equipes focadas na operação.
Embora não seja nada definitivo e nem formalmente pesquisado, eu aconselho que durante o processo de análise de viabilidade da persistência poliglota, os seguintes itens sejam avaliados:
1 – Formato do dado
O primeiro critério que deve ser analisado para escolher um ou outro BD NoSQL ou um BD Relacional.
2 – Necessidade de integridade referencial
Amigos… Cuidado ao contar com as aplicações para garantir a integridade referencial.
3 – Versão
A maioria dos bancos NoSQL tem uma versão para a comunidade e uma versão paga. Para escolher entre uma e outra verifique o que elas oferecem… por exemplo: suporte, ferramentas, treinamentos, limite de tamanho do BD, replicação, backup…
4 – Licença
A maior parte dos BDs NoSQL é open source… O que não significa que sejam gratuitos! Verifique se a licença permite que você utilize o banco de dados da maneira que você precisa.
5 – Segurança
Em fevereiro de 2020 entrará em vigor no Brasil a Lei Geral de Proteção de Dados e em maio de 2018 entrou em vigor na Europa a GDPR. Ambas têm em comum a necessidade de proteger dados pessoais. Se a sua empresa for armazenar dados pessoais e sensíveis nos bancos de dados NoSQL, garanta que ele tem mecanismos de segurança para proteger os dados conforme descrito nas leis. (Aguarde meus próximos artigos sobre este assunto.)
6 – Governança
Precisamos conhecer os dados para poder usá-los! Um schema flexível não significa que você deva incluir dados sem nenhum cuidado, porque isso pode ser desastroso para a empresa. Verifique se o seu fluxo de governança de dados precisará ser adaptado para garantir a qualidade dos dados.
7 – Manutenção
Como é a manutenção dos novos bancos de dados? Sua equipe está apta a garantir o funcionamento dos novos servidores? Que ferramentas existem para ajuda-los? Como será feito o backup?
8 – Treinamento
Apesar de todas as dificuldades, se existirem treinamentos focados não só nas equipes de Dev, mas também nas equipes de operação, a jornada será mais tranquila!
9 – Deployment
Quando ocorrerem alterações no ambiente de produção como é feito o deployment? Em quais situações o ambiente precisa estar parado para ser atualizado? Qual tempo médio de downtime? Como são feitas as atualizações?
10 – Drivers
Verifique se o banco de dados possui drivers oficiais para a plataforma de programação que você usa.
11 – Monitoração
Em ambiente de produção é indispensável ser proativo! É preciso monitorar o ambiente a atuar antes dos problemas acontecerem. Verifique se sua equipe conseguirá ser proativa com os novos bancos de dados.
Conclusão
Não tenho autoridade para discordar do Fowler! Também acho que o futuro é da persistência poliglota. Mas acho também, que as soluções adotadas devem ser analisadas de forma integral! Temos que pensar no desenvolvimento das aplicações e na operação delas, de forma que seja possível ter o melhor de cada uma das soluções.
O futuro chegou!
Links úteis
Eu particularmente adoro trabalhar com dados e bancos de dados! Tanto relacionais quanto NoSQL e por isso compartilho conteúdo em alguns outros canais:
- Portal iMasters
- Para desenvolvedores iniciantes eu faço artigos no meu blog
- Para saber mais sobre mim, acesse: DaniMonteiroDBA.com
Durante o ano de 2016 eu publiquei muitos arttigos sobre um banco de dados NoSQL que eu adoro: o MongoDB. Se você quer saber mais sobre o banco de dados NoSQL mais usado no mundo, acesse:
Se você prefere vídeos, fique esperto com as atualizações do meu canal!
E por fim, se você prefere cursos presenciais, não perca a chance de dar um mergulho neste BD! A primeira etapa será em BH, com um mergulho de oito horas! Muita mão na massa sem esquecer os conceitos, porque só assim você vai entender porque sempre digo que MongoDB é vida!
O link para inscrição é: bit.ly/mongodb_bh.
Referências
De 0 a 10, o quanto você recomendaria este artigo para um amigo?