NoSQL e dados em larga escala no contexto do Banco do Brasil – Agente de Tecnologia

Fundamentos de NoSQL: por que existe e o que resolve

NoSQL ("Not Only SQL") é um conjunto de modelos de banco de dados projetados para lidar bem com: grande volume de dados, alta taxa de escrita/leitura, baixa latência e flexibilidade de esquema. Em vez de priorizar um modelo único (tabelas e relacionamentos), NoSQL oferece diferentes estruturas de armazenamento, cada uma com pontos fortes e limitações.

Em ambientes bancários digitais, NoSQL aparece com frequência em camadas como: armazenamento de eventos e logs, cache de baixa latência, perfis e preferências de cliente, trilhas de auditoria, telemetria de aplicações, e dados semi-estruturados que mudam com frequência.

Principais modelos NoSQL

1) Documento (Document Store)

Armazena registros como documentos (geralmente JSON/BSON). Cada documento pode ter campos diferentes, permitindo evolução de esquema sem migrações rígidas.

• Quando usar: dados semi-estruturados, agregados naturais (um “objeto” grande), leitura por chave/atributos, necessidade de flexibilidade.
• Exemplos de uso bancário: perfil do cliente (preferências, dispositivos, limites personalizados), cadastro enriquecido com campos opcionais, configurações de app, histórico resumido de interações.
• Trade-offs: joins complexos não são o foco; modelagem tende a duplicar dados para otimizar leitura; consistência e transações podem variar por produto/cluster.

// Exemplo conceitual de documento de perfil (JSON) {  "clienteId": "123",  "nome": "Ana",  "contas": [    {"agencia": "0001", "numero": "12345-6", "tipo": "corrente"}  ],  "preferencias": {"tema": "escuro", "idioma": "pt-BR"},  "dispositivosConfiaveis": ["deviceA", "deviceB"],  "flags": {"optInMarketing": false}}

2) Chave-valor (Key-Value Store)

Modelo mais simples: uma chave única aponta para um valor (string, blob, JSON). É excelente para acesso direto e rápido.

• Quando usar: cache, sessões, tokens, rate limiting, contadores, dados temporários.
• Exemplos de uso bancário: cache de saldo/limites para reduzir carga em sistemas centrais (com cuidado de consistência), sessão do usuário, token de autenticação, controle de tentativas de login.
• Trade-offs: consultas por atributos são limitadas; normalmente você busca pela chave exata.

// Exemplo conceitual: chave -> valor session:cliente:123 -> {"ultimoAcesso":"2026-01-15T10:20:00Z","ip":"..."} otp:cliente:123 -> "839201" tentativas_login:cpf:... -> 2

3) Colunar (Wide-Column / Column-Family)

Armazena dados em famílias de colunas, otimizando leituras e escritas em grande escala, especialmente para séries temporais e dados distribuídos. O “esquema” é mais flexível do que tabelas tradicionais, e o particionamento é parte central do design.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Quando usar: alto volume de escrita, consultas previsíveis por chave de partição, dados de telemetria, eventos, histórico por entidade.
• Exemplos de uso bancário: trilhas de eventos por cliente (eventos do app), métricas de performance, logs estruturados, histórico de transações para análises operacionais (não substitui o sistema transacional principal).
• Trade-offs: modelagem orientada a consultas; joins e ad-hoc queries são limitados; exige cuidado com chave de partição para evitar “hot partitions”.

// Exemplo conceitual de chave de partição para eventos (clienteId, data) PartitionKey: (clienteId=123, dia=2026-01-15) Columns: 10:01 evento=login 10:02 evento=consulta_saldo 10:05 evento=pagamento_pix ...

4) Grafos (Graph Database)

Modela dados como nós (entidades) e arestas (relações), com propriedades. É forte para consultas de relacionamento (caminhos, vizinhança, comunidades).

• Quando usar: relações complexas e mutáveis, exploração de conexões, detecção de padrões.
• Exemplos de uso bancário: detecção de fraude (relações entre contas, dispositivos, IPs, beneficiários), análise de redes de transações, recomendação de próximos passos (ex.: relacionamento entre produtos e perfis).
• Trade-offs: nem sempre é a melhor escolha para agregações simples e relatórios; exige modelagem específica e consultas próprias.

// Exemplo conceitual de grafo (nós e relações) (Cliente:123) -[USA_DISPOSITIVO]-> (Device:A) (Cliente:123) -[TRANSFERE_PARA]-> (Conta:987) (Device:A) -[ACESSA_DE]-> (IP:1.2.3.4)

Quando usar NoSQL vs modelo relacional: critérios e trade-offs

Critérios práticos de escolha

