🏗️ Arquitetura de Dados Moderna

Este documento é um manual técnico de referência para engenheiros de software, arquitetos e cientistas de dados — mas com uma escada didática para que um trainee consiga acompanhar. Cada família é analisada sob a ótica da engenharia real: arquitetura interna, trade-offs, anti-padrões documentados e integração com IA moderna. A versão 2.3 incorpora explicações conceituais com analogias simples, um glossário para iniciantes e contextualização de custo e carga operacional (FinOps).

Como Escolher o Banco de Dados Correto

A escolha não deve ser guiada por hype. É uma decisão arquitetural que impacta latência, throughput, custo operacional, complexidade de código e resiliência a falhas.

Perguntas Fundamentais

1. Qual o formato dos dados? Estruturado (tabelas), semiestruturado (JSON), grafos, séries temporais, vetores densos?
2. Qual o padrão de acesso? Leitura pesada, escrita pesada, balanceado? Consultas pontuais ou analíticas?
3. Qual a latência aceitável? Sub-ms (Redis), ms (PostgreSQL), segundos (BigQuery)?
4. Qual o volume de dados? GB, TB, PB?
5. Qual o modelo de consistência necessário? ACID estrito ou eventual aceitável?
6. Qual a tolerância a falhas? Zero downtime? Recuperação em minutos?
7. Qual o orçamento operacional? Self-hosted, managed cloud, serverless?

Matriz de Decisão

Poliglot Persistence

Prática de usar diferentes tecnologias de armazenamento para diferentes necessidades dentro da mesma aplicação. Um e-commerce moderno pode usar:

• PostgreSQL — pedidos, transações financeiras (ACID)
• Redis — carrinho, sessões, rate limiting
• Elasticsearch — busca de produtos (stemming, relevância)
• Cassandra — eventos de navegação (write-heavy)
• Pinecone — recomendações por similaridade semântica

graph LR
    A[API Gateway] --> B[Pedidos]
    A --> C[Busca]
    A --> D[Recomendação]
    B --> E[(PostgreSQL)]
    B --> F[(Redis)]
    C --> G[(Elasticsearch)]
    D --> H[(Pinecone)]
    B --> I[(Cassandra)]
                

1. Bancos Relacionais — Conceito & Modelo

Organizam dados em tabelas com schema rígido. Baseado na álgebra relacional de Codd (1970). Relações por chaves primárias e estrangeiras, garantindo integridade referencial.

Modelo Mental

Pense em um banco relacional como um conjunto matemático de fatos. Cada linha é uma proposição verdadeira. O SQL é declarativo: você descreve o que quer, o query planner decide como obter.

-- DDL + INSERT: como o dado é armazenado
        CREATE TABLE pedidos (
        id SERIAL PRIMARY KEY,
        cliente_id INTEGER NOT NULL REFERENCES clientes(id),
        valor_total NUMERIC(12,2) NOT NULL,
        status VARCHAR(20) DEFAULT 'pendente',
        criado_em TIMESTAMPTZ DEFAULT now()
        );
        INSERT INTO pedidos (cliente_id, valor_total, status)
        VALUES (42, 299.90, 'confirmado');

Características — ACID, CAP & Escalabilidade

ACID

• Atomicidade: WAL garante tudo ou nada.
• Consistência: Constraints e integridade referencial.
• Isolamento: MVCC (PostgreSQL) ou locks (MySQL).
• Durabilidade: WAL + fsync.

CAP Theorem — Contexto Correto

O teorema CAP aplica-se a sistemas distribuídos com replicação. Um PostgreSQL standalone não está sujeito a partições de rede — não há "P" para tolerar. Já bancos NewSQL como CockroachDB são nativamente CP (consistência + tolerância a partições).

Arquitetura Interna — B-Tree, MVCC & VACUUM

A maioria usa B-Trees como estrutura primária de índice. Cada nó ocupa uma página de disco (8KB no PostgreSQL). MVCC permite leituras não bloqueantes via snapshots. O VACUUM limpa versões obsoletas — falha em executá-lo causa bloat e degradação de performance.

graph TD
    A[Cliente SQL] --> B[Parser]
    B --> C[Query Planner]
    C --> D[Executor]
    D --> E[Storage Engine]
    E --> F[B-Tree Index]
    E --> G[Heap / Table]
    E --> H[WAL Writer]
    H --> I[(Write-Ahead Log)]
                

SQL & Interfaces

