Escrito por: Isocler Teixeira, Head of Architeture
As aplicações atualmente mudam rapidamente, lidam com dados de diversos formatos (texto, imagens, eventos) e precisam escalar. Foi nesse contexto que os bancos NoSQL ganharam espaço: eles não seguem, obrigatoriamente, o modelo tabular dos bancos relacionais e oferecem modelos de dados alternativos para ganhar flexibilidade e escala horizontal.
O que é NoSQL
- Definição: banco de dados que não usa apenas tabelas relacionais. Além disso, pode armazenar documentos JSON/BSON, pares de chave–valor, ou grafos.
- Vantagens típicas: esquemas flexíveis, escala horizontal, consultas rápidas por conta do modelo de dados, e facilidade para desenvolvedores.
- Cada NoSQL tem sua linguagem/forma de consulta tais como: MongoDB usa MQL (MongoDB Query Language) e bancos de grafo como Neo4j usam Cypher.
Mas por que NoSQL ficou popular?
- Agilidade de modelo: você consegue evoluir o schema sem migrações complexas; dá para validar schema quando fizer sentido.
- Escala horizontal: distribui dados em múltiplos nós/regiões para crescer com a demanda.
- Produtividade: documentos se parecem com estruturas de dados das linguagens mais comuns, o que acelera o desenvolvimento.
Fique por dentro das últimas notícias
SQL x NoSQL: quando usar cada um
Use NoSQL quando…
- o modelo varia com frequência (novos campos, documentos heterogêneos);
- precisa de escala horizontal elástica e latência baixa;
- lida com dados semiestruturados (logs, eventos, catálogos, perfis, imagens) e deseja fazer consultas sem se esforçar com joins complexos.
Prefira SQL quando…
- o domínio é altamente estruturado e estável;
- há transações complexas com forte consistência;
- relatórios tradicionais tabulares dominam o consumo.
Contudo uma prática ideal seria: arquiteturas híbridas ou seja, parte relacional para processos transacionais críticos e NoSQL para catálogos, eventos, conteúdos de imagens, personalização …
Casos de uso – Vamos imaginar o Por que e Como aplicar NoSQL
Imagine uma operação de e-commerce de moda onde a cada semana, lançam coleções com pequenas variações, tabelas com medidas específicas, combinações, preços diferenciados por região, campanhas relâmpagos e reviews com fotos de seus clientes.
No dia a dia desse catálogo de moda, a estrutura dos dados não é estática. A cada coleção surgem campos novos, metadados de campanha e relações que não existiam ontem. Em um modelo relacional, cada novidade pede alteração de tabela, validação, novo ajuste no ETL… e o negócio fica refém do ciclo de mudança do banco.
No modelo de documentos (NoSQL), você representa cada produto como um documento JSON enriquecido, que já carrega consigo suas variantes, preços por região, mídias, ranking de popularidade, dentre outras coisas. Se porventura, amanhã você decidir medir “score de afinidade no TikTok”, esse campo nasce no documento, sem derrubar ninguém. O banco acompanha a cadencia do negócio.
Como isso ganha forma no MongoDB
Assim, pense no produto como um documento único, com tudo o que a sua vitrine precisa ler “de uma vez” ou seja, título, descrição, categoria, variações (cor, tamanho, código do produto), preço por região, mídias (imagens, vídeo do produto), reputação do produto (média de reviews), etc .
A página do produto consulta apenas um documento; nada de juntar 5 ou mais tabelas para mostrar o básico. Com isso, ocorre redução na latência e simplifica-se o código. Assim, novos campos podem surgir quando a área de produto/marketing precisar, sem engessar o esquema de dados de quem está desenvolvendo.
E isto vai além de um esquema de dados flexível: pode-se explorar técnicas que o MongoDB oferece. Você ativa o Mongo Atlas Search e indexa campos como título, descrição, tags e atributos, faz fuzzy matching (“vestido vermelo” ~ “vestido vermelho”), e isto sem sair do Mongo – não precisa de um cluster separado só para buscas. Além é claro, de técnicas avançadas com recomendações e similaridade usando busca vetorial. Mas isto, pode ser lido com mais detalhes em outro Artigo que a iblue publicou intitulado “ Text Search x Vector Search no MongoDB: quando usar cada um”.
Conclusão
NoSQL não é “substituto universal” de SQL : é mais uma caixa de ferramentas. Ao escolher o modelo certo para cada parte do seu negócio/aplicação, você ganha agilidade, escala e terá velocidade na entrega. Como no caso de uso acima, se o seu produto precisa absorver mudança constante de requisitos, operar em múltiplas regiões e lidar com dados semiestruturados, vale muito considerar NoSQL, especialmente bancos como o MongoDB.