• Formato do dado: se é altamente estruturado e relacional, o relacional tende a ser natural; se é semi-estruturado e evolui rápido, documento pode ser melhor.
• Padrão de acesso: se você precisa de consultas complexas com joins e integridade referencial forte, relacional é forte; se você precisa de leituras por chave e baixa latência, chave-valor é excelente.
• Escala e distribuição: NoSQL costuma facilitar particionamento e replicação horizontal; relacional pode escalar bem, mas frequentemente com mais complexidade para sharding.
• Consistência: relacional tradicionalmente prioriza consistência forte; NoSQL frequentemente oferece opções que incluem consistência eventual para ganhar disponibilidade e performance.
• Transações: se você precisa de transações multi-entidade com garantias rígidas, relacional é o padrão; em NoSQL, depende do produto e do desenho (muitas vezes transações são limitadas ao documento/partição).

Trade-offs típicos (o que cai em prova)

• Flexibilidade vs integridade: documento permite campos variáveis; em troca, validação e integridade podem migrar para a aplicação.
• Desnormalização: em NoSQL é comum duplicar dados para reduzir joins; isso exige estratégia para manter consistência entre cópias.
• Consistência eventual: leituras podem ver dados “antigos” por um curto período após uma escrita, dependendo da configuração.
• Consultas ad-hoc: relacional costuma ser mais forte para consultas arbitrárias; NoSQL frequentemente exige modelar para consultas conhecidas.

Consistência eventual: conceito e leitura prática

Consistência eventual significa que, após uma atualização, diferentes réplicas podem ficar temporariamente divergentes, mas convergem com o tempo. Isso é comum em sistemas distribuídos que priorizam disponibilidade e baixa latência.

Em termos de prova e de prática, pense assim: se uma escrita ocorre em um nó e a replicação para outros nós leva alguns milissegundos/segundos, uma leitura em outra réplica pode retornar o valor anterior nesse intervalo.

Onde faz sentido em casos bancários

• Logs e eventos: se um evento de clique ou telemetria aparecer com atraso, o impacto é baixo.
• Cache: um cache pode estar levemente desatualizado, desde que exista estratégia de expiração/invalidação e o sistema fonte seja o “dado de verdade”.
• Perfis e preferências: mudanças de preferências podem tolerar pequena demora para refletir em todos os pontos.

Onde exige cuidado

• Saldo e movimentação financeira: normalmente requer consistência forte no sistema transacional de origem. NoSQL pode participar como leitura derivada (projeção) ou cache, mas não como fonte única sem garantias adequadas.
• Limites e antifraude em tempo real: decisões críticas podem exigir leitura consistente ou mecanismos adicionais (ex.: checagem no sistema fonte, quorum, bloqueios lógicos).

Particionamento (Sharding) e Replicação: visão conceitual

Particionamento / Sharding

Particionar é dividir os dados em “fatias” (shards) distribuídas em múltiplos nós. O objetivo é escalar horizontalmente: mais nós, mais capacidade.

• Chave de partição: atributo usado para decidir em qual shard o dado fica (ex.: clienteId).
• Risco de hot shard: se muitas requisições caem na mesma chave/intervalo, um shard vira gargalo (ex.: todos os eventos do “cliente mais ativo” ou uma partição por data com pico no dia).
• Estratégias comuns: hash da chave (distribui melhor), partição por intervalo (bom para consultas por período), ou combinação (ex.: clienteId + dia).

Replicação

Replicação é manter cópias dos dados em múltiplos nós para aumentar disponibilidade e tolerância a falhas. Pode ser:

• Síncrona: confirma escrita após gravar em múltiplas réplicas (maior consistência, maior latência).
• Assíncrona: confirma escrita em uma réplica e propaga depois (menor latência, pode gerar consistência eventual).

Em muitos bancos NoSQL, você escolhe níveis de consistência por operação (por exemplo, escrever com quorum e ler com quorum), equilibrando latência e consistência.

Casos de uso bancários digitais conectando NoSQL e dados em larga escala

1) Logs e observabilidade (alto volume de escrita)

Aplicações bancárias geram logs e métricas continuamente. O foco é ingestão rápida, retenção e consulta por período/serviço/cliente (com cuidados de privacidade e compliance).

• Modelo comum: colunar (séries temporais) ou documento (eventos JSON).
• Motivo: alta taxa de escrita e necessidade de escalar horizontalmente.

2) Eventos de negócio (event sourcing / trilhas de eventos)

Eventos como “login”, “iniciou pagamento”, “confirmou transação” podem ser armazenados como registros imutáveis. Isso facilita auditoria, reprocessamento e construção de visões derivadas.

• Modelo comum: documento ou colunar.
• Motivo: dados append-only e consultas por entidade (cliente/conta) e por período.

3) Cache e sessão (baixa latência)

Para reduzir latência e carga em sistemas centrais, usa-se cache para dados frequentemente lidos e com validade curta.

• Modelo comum: chave-valor.
• Cuidados: TTL (expiração), invalidação, e fallback para a fonte de verdade. Evitar tratar cache como registro definitivo.

4) Perfis e preferências (flexibilidade de esquema)

Perfis podem crescer com novos campos (novas features do app, novos sinais de risco, novos dispositivos). Documento costuma ser natural.

• Modelo comum: documento.
• Cuidados: validação de campos, versionamento de esquema, e estratégia para dados duplicados.

Passo a passo prático: comparar modelagem relacional vs documento

Atividade 1 — Modelar “Perfil do cliente + dispositivos”

Cenário: o app precisa exibir rapidamente: dados do cliente, preferências e lista de dispositivos confiáveis. Atualizações de preferências são frequentes; inclusão de novos campos é comum.

Passo a passo (relacional):

• 1) Defina tabelas: Cliente, Preferencia (ou colunas em Cliente), Dispositivo, ClienteDispositivo (associação).
• 2) Defina chaves primárias e estrangeiras para integridade.
• 3) Para montar a tela, planeje a consulta com joins (Cliente + Preferencias + Dispositivos).
• 4) Avalie impacto: joins e múltiplas leituras podem aumentar latência sob alta concorrência.

Passo a passo (documento):

• 1) Defina o agregado: um documento por cliente contendo preferências e dispositivos confiáveis.
• 2) Modele campos opcionais para evolução (ex.: flags, novos atributos de segurança).
• 3) Garanta que a consulta principal seja por clienteId (chave).
• 4) Planeje atualizações: preferências podem ser atualizadas no documento; se dispositivos forem muito grandes, considere separar em coleção própria.

Perguntas para responder:

• Qual modelo reduz mais a quantidade de consultas para montar a tela?
• Onde fica mais simples garantir integridade (ex.: dispositivo não duplicado)?
• Se o número de dispositivos crescer muito, o documento ainda é adequado?

Atividade 2 — Modelar “Eventos do app” (cliques, telas, erros)

Cenário: registrar milhões de eventos por dia, consultar por período e por cliente, e reprocessar eventos para gerar métricas.

Passo a passo (relacional):

• 1) Crie tabela Evento com colunas (clienteId, timestamp, tipo, payload).
• 2) Crie índices por (clienteId, timestamp) e por (timestamp).
• 3) Avalie particionamento por data (se disponível) e retenção.
• 4) Verifique custo de escrita e manutenção de índices em altíssimo volume.

Passo a passo (NoSQL colunar/documento):

• 1) Escolha chave de partição (ex.: clienteId + dia) para distribuir carga.
• 2) Modele o evento como registro append-only (imutável).
• 3) Defina TTL/retention (expiração) conforme política de retenção.
• 4) Planeje consultas principais: por cliente e por intervalo de tempo; evite consultas que varrem todo o cluster.

Perguntas para responder:

• Qual solução lida melhor com escrita massiva?
• Como evitar hot partitions em dias de pico?
• Quais consultas ficam difíceis em NoSQL sem modelagem prévia?

Questões estilo concurso (cenários e características)

1) Identificação do modelo adequado

Enunciado: Um sistema precisa armazenar sessões de usuários com expiração automática e acesso sempre por um identificador único. Qual modelo NoSQL é mais adequado?

• Gabarito esperado: chave-valor (por acesso direto e suporte a TTL em muitos cenários).

2) Consistência eventual

Enunciado: Em um banco NoSQL com replicação assíncrona, uma leitura logo após uma escrita pode retornar o valor anterior. Esse comportamento descreve qual conceito?

• Gabarito esperado: consistência eventual.

3) Sharding e chave de partição

Enunciado: Ao particionar dados por uma chave com baixa cardinalidade (ex.: “tipoEvento”), pode ocorrer concentração de carga em poucos shards. Como se chama esse problema?

• Gabarito esperado: hot partition / hot shard (desbalanceamento de partições).

4) Documento vs relacional (trade-off de joins)

Enunciado: Em bancos de documentos, é comum duplicar dados para evitar joins e otimizar leituras. Qual trade-off isso introduz?

• Gabarito esperado: maior complexidade para manter consistência entre cópias (desnormalização).

5) Grafos em detecção de fraude

Enunciado: Para identificar relações indiretas entre contas, dispositivos e IPs (por exemplo, “contas conectadas por um mesmo dispositivo”), qual modelo tende a ser mais apropriado?

• Gabarito esperado: banco de grafos.

6) Cenário adequado para NoSQL em banco digital

Enunciado: Marque o cenário em que NoSQL é tipicamente mais adequado: (A) escrituração contábil com integridade referencial rígida e transações complexas; (B) armazenamento de logs e eventos em grande volume com consultas por período; (C) conciliação financeira com consistência forte obrigatória.

• Gabarito esperado: (B).