-- Window function com cast explícito (evita divisão inteira)
        SELECT categoria, produto, receita,
        RANK() OVER (PARTITION BY categoria ORDER BY receita DESC) AS rank_cat,
        ROUND(receita::numeric / SUM(receita::numeric) OVER (PARTITION BY categoria) * 100, 2) AS pct
        FROM vendas_mensais WHERE data >= '2026-01-01'
        ORDER BY categoria, rank_cat;

Casos de Uso Reais (Validados)

• Stripe: PostgreSQL para transações financeiras. ACID inegociável. Sharding com Citus.
• Instagram: PostgreSQL com sharding lógico customizado (geração de IDs via PL/pgSQL, roteamento na aplicação). Não usam Vitess — Vitess é uma solução para MySQL criada pelo YouTube.
• Uber: MySQL com Schemaless (camada interna de flexibilidade).

Quando NÃO Usar SQL

• Full-text search: Elasticsearch oferece stemming e BM25 nativos.
• Análise de petabytes: ClickHouse/BigQuery superam row-store.
• Schema altamente variável: MongoDB ou Couchbase mais naturais.

Produtos Relevantes

IA & SQL

PostgreSQL + pgvector permite busca por similaridade de cosseno no SQL, mantendo metadados na mesma base — ideal para RAG sem dupla sincronização.

-- Busca semântica com pgvector
        SELECT documento_id, conteudo,
        1 - (embedding <=> query_embedding) AS similaridade
        FROM documentos ORDER BY embedding <=> query_embedding LIMIT 10;

2. Bancos Colunares / OLAP — Conceito & Row vs Column

Armazenam dados por coluna. Em um row-store (OLTP), todos os campos de uma linha ficam juntos na mesma página. Em um column-store (OLAP), cada coluna é armazenada separadamente, permitindo compressão extrema (10-20x) e scans eficientes para agregações.

Visualização: Como o disco enxerga seus dados

Considere uma tabela de vendas com 4 colunas (id, data, categoria, valor) e 3 linhas. Veja como cada arquitetura agrupa os bytes no disco:

graph TB
    subgraph ROW["🗄️ Row-Store (PostgreSQL, MySQL) — agrupado por LINHA"]
        R1["Bloco 1: [1 | 2026-05-12 | audio  | 299.90]"]
        R2["Bloco 2: [2 | 2026-05-12 | video  | 1499.00]"]
        R3["Bloco 3: [3 | 2026-05-13 | audio  | 89.50]"]
        R1 --> R2 --> R3
    end
    subgraph COL["📊 Column-Store (ClickHouse, BigQuery) — agrupado por COLUNA"]
        C1["Bloco id:        [1, 2, 3]"]
        C2["Bloco data:      [2026-05-12, 2026-05-12, 2026-05-13]"]
        C3["Bloco categoria: [audio, video, audio]"]
        C4["Bloco valor:     [299.90, 1499.00, 89.50]"]
        C1 --> C2 --> C3 --> C4
    end
                

-- Query analítica no ClickHouse
        SELECT toStartOfDay(data) AS dia, categoria,
        SUM(receita) AS total, COUNT(DISTINCT usuario_id) AS usuarios
        FROM vendas WHERE data >= today() - 30
        GROUP BY dia, categoria ORDER BY dia DESC, total DESC LIMIT 100;
        -- Column-store lê apenas 4 colunas; row-store leria TODAS as colunas de cada linha.

⚠️ Colunar (OLAP) ≠ Wide-Column (NoSQL)

Casos de Uso

• Cloudflare: ClickHouse para análise de trilhões de eventos/dia.
• Spotify: BigQuery para análise de streaming.
• Capital One: Snowflake como data warehouse corporativo.

Produtos

3. Bancos de Documento — Conceito & Modelo

Armazenam documentos (JSON, BSON). Design orientado a agregados: dados relacionados são embedados, evitando JOINs. Schema flexível por documento.

// Documento MongoDB: dados relacionados embutidos
        db.produtos.insertOne({
        _id: ObjectId("684f1a2b3c4d5e6f7a8b9c0d"),
        nome: "Fone Bluetooth Pro",
        categoria: "áudio",
        preco: NumberDecimal("299.90"),
        variantes: [{ cor: "preto", estoque: 150 }, { cor: "branco", estoque: 80 }],
        avaliacoes: [{ usuario: "ana", nota: 4.5, comentario: "Ótimo som" }]
        });

Características — Tunable Consistency & Sharding

MongoDB moderno (4.0+) não é puramente BASE. Ele oferece consistência configurável (tunable consistency): transações ACID multi-documento, leituras com readConcern: "majority" e escritas com writeConcern: "majority". O modelo permite escolher entre performance e consistência por operação.

O custo real de subir a consistência

