Alura > Cursos de Data Science > Cursos de Engenharia de Dados > Conteúdos de Engenharia de Dados > Primeiras aulas do curso Engenharia de Dados: Bancos NoSQL para Engenheiros - MongoDB, Redis e Cassandra

Engenharia de Dados: Bancos NoSQL para Engenheiros - MongoDB, Redis e Cassandra

Do SQL ao NoSQL: Conceitos Fundamentais e Preparação do Ambiente - Apresentação

Introduzindo o curso de Engenharia de Dados em NoSQL

Olá, bem-vindo ao curso de Engenharia de Dados em NoSQL para Engenheiros, com foco em MongoDB, Redis e Cassandra. Se você está aqui, provavelmente já percebeu que o mundo dos dados mudou completamente. Não estamos mais restritos a um único modelo de dados. Hoje, as aplicações reais combinam múltiplas tecnologias, cada uma escolhida estrategicamente para resolver um tipo específico de problema. E é exatamente isso que faremos neste curso.

Aqui, não vamos estudar NoSQL apenas na teoria. Vamos construir, evoluir e transformar uma aplicação real. Esta aplicação será a Minishop. A Minishop é um pequeno e-commerce que será implementado em uma aplicação em Python de linha de comandos, com uma arquitetura organizada em portas e adaptadores. Não se preocupe, vamos explicar o que isso significa ao longo do curso.

Iniciando a aplicação MiniShop

A aplicação começará de forma muito simples. No início, ela funcionará totalmente em memória: controle de carrinho em memória, controle de sessão em memória, logs em memória, métricas em memória. Ou seja, o sistema funcionará, mas sem persistência real. Quando fechamos a aplicação, tudo se perde. E é aí que começa nossa transformação.

Ao longo das aulas do curso, vamos redesenhar esta aplicação. Não vamos descartá-la; apenas evoluí-la. Vamos substituir, no código Python, partes estratégicas da aplicação que estão em memória por bancos de dados NoSQL. E não usaremos apenas um banco de dados; usaremos três.

Integrando bancos de dados NoSQL

Utilizaremos Redis para controlar as sessões de acesso e o carrinho de compras. MongoDB será usado para controlar o registro de eventos e o histórico de ações do usuário. Quanto ao Cassandra, será utilizado para controlar métricas, contadores e séries temporais.

Cada uma dessas bases será introduzida no momento adequado do curso para resolver um problema específico da arquitetura da aplicação.

Estruturando o curso e aplicando teoria na prática

Como estará estruturado este curso? Primeiro, começaremos instalando nosso ambiente. Instalaremos Python, VS Code e a aplicação MiniShop, que funcionará toda em memória. Depois, a cada duas lições, trabalharemos com uma dessas três bases NoSQL. Inicialmente, faremos um resumo conceitual dessa base NoSQL, entenderemos o modelo de dados, estudaremos nosso caso de uso, integraremos na aplicação dentro do Python o uso desse NoSQL e, finalmente, substituiremos os adaptadores que estão em memória por adaptadores reais. Ou seja, teoria aplicada imediatamente na prática.

Não aprenderemos apenas comandos aqui. Vamos entender quando usar Redis, quando usar MongoDB, quando usar Cassandra, por que misturar bases faz sentido e como manter a arquitetura limpa usando portas e adaptadores, além de como evoluir um sistema sem ter que reescrever toda a aplicação. Este é um curso sobre tecnologia, mas também sobre arquitetura de software.

Explorando a aplicação MiniShop e sua arquitetura

A aplicação MiniShop não é um exemplo artificial. Ela simulará usuários se autenticando, criando o carrinho de compras, gerenciando eventos de navegação, gerando métricas de acesso e contadores de produtos. Assim, veremos claramente por que a sessão se encaixa com Redis, por que os eventos se encaixam com MongoDB, por que gerenciar métricas se encaixa com Cassandra. Nada será aleatório neste curso, tudo é arquitetura.

Concluindo com uma revisão comparativa

Ao final do curso, faremos uma revisão comparativa das três bases de dados. Discutiremos os modelos de dados utilizados, desempenho, consistência, escalabilidade e casos ideais de uso. Terminaremos este curso não apenas sabendo usar as três bases NoSQL, mas também sabendo escolher a base correta para cada problema.

Sejam bem-vindos, obrigado e até o próximo vídeo.

Do SQL ao NoSQL: Conceitos Fundamentais e Preparação do Ambiente - SQL x NoSQL Por que Esse Novo Paradigma Surgiu

