Tive o prazer de participar da primeira edição do DBA Dev Summit. Palestrei sobre modelagem para bancos de dados NoSQL, e foi uma seção muito legal.

No final da minha palestra, durante as perguntas, nasceu este artigo.

Não lembro das palavras exatas sobre os custos da persistência poliglota, mas era algo como:

• “A persistência poliglota faz as aplicações darem um salto de desempenho, mas aumentam muito os custos. Tem alguma solução pra essa equação?”

Direto do túnel do tempo

Em 2012, Martin Fowler disse que o futuro era da persistência poliglota. E a definição de persistência poliglota é linda:

• “Uma variedade de diferentes tecnologias de armazenamento de dados para diferentes tipos de dados”

Agora me acompanhe no túnel do tempo. Em 2012, quais eram os principais recursos do seu SGBD favorito?

Não pesquisei todas as possibilidades, mas me arrisco a dizer que os SGBDs estavam aptos a tratar somente um modelo de dados com maestria.

E, por isso, fazia total sentido ter um SGBD para cada modelo de dados (key-value, família de colunas, documentos, grafos e os relacionais).

No artigo onde Fowler define a persistência poliglota, ele chama a nossa atenção para o fato de que os altos custos são “compensados” pelos benefícios.

NoSQL não é de graça!

Um dos grandes problemas que eu tenho visto na adoção de bancos de dados NoSQL é a crença de que são gratuitos e a empresa não precisará gastar com nada.

Ao adotar um BD NoSQL usando a versão community, é de extrema importância estar atento ao tipo de licença, para garantir que a sua empresa está fazendo uso correto e dentro da lei.

Além disso, é preciso estar atento aos requisitos de hardware e a necessidade de contratação de mão de obra especializada.

Percebem que começamos a ter custos?

E se eu usar a Nuvem?

Usar a nuvem vai facilitar muito a vida dos times que operam e mantêm seus bancos de dados. Isso tira da empresa a responsabilidade pela infraestrutura e oferece muitas possibilidades de serviços.

Mas se os serviços não forem bem escolhidos e os dados não forem modelados corretamente, a empresa continuará tendo altos custos.

Conheça seu SGBD!

Recentemente eu escrevi um artigo falando do PostgreSQL como banco de dados NoSQL. O MongoDB tem uma storage engine que processa dados em memória, o SQL Server 2019 traz várias novidades para manipulação de dados não relacionais e o MongoDB pode armazenar e consultar grafos.

De 2012 para 2019 muitas coisas mudaram! E hoje temos SGBDs extremamente poderosos e capazes de armazenar e consultar dados de diversos modelos.

E antes que alguém me pergunte, não estou falando de salvar em uma coluna varchar um documento JSON. Estou falando de usar o tipo BSON do PostgreSQL, por exemplo.

Muitos SGBDs manipulam maravilhosamente vários modelos de dados – são multimodelos e têm recursos incríveis!

Então, amigos, antes de sair comprando SGBDs ou contratando serviços, eu lhes convido a conhecer seus respectivos SGBDs (aquele que a sua empresa já usa). Será que ele não tem recursos que podem atender aos seus requisitos?

Conclusão

Não tem mágica. É preciso conhecer os requisitos da sua aplicação, conhecer o formato do seu dado e ver se o seu SGBD manipula da forma esperada este modelo de dados.

Podemos ter persistência poliglota com vários SGBDs diferentes, cada um tratando de um modelo de dados, e isso é lindo!

Mas também podemos ter persistência poliglota usando um único SGBD multimodelo, porque muito mais do que a variedade de tecnologias, o que importa é atender aos requisitos de negócio de forma eficiente e eficaz, respeitando o formato do dado.

Próximos passos

Vou publicar no meu site um check list de modelagem de dados. Se cadastre e receba em primeira mão.