"Tunable" não é mágica: cada degrau acima na consistência custa latência. Veja a ordem de grandeza típica em um replica set de 3 nós:

Sharding — Anti-Padrão Documentado

Arquitetura Interna

Storage engine WiredTiger: B-Trees + MVCC + compressão snappy. O oplog registra operações para replicação.

graph TD
    A[Driver] --> B[Mongos Router]
    B --> C[Config Servers]
    B --> D[Shard 1]
    B --> E[Shard 2]
    D --> F[(WiredTiger)]
    E --> G[(WiredTiger)]
                

Queries & APIs

// Aggregation pipeline
        db.vendas.aggregate([
        { $match: { data: { $gte: new Date('2026-04-01') } } },
        { $unwind: '$itens' },
        { $group: { _id: '$itens.categoria', total: { $sum: '$itens.preco' } } },
        { $sort: { total: -1 } }, { $limit: 10 }
        ]);

Casos de Uso Reais

• Adobe: Creative Cloud — metadados de ativos com schema flexível.
• eBay: Catálogo de produtos com milhões de SKUs.
• Coinbase: Dados de exchange com histórico embutido.

Quando NÃO Usar

• Relacionamentos N:N complexos: Use grafo ou relacional.
• Relatórios analíticos pesados: Aggregation pipeline lento vs SQL colunar.

Produtos

4. Bancos Key-Value — Conceito & Modelo

Modelo mais simples: chave → valor. Redis estende com listas, sets, sorted sets, hashes, streams. Latências em microssegundos.

// Redis: estruturas de dados
        SET usuario:42:session "abc123" EX 3600
        LPUSH fila:emails "bem-vindo:joao@exemplo.com"
        ZADD ranking:jogadores 1500 "alice" 1420 "bob"
        HSET produto:789 nome "Teclado" preco 199.90 estoque 45

Características

O event loop principal do Redis é single-threaded — a execução dos comandos acontece em uma única thread, o que garante atomicidade sem precisar de locks e dá previsibilidade de latência. Mas atenção: a partir do Redis 6.0, o I/O de rede (leitura/parsing de bytes do socket e escrita das respostas) pode ser delegado a múltiplas threads via io-threads. Em workloads com muitos clientes concorrentes, isso aumenta o throughput sem quebrar a atomicidade.

Persistência: RDB (snapshots) + AOF (append-only file). Cluster com 16384 hash slots para sharding horizontal.

Arquitetura Interna

Estruturas otimizadas: SDS (strings O(1)), Skip Lists (sorted sets O(log N)), Quicklists, Rax (Radix Tree para streams).

graph LR
    A[Cliente] --> B[Event Loop]
    B --> C{Comando}
    C -->|SET| D[Hash Table]
    C -->|ZADD| E[Skip List]
    D --> F[(RAM)]
                

Casos de Uso

• Twitter: Timeline cache.
• GitHub: Job queues (Sidekiq), rate limiting.
• OpenAI: Rate limiting e cache de API.

Produtos

5. Bancos Wide-Column — Conceito & Modelo

Organizam dados em linhas com row key, mas cada linha pode ter colunas diferentes (modelo esparso). Colunas agrupadas em column families. Otimizado para escritas rápidas e escalabilidade horizontal. Não confundir com bancos colunares (OLAP) — veja a distinção na seção 2.

-- CQL (Cassandra): schema
        CREATE TABLE eventos_usuario (
        usuario_id UUID,
        timestamp TIMESTAMP,
        tipo TEXT,
        payload TEXT,
        PRIMARY KEY (usuario_id, timestamp)
        ) WITH CLUSTERING ORDER BY (timestamp DESC);

Modelagem Query-First — O Paradigma do Wide-Column

Diferentemente do modelo relacional (onde você modela entidades e normaliza), no Cassandra você modela para as queries que vai executar. Isso significa que você pode duplicar dados em múltiplas tabelas para atender a diferentes padrões de acesso. Não há JOINs — cada query deve bater em uma única tabela (ou partição).

-- Mesma informação modelada para DUAS queries diferentes
        -- Tabela 1: posts de um autor (query por autor)
        CREATE TABLE posts_por_autor (
        autor_id UUID,
        data TIMESTAMP,
        titulo TEXT,
        conteudo TEXT,
        PRIMARY KEY (autor_id, data)
        ) WITH CLUSTERING ORDER BY (data DESC);

        -- Tabela 2: posts por tag (query por tag)
        CREATE TABLE posts_por_tag (
        tag TEXT,
        data TIMESTAMP,
        autor_id UUID,
        titulo TEXT,
        PRIMARY KEY (tag, data)
        ) WITH CLUSTERING ORDER BY (data DESC);
        -- Os dados são duplicados. Isso é intencional e necessário no Cassandra.
        -- Tentar "normalizar" aqui seria um anti-padrão.