Introduzindo o contexto das bases de dados NoSQL

Neste vídeo, vamos entender por que surgiram as bases de dados NoSQL e em que contexto se tornaram necessárias. A ideia aqui não é afirmar que o SQL se tornou obsoleto, mas compreender os limites do modelo relacional quando aplicado a sistemas modernos distribuídos e de grande escala.

Até agora, estamos acostumados a bases de dados relacionais. Essas bases possuem tabelas bem definidas, esquemas rígidos, dados normalizados e relações resolvidas por meio de joins. Este modelo é extremamente potente, confiável e continua sendo essencial em inúmeros cenários, principalmente em sistemas transacionais tradicionais para controlar os processos operativos das empresas.

Explorando os desafios das bases de dados relacionais

O desafio começa quando esses sistemas crescem significativamente. Quando esses sistemas passam a ter um alto volume de acessos simultâneos, grandes quantidades de joins, necessidade de escalar horizontalmente entre diferentes servidores e lidar com dados que mudam de formato com frequência, nos cenários que acabamos de descrever, o custo de manter toda essa consistência inerente da base de dados relacional se torna muito alto e cada vez maior.

Foi nesse contexto que surgiram as bases de dados NoSQL.

Destacando a adoção do NoSQL por grandes empresas

Grandes empresas como Google, Amazon e Facebook começaram a enfrentar problemas que simplesmente não eram resolvidos pelas bases de dados relacionais tradicionais. Imagine, essas empresas precisam lidar com bilhões de registros, sistemas distribuídos globalmente e a necessidade de ter latências extremamente baixas entre as consultas que os usuários fazem à base de dados.

Por isso, é importante deixar algo bem claro. NoSQL não está em oposição ao SQL. NoSQL trata-se de escolher o modelo correto para o problema correto. Em vez de tentar resolver tudo em nossa aplicação com uma única base de dados, começamos a distribuir responsabilidades entre diferentes tecnologias dentro da mesma aplicação.

Apresentando a abordagem prática do curso

Ao longo deste curso, vamos colocar exatamente isso em prática. Vamos usar Redis para dados de acesso rápido, MongoDB para eventos e logs, e Cassandra para métricas e séries temporais. Cada tecnologia será aplicada onde fizer mais sentido, aproveitando, claro, seus pontos fortes.

Portanto, o objetivo deste curso não é memorizar comandos, mas desenvolver um raciocínio arquitetônico. Entender quando usar SQL, quando usar NoSQL e, principalmente, por que fazer essas escolhas. Isso é o que nos guiará nos próximos vídeos.

Obrigado a todos. Até breve.

Do SQL ao NoSQL: Conceitos Fundamentais e Preparação do Ambiente - Tipos de Bancos NoSQL e Casos de Uso Reais

Introduzindo os tipos de bases NoSQL

Neste vídeo, classificaremos os diferentes tipos de bases NoSQL e os associaremos a problemas reais encontrados em sistemas modernos. Em vez de vermos o SQL como uma única categoria, é fundamental entendermos que existem diversos tipos de bases, cada uma mais adequada para um tipo específico de tarefa ou desafio. O objetivo aqui é compreender as diferenças entre esses tipos e ver como bases como Redis, BomDB e Cassandra se encaixam dentro de uma arquitetura moderna, resolvendo problemas reais de forma eficiente.

As bases NoSQL podem ser agrupadas em três grandes categorias: Key-Value, Document e Wide Column. Cada uma dessas categorias foi projetada para atender a necessidades específicas, como certas características próprias de armazenamento e uma forma diferente de acessar os dados. O Key-Value é o modelo mais simples; baseia-se em pares chave-valor, onde a chave é única e o valor pode variar desde um dado simples até uma estrutura complexa. Por outro lado, as bases do tipo Document armazenam dados em documentos semiestruturados, geralmente em formato JSON ou BSON, oferecendo maior flexibilidade para representar informações complexas. Finalmente, o Wide Column: esse tipo de base é orientado a grandes volumes de dados altamente escaláveis, permitindo que cada linha tenha um conjunto variável de colunas, sendo muito usado para dados temporais e métricas.

Explorando as bases Key-Value

