Documentação Técnica – Modelagem de Dados: SQL, NoSQL, Normalização e Sharding | Banco de Dados

• Documentação Técnica – Modelagem de Dados: SQL, NoSQL, Normalização e Sharding | Banco de Dados

---

Normalização vs Desnormalização

Normalização

• Técnica utilizada em bancos relacionais para reduzir redundância e dependências.
• Consiste em dividir uma tabela grande em tabelas menores interligadas por meio de relacionamentos.
• Facilita a consistência e integridade dos dados.
• Alterações em dados geralmente afetam apenas uma tabela.

• Foco Principal: Integridade, Redundância Mínima (TDD/ACID). • Onde Usar em Fintech: Contas Digitais e Pagamentos Digitais (saldos, transações críticas). É a fonte de verdade. • Prós: Otimiza a escrita, minimiza o risco de inconsistência. • Tecnologias: PostgreSQL, Oracle (Sistemas Transacionais).

Exemplo (SQL):

-- Tabela Produto
produto(id, nome)

-- Tabela ProdutoItem
produto_item(id, produto_id, descricao)

Desnormalização

• Processo reverso da normalização.
• Adiciona redundância intencional para otimizar a leitura dos dados.
• Comum em bancos NoSQL, que priorizam desempenho em leitura e simplicidade.
• Utiliza estrutura embutida em documentos.

• Foco Principal: Performance e Velocidade de Leitura (Escalabilidade). • Onde Usar em Fintech: Históricos, Logs de Transação, Relatórios, e sistemas de Detecção de Fraude. • Prós: Otimiza consultas, essencial para a agilidade no acesso a dados históricos. • Tecnologias: NoSQL ou Tabelas Otimizadas no PostgreSQL (Sistemas Analíticos).

Exemplo (NoSQL):

{
  "_id": "produto_1",
  "nome": "Notebook",
  "itens": [
    { "descricao": "Fonte" },
    { "descricao": "Mouse" }
  ]
}

---

Diferenças entre SQL e NoSQL

Característica	SQL (Relacional)	NoSQL (Orientado a Documentos)
Modelo de Dados	Tabelas (linhas e colunas)	Documentos (geralmente JSON)
Esquema	Fixo, definido previamente	Flexível, dinâmico
Relacionamentos	Joins, chaves primárias e estrangeiras	Dados embutidos ou referenciados
Escalabilidade	Vertical (aumentar recursos do servidor)	Horizontal (sharding, replicação)
Linguagem de Consulta	SQL	MapReduce, APIs REST
Exemplo de Relacionamento	produto e produto_item com foreign key	Documento produto com array de itens

---

Dicas para Modelagem NoSQL

• Modele as entidades e relacionamentos inicialmente como faria em um banco relacional.
• Analise os padrões de acesso e otimize a estrutura dos documentos para leitura eficiente.
• Utilize embutimento quando os dados relacionados forem acessados juntos.
• Use referências quando os dados forem grandes, compartilhados ou modificados independentemente.

---

Padrões de Modelagem NoSQL

Embedded Pattern

• Utilizado quando há uma relação 1:N e os dados “filhos” são sempre acessados junto com o “pai”.

Exemplo:

{
  "_id": "pedido_001",
  "cliente": "João",
  "itens": [
    { "produto": "Mouse", "quantidade": 2 },
    { "produto": "Teclado", "quantidade": 1 }
  ]
}

Referenced Pattern

• Utilizado quando os dados “filhos” são acessados ou modificados independentemente, ou são reutilizados.

Exemplo:

// Documento Pedido
{ "_id": "pedido_002", "cliente": "Maria" }

// Documento Item
{ "_id": "item_77", "pedido_id": "pedido_002", "produto": "Monitor" }

---

Sharding (Particionamento Horizontal)

O que é

• Técnica usada para distribuir dados de um banco muito grande entre diferentes servidores ou instâncias.
• Cada fragmento (shard) contém uma porção do conjunto total de dados.
• Visa melhorar desempenho, escalabilidade e balanceamento de carga.

Como funciona

• Pode particionar os dados com base em:

  • Intervalos de valores (ex: A-M, N-Z)
  • Hash de uma chave (ex: ID do usuário)
  • Localização geográfica, entre outros critérios

Vantagens

• Aumento da escalabilidade e da performance de leitura e escrita.
• Possibilidade de balanceamento de carga.
• Permite manutenção e expansão horizontal (adicionar novos shards).

Desvantagens

• Aumenta a complexidade de gestão.
• Consultas cruzando shards são mais difíceis e custosas.
• Reorganizar shards requer redistribuição de dados.

Exemplo

Antes do sharding (monolítico):

users: [ user1, user2, user3, ..., userN ]

Após sharding (por região):

users_us:    [ usuários dos EUA ]
users_eu:    [ usuários da Europa ]
users_asia:  [ usuários da Ásia ]

---

Modelo CAP

Diagrama no MIRO: 🔗 Clique aqui

---

Sigla	Significado	Descrição Técnica
AP	Availability + Partition Tolerance	Prioriza disponibilidade mesmo durante partições de rede; pode aceitar inconsistência temporária.
CP	Consistency + Partition Tolerance	Prioriza consistência forte; pode recusar requisições para preservar integridade durante partições.
EL	Eventual Consistency	Modelo onde os dados convergem ao estado consistente ao longo do tempo.
EC	Eventual Consistency	Mesmo conceito de EL; variação de nomenclatura.

Banco de Dados	Modelo CAP	Modelo de Dados	Casos de Uso Comuns	Consenso / Replicação	Consistência Forte	Observações
Cassandra	AP / EL	Colunar	Redes sociais, séries temporais, catálogos (Netflix), IoT, saúde, escrita massiva, catálogos globais distribuídos	Quorum	✅	Fórmula quorum: RF / 2 + 1 (ex: RF=10 → 6)
MongoDB	CP / EC	Documento (ACID)	Web/mobile, e-commerce, logs, prototipagem	Raft	✅	WriteConcern / ReadConcern configuráveis
DynamoDB (AWS)	AP / EL	Chave-Valor	Web/mobile alto tráfego, placar, perfis, cliques, carrinho, telemetria	Quorum	✅	Leitura/escrita forte via configuração
CockroachDB	CP / EC	Relacional distribuído (ACID)	Financeiro, inventário global, jogos multi-região, pagamentos, e-commerce	Raft	✅	Modo eventual habilitado recentemente
SpannerDB (Google)	CP / EC	Relacional distribuído (ACID)	Fintechs globais, jogos de alta escala, backends críticos 99.999% SLA	Paxos	✅	TrueTime, relógios atômicos, infra Google
PostgreSQL	CP / EC	Relacional single-node (ACID)	Web, ERP, CMS, e-commerce, sistemas empresariais	WAL Replication	❌	Single-node; HA depende de ferramentas externas
Redis	AP / EL	Chave-Valor	Cache, mensageria, sessão	Sentinel	❌	Pode configurar quorum, mas mantém comportamento AP
Etcd	CP / EC	Chave-Valor	Kubernetes, config management, service discovery	Raft	❌	Totalmente focado em consistência forte
Riak	AP / EL	Chave-Valor	Ad delivery, IoT, logs, alto volume	Quorum	⚠️	Strong Consistency experimental
Neo4j	CP / EC	Grafo	Fraude, recomendação, redes sociais, AML, anomalias	Raft	✅	Pode operar em HA ou modo fortemente consistente
Elasticsearch	CP / EC	Documento	Busca full-text, ELK, análise de logs	Próprio (Quorum-based)	✅	Configuração via wait_for_active_shards
FoundationDB	CP / EC	Chave-Valor transacional distribuído	Metadados em larga escala, bancos customizados, CloudKit	Paxos	❌	CP fim-a-fim; sacrifica disponibilidade
ScyllaDB	AP / EL	Colunar	Time series alta ingestão, gaming, AdTech, migração Cassandra	Raft (metadados)	✅	Tunable consistency; dados continuam AP
Couchbase	CP / EC	Documento	Perfis, e-commerce, jogos online, cache distribuído	Próprio	✅	Alterna entre consistência forte ou alta disponibilidade
YugabyteDB	CP / EC	Relacional distribuído (ACID)	Missão crítica, varejo global, financeiro multi-região, migração Oracle/Postgres	Raft	❌	Não suporta consistência eventual

---