Arquitetura Interna — LSM Tree, Bloom Filters & Tombstones

Cassandra usa LSM Trees (Log-Structured Merge Trees). Escritas → MemTable (RAM) + Commit Log (WAL). Flush → SSTable imutável. Compaction mergeia SSTables, removendo tombstones (marcadores de deleção).

Bloom Filter: estrutura probabilística em RAM que responde rapidamente se uma chave pode existir em uma SSTable (falso positivo possível, falso negativo não). É como um porteiro com lista de convidados aproximada: se ele diz "não está na lista", tem certeza; se diz "talvez esteja", você precisa confirmar entrando. Reduz I/O drasticamente em consultas pontuais.

graph TD
    A[Write] --> B[Commit Log]
    A --> C[MemTable]
    C -->|Flush| D[(SSTable)]
    E[Read] --> F[Bloom Filter]
    F --> C
    F --> D
                

Casos de Uso Reais

• Netflix: Cassandra para bilhões de eventos de streaming/dia.
• Apple: iCloud — 75.000+ nós gerenciando petabytes.
• Discord: Migrou do Cassandra para ScyllaDB (2022) por problemas de GC da JVM em clusters massivos. Este case é a principal motivação para o ScyllaDB (C++, shard-per-core, latência consistente).

Produtos

6. Bancos de Grafo — Conceito & Modelo

Modelam dados como nós e arestas, ambos com propriedades. O poder está nas consultas de travessia (traversal) — encontrar caminhos, padrões e conexões indiretas.

// Cypher (Neo4j): estrutura e consulta
        CREATE (alice:User {name: 'Alice'})-[:FRIEND {desde: date('2024-01-15')}]->(bob:User {name: 'Bob'});

        -- Amigos de amigos (2º grau) que não são amigos diretos
        MATCH (eu:User {name: 'Alice'})-[:FRIEND]->(amigo)-[:FRIEND]->(amigo2)
        WHERE NOT (eu)-[:FRIEND]->(amigo2) AND eu <> amigo2
        RETURN amigo2.name, COUNT(*) AS conexoes LIMIT 10;

Index-Free Adjacency — O Diferencial dos Grafos

O conceito que diferencia bancos de grafo de relacionais é a index-free adjacency. Em um banco relacional, um JOIN entre usuarios e amizades requer busca em índice (O log N) para cada hop. Em um banco de grafo nativo, cada nó mantém ponteiros físicos diretos para seus vizinhos (arestas). Uma travessia de 3 hops no grafo é O(1) por hop — custo constante, independente do tamanho total do banco.

Mini-aside sobre complexidade: O log N significa "tempo cresce proporcional ao logaritmo do tamanho dos dados" — buscar em 1 bilhão de registros custa ~30 saltos em uma B-Tree. O(1) significa "tempo constante" — não muda com o tamanho. Para 1 hop a diferença é pequena; para 5 hops em grafo gigante, é a diferença entre milissegundos e minutos.

Supernodes — O Calcanhar de Aquiles

Um supernode é um nó com um número extremamente alto de arestas (ex: uma celebridade com milhões de seguidores). Travessias que passam por supernodes degradam performance drasticamente, pois todas as arestas precisam ser avaliadas. Em produção, é comum modelar supernodes com meta-arestas ou limitar a profundidade da travessia.

Casos de Uso

• LinkedIn: Grafo de conexões profissionais — "pessoas que você talvez conheça".
• PayPal: Detecção de fraude via padrões em grafos de transações.
• NASA: Neo4j para dependências entre componentes de engenharia.

Produtos

7. Bancos Time-Series — Conceito & Modelo

Otimizados para dados com timestamp. Operações típicas: inserções sequenciais, consultas por intervalo e agregações temporais.

Retention Policies & Continuous Downsampling

Diferentemente de um colunar comum, TSDBs possuem retention policies (ex: deletar dados brutos após 30 dias) e continuous downsampling — agregação automática de dados antigos em resoluções menores (1s → médias de 1min → médias de 1h).

-- Exemplo InfluxDB (Flux simplificado)
        from(bucket: "metricas")
        |> range(start: -30d)
        |> filter(fn: (r) => r._measurement == "cpu")
        |> aggregateWindow(every: 1h, fn: mean)
        |> yield(name: "cpu_horaria")

Casos de Uso

• Netflix: Atlas (InfluxDB) para 200M+ métricas.
• Uber: M3 para observabilidade de microserviços.
• CERN: InfluxDB para sensores do LHC.

Quando NÃO Usar TSDB

Produtos

8. Bancos de Search — Conceito & Modelo

Elasticsearch: construído sobre Apache Lucene, usa índices invertidos. Relevância via BM25. Índices em shards.

// Elasticsearch: mapeamento e indexação
        PUT /produtos
        { "mappings": { "properties": {
        "nome": { "type": "text", "analyzer": "portuguese" },
        "preco": { "type": "float" },
        "categoria": { "type": "keyword" }
        }}}
        POST /produtos/_doc
        { "nome": "Fone Bluetooth", "preco": 299.90, "categoria": "áudio" }

Casos de Uso

• Uber: Busca de endereços e geocoding.
• Tinder: Matching geo-espacial.
• Wikipedia: Full-text em milhões de artigos.

Produtos

9. Bancos Vetoriais — Conceito & Embeddings

Armazenam e indexam vetores densos (embeddings) de 300 a 4096 dimensões. Algoritmo dominante: HNSW — grafo em múltiplas camadas, busca O(log N) aproximada.

# Embedding + upsert no Pinecone
        from openai import OpenAI
        from pinecone import Pinecone
        emb = OpenAI().embeddings.create(
        model="text-embedding-3-large",
        input="Fone Bluetooth com cancelamento de ruído"
        ).data[0].embedding
        Pinecone().Index("produtos").upsert(
        vectors=[("prod-789", emb, {"nome": "Fone Bluetooth Pro"})]
        )

RAG & IA Generativa

Retrieval-Augmented Generation: chunking → embedding → armazenamento → busca dos K chunks mais similares → injeção no prompt do LLM.

graph LR
    A[Documentos] --> B[Chunking]
    B --> C[Embedding]
    C --> D[(Banco Vetorial)]
    E[Pergunta] --> F[Embedding]
    F --> D
    D --> G[Top-K Chunks]
    G --> H[Prompt]
    H --> I[LLM]
    I --> J[Resposta]
                

Hybrid Search — O Estado da Arte em 2026

Ninguém usa apenas busca vetorial pura em produção. O padrão moderno é hybrid search: combinar resultados de busca vetorial (similaridade semântica) com busca lexical (BM25 / texto pleno) e fundi-los via Reciprocal Rank Fusion (RRF) ou pesos ajustados (weighted scoring).

graph TD
    A[Query do Usuário] --> B[Embedding da Query]
    A --> C[Análise Lexical]
    B --> D[Índice HNSW]
    C --> E[Índice Invertido BM25]
    D --> F[Top-K Vetorial]
    E --> G[Top-K Lexical]
    F --> H[Fusão RRF]
    G --> H
    H --> I[Resultado Final Ranqueado]
                

Bancos como Weaviate e Elasticsearch (8.x+) oferecem hybrid search nativo. O Pinecone recentemente adicionou suporte a sparse vectors para permitir a mesma fusão. Essa combinação captura tanto a intenção semântica quanto a precisão de palavras-chave exatas.

Quando NÃO Usar Banco Vetorial

Produtos

Tabela Comparativa Geral

Agora com duas colunas extras para apoiar decisões de mundo real: 💰 Custo Relativo (TCO típico em escala média — $ barato, $$$$ caro) e 🛠️ Carga Operacional (esforço de setup + manutenção em produção).

Glossário Para o Trainee

Os termos mais densos do material, explicados sem usar mais jargão. Use como referência rápida ao ler outras seções.

Teorema PACELC — Indo Além do CAP

O CAP Theorem só fala sobre o que acontece durante uma partição de rede. Mas, na prática, a maior parte do tempo o sistema não está particionado — e mesmo assim precisa decidir entre latência e consistência. É aí que entra o PACELC, proposto por Daniel Abadi (2010):

Erros Comuns na Escolha de Banco

Tendências 2026

• Hybrid Search como padrão: BM25 + vetor via RRF. Weaviate, ES e Pinecone competem nesse espaço.
• Serverless databases: Neon (PG), Planetscale (MySQL), DynamoDB.
• DuckDB: "SQLite para analytics" — análise local em Parquet/CSV/JSON.
• NewSQL em ascensão: CockroachDB, YugabyteDB — PostgreSQL wire-compatible com consistência distribuída nativa (CP).
• FinOps em bancos vetoriais: Custo de transferência de dados em SaaS (Pinecone) vs self-hosted (pgvector/Qdrant) é fator de decisão crescente.