Apesar dessas diferenças de arquitetura e modelagem, todos esses tipos compartilham um objetivo comum: foram projetados para processar grandes volumes de dados com eficiência e escalabilidade. Vamos agora enfatizar as bases Key-Value; esses modelos são dos mais simples entre todos os modelos NoSQL e também são os mais eficientes. Redis, por exemplo, é um exemplo clássico desse tipo de base; é extremamente rápido porque opera tudo em memória e é muito utilizado para cache e gestão de sessões. Em vez de consultar uma base relacional a cada requisição, por exemplo, o Redis pode manter em memória os dados mais acessados, permitindo respostas quase instantâneas, o que o torna ideal para controlar sessões de usuários, dados temporais e resultados de consultas que podem ser reutilizados com frequência. Além disso, o Redis é fundamental em cenários onde é necessário baixa latência e alto desempenho. Quando esses dois fatores são críticos, como no controle de acesso ou em aplicações de alto desempenho, o Redis é a melhor base para usar.

Analisando as bases Document

Falemos agora das bases baseadas em documentos, e o MongoDB é seu exemplo mais popular. Ao contrário das bases relacionais que exigem esquemas rígidos, como tabelas bem definidas e relações bem definidas, o MongoDB trabalha com esquemas mais flexíveis.

Armazenamos na base documentos em formato JSON ou BSON, que oferecem alta flexibilidade para estruturar os dados. Esse enfoque, considerado pelo MongoDB, é ideal para dados que chamamos de semi-estruturados ou que evoluem ao longo do tempo. Por exemplo, em um e-commerce, podemos ter produtos com atributos diferentes: alguns têm tamanho, outros têm cor, outros têm desconto, e pode ser necessário adicionar novos atributos aos produtos ao longo do tempo, sem a necessidade de alterar o esquema do banco de dados.

Além disso, o MongoDB se adapta muito bem a dados variados, que não se encaixam em tabelas fixas, como eventos de usuários, logs de aplicações e interações do sistema. É uma excelente opção para cenários onde os dados mudam constantemente.

Discutindo as bases Wide Column

Em relação aos bancos de dados Wide Column, o Cassandra é um de seus principais representantes. Enquanto o MongoDB prioriza a flexibilidade, o Cassandra é projetado para a escala horizontal e para lidar com grandes volumes de dados que normalmente estão distribuídos. O modelo do Cassandra combina tabelas, partições e chaves de clustering, permitindo escritas eficientes e leituras muito rápidas, mesmo quando são realizadas cargas massivas de dados. Por isso, é amplamente utilizado para dados de séries temporais, como métricas de desempenho, acessos a sistemas e logs em tempo real. Em cenários como a monitoração de servidores, onde milhões de registros podem ser gerados por segundo, o Cassandra se destaca por armazenar dados em escala global sem comprometer o desempenho de leitura ou escrita.

Comparando NoSQL com bancos de dados relacionais

Os bancos de dados relacionais têm uma característica muito peculiar: a normalização dos dados e o uso de joins entre múltiplas tabelas. No entanto, esses joins podem se tornar custosos em termos de desempenho quando lidamos com grandes volumes de dados, especialmente em ambientes distribuídos. Além disso, os bancos de dados relacionais têm mais dificuldade para lidar com dados cuja estrutura muda com frequência, como ocorre em cenários típicos de uso do MongoDB.

O NoSQL aborda esses desafios de outra maneira. Esses bancos acabam reduzindo relações complexas e diminuindo a necessidade de consultas em várias tabelas, permitindo armazenar dados de maneira mais direta, otimizando as operações de leitura e escrita para alto desempenho.

Concluindo sobre a escolha do banco de dados

A escolha do banco de dados, então, depende do problema. Ao longo deste vídeo, fica claro que a escolha do banco de dados depende diretamente do problema a ser resolvido. Não existe uma solução única para todos os cenários. Para a necessidade de velocidade extrema, o Redis pode ser uma excelente opção. Quando o foco é a flexibilidade para dados semi-estruturados, é o MongoDB. E para grandes volumes, o Cassandra. No final, a decisão não deve ser guiada por preferências pessoais, mas sim pelas exigências do sistema. Por isso, conhecer os pontos fortes e as limitações de cada tecnologia é fundamental para que possamos construir uma arquitetura eficiente.

Agradecemos a todos, um abraço e até o próximo vídeo.

Sobre o curso Engenharia de Dados: Bancos NoSQL para Engenheiros - MongoDB, Redis e Cassandra

O curso Engenharia de Dados: Bancos NoSQL para Engenheiros - MongoDB, Redis e Cassandra possui 540 minutos de vídeos, em um total de 92 atividades. Gostou? Conheça nossos outros cursos de Engenharia de Dados em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Engenharia de Dados acessando integralmente esse e outros cursos, comece hoje!

Conheça os Planos para Empresas