Bancos de Dados Modernos — Guia Técnico Revisado

🗃️

// 01 · Família

Banco de Dados Relacional (SQL)

Organiza dados em tabelas com linhas e colunas, relacionamentos via chaves estrangeiras, garantindo integridade por ACID e SQL padrão.

ACIDSchema rígidoEscala VerticalB-treesWAL

💡 Analogia em 30 segundos

Imagine uma planilha de Excel rigorosamente auditada: cada aba (tabela) tem colunas predefinidas, fórmulas (constraints) que impedem erros, e uma log de alterações (WAL) que garante que nada se perde se o computador desligar no meio da edição.

A decisão de arquitetura: você aceita perder a flexibilidade de schema para ganhar a garantia de que seu dinheiro não será debitado duas vezes?

Como funciona

Armazenamento: B-trees para índices + heaps em páginas. Tamanhos variam por engine: PostgreSQL 8KB (padrão), MySQL InnoDB 16KB, SQLite 4KB (padrão do sistema de arquivos)
Consistência: ACID nativo. WAL garante durabilidade antes de confirmar; MVCC permite leituras consistentes sem bloquear escritas
Distribuição: Single-node nativo; sharding manual ou via Vitess/Citus. Replicação assíncrona (streaming) é padrão; síncrona só em clusters ativos com trade-off de latência
Consulta: Query planner otimiza joins e índices; custo é proporcional à cardinalidade e selectividade
Schema: Rígido por design. ALTER TABLE pode bloquear tabelas grandes em engines antigas; online DDL é feature recente e não universal

-- Exemplo: schema relacional com FK e índice
CREATE TABLE pedidos (
  id SERIAL PRIMARY KEY,
  cliente_id INT REFERENCES clientes(id),
  total DECIMAL(10,2),
  criado_em TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_cliente ON pedidos(cliente_id);

Casos de uso reais

E-commerce: Inventário e pedidos com consistência transacional (evita oversell em flash sales)
Sistemas financeiros: Auditoria, compliance SOX/PCI, movimentações atômicas entre contas
CRM/ERP: Relacionamentos complexos entre clientes, oportunidades e histórico de interações
Payroll/HR: Integridade referencial entre folha, benefícios e contabilidade
SQLite embarcado: Apps mobile/desktop offline-first com zero configuração de servidor

Características

Latência: Tipicamente milissegundos para queries indexadas; latência sobe com lock contention em writes concorrentes ou joins mal otimizados
Throughput: Limitado pela capacidade do nó único; sharding adiciona complexidade de joins cross-shard e consistência distribuída
Linguagem: SQL ANSI + DDL/DML/DCL; stored procedures opcionais (PostgreSQL PL/pgSQL, SQL Server T-SQL)
ORMs: Hibernate, SQLAlchemy, Prisma — cuidado com queries N+1 em lazy loading, que destroem performance em produção

Quando Evitar

Dados altamente desnormalizados (deep object graphs) — N+1 em ORM é difícil de otimizar sem redesign
Escalabilidade horizontal necessária como primeiro requisito — sharding manual é complexo e quebra joins cross-shard
Dados não-estruturados binários grandes — imagens, vídeos, logs brutos (use object store S3/MinIO)
Latência crítica com replicação síncrona entre regiões — WAL sync entre nós é bottleneck de rede
Padrões de acesso imprevisíveis com schema em constante mutação — ALTER TABLE em tabelas grandes pode travar

Casos de Uso com IA

RAG

pgvector em PostgreSQL para similarity queries; JSONB armazena metadados de chunks com índices GIN

Agentes

Source of truth transacional para state persistente; SQL para multi-hop reasoning via joins estruturados

ML Pipelines

Feature stores (Tecton, Feast) usam SQL para data slicing, treino supervisionado e versionamento de features

Observabilidade

Logging estruturado em tabelas; queries históricas para debug de drift de modelo e comparação de versões

📌 O que ninguém te conta

O SQLite está presente em aproximadamente um trilhão de dispositivos — todo smartphone Android, iPhone, navegador Chrome/Firefox, e até smart TVs o usam internamente. É provavelmente o banco de dados mais implantado do mundo, e quase invisível.

Consistência

ACID

Escala

Vertical

Latência

P50 ms

Use Case

Transações complexas

Produtos PostgreSQLMySQL / MariaDBOracleSQL ServerSQLite

📄

// 02 · Família

Banco de Dados de Documentos

Armazena dados como documentos JSON/BSON semi-estruturados. Schema flexível, evolução sem migration, ideal para objetos aninhados e iteração rápida.

BASESchema FlexívelSharding nativoBSONReplica sets

💡 Analogia em 30 segundos

É como uma pasta de arquivos onde cada documento pode ter seu próprio formato: um currículo tem "experiências", outro tem "projetos open source". Não precisa reimprimir toda a pasta porque alguém inventou um novo campo.

A decisão de arquitetura: você precisa iterar no schema mais rápido do que o time consegue fazer migrations de banco?

Como funciona

Armazenamento: BSON em WiredTiger (MongoDB) — engine moderna com B-trees, copy-on-page e compressão; Couchbase usa B-trees com cache integrado (managed cache); Firestore é serverless com replicação multi-região automática
Indexação: Em qualquer campo ou campo aninhado; índices compostos e de array para agregações. MongoDB: índices B-tree; Couchbase: GSI (Global Secondary Indexes)
Distribuição: Sharding via shard key (MongoDB); replica sets automáticos. Couchbase usa XDCR (cross-datacenter replication). Firestore abstrai completamente a infraestrutura
Consistência: BASE por padrão. MongoDB permite tuning via writeConcern/readConcern; Firestore oferece strong consistency por documento
Transações: MongoDB 4.0+ suporta ACID multi-documento em replica sets; 4.2+ em shards. Couchbase oferece ACID em escopo de bucket desde a versão 6.5

// Exemplo: documento JSON aninhado (MongoDB)
{
  "_id": ObjectId("..."),
  "usuario": "ana",
  "endereco": { "cidade": "SP", "uf": "SP" },
  "tags": ["premium", "mobile"]
}

Casos de uso reais

CMS: Posts com nested comments e estrutura mutável sem migration scripts; WordPress moderno usa MySQL, mas headless CMS (Strapi, Sanity) frequentemente usam documentos
Mobile offline-first: Couchbase Sync Gateway replica local/remoto com resolução de conflitos automática
IoT: Sensores variáveis sem schema rígido — novos atributos (firmware, localização) são absorvidos automaticamente
Startups em MVP: Iteração rápida sem ALTER TABLE; campos opcionais não geram colunas NULL
User profiles: Atributos diversos (preferências, consentimentos LGPD) sem dezenas de colunas NULL em tabela relacional

Características

Latência: Tipicamente milissegundos; lookups aninhados podem exigir múltiplas queries se não indexados (evite deep nesting sem necessidade)
Throughput: Alto em write-heavy com sharding bem configurado — a escolha da shard key é a decisão arquitetural mais crítica
Linguagem: JSON-based query; aggregation pipeline (MongoDB); N1QL/SQL++ (Couchbase); queries simples (Firestore)
ODMs: Mongoose (Node), Pydantic ODM (Python), Couchbase SDK. Cuidado com ODMs que mascaram a ausência de joins eficientes

Quando Evitar

Integridade referencial complexa — sem constraints de FK nativas; validação deve ser feita na aplicação ou via schema validation
Transações multi-documento simples e frequentes — SQL ACID nativo é mais direto, maduro e debugável
Dados altamente estruturados e homogêneos — SQL schema é mais eficiente em storage e cache locality
Consultas analíticas complexas com agregações cross-collection — exporte para data warehouse (OLAP)
Relacionamentos muitos-muitos intrincados — SQL JOINs com índices cobertos são mais eficientes

Casos de Uso com IA

RAG

Chunks de texto com embedding em array denso; query por similarity combinada com filtros de metadata em documentos

Agentes

Logs de ações em documentos flexíveis; context retrieval via aggregation pipelines com $lookup

ML Pipelines

Feature stores com schema evolution simples; LanceDB compatível com BSON para embeddings multimodais

Observabilidade

Structured logging em documentos; field flattening para análise downstream em data lake

📌 O que ninguém te conta

O MongoDB nasceu como um componente interno de uma plataforma de cloud computing (10gen) em 2007. A empresa quase falhou porque ninguém queria a plataforma, mas todos queriam o banco de dados. Viraram empresa de banco de dados por acaso.

Consistência

BASE

Escala

Horizontal

Latência

P50 ms

Use Case

Dados flexíveis

Produtos MongoDBCouchbaseFirestoreArangoDB

⚡

// 03 · Família

Banco de Dados Key-Value

Modelo mais simples: chave → valor. Acesso O(1) por hash table. In-memory com latência sub-ms. Ideal para caching, sessions e state efêmero.

In-MemorySub-msHash O(1)Pub/SubSorted Sets

💡 Analogia em 30 segundos

É como um armário de correio: você sabe o número da gaveta (chave), abre e pega o envelope instantaneamente. Não consegue procurar por "cartas com selo azul" — só sabe se abrir uma por uma.

A decisão de arquitetura: você precisa de velocidade absoluta para dados que podem ser reconstruídos se o servidor reiniciar?

Como funciona

Armazenamento: In-memory (Redis) ou disk-backed (RocksDB/LevelDB com LSM trees). Redis usa estruturas de dados em memória; DynamoDB usa LSM em SSD com replicação multi-AZ
Lookup: Hash tables O(1) por chave exata; sem índices secundários nativos (exceto DynamoDB que oferece GSI/LSI, mas com custo de write duplicado)
Durabilidade: Redis usa AOF (append-only file) e RDB snapshots; trade-off velocidade vs segurança. Memcached é puro cache sem persistência
Distribuição: Consistent hashing; Redis Cluster com 16384 slots. DynamoDB é fully managed e abstrai sharding
Consistência: Single-node (Redis): forte (operações atômicas). Cluster: eventual com replicação assíncrona. DynamoDB oferece strong ou eventual por request

# Exemplo: Redis CLI — atomic counter + TTL
INCR rate_limit:ip:192.168.1.1
EXPIRE rate_limit:ip:192.168.1.1 60
ZADD leaderboard 1500 "player_ana"

Casos de uso reais

Session cache: Web apps com failover gracioso (TTL automático expira sessions inativas)
Rate limiting: INCR atômico por IP sem race conditions; janela deslizante via sorted sets
Leaderboards: Sorted sets (Redis) para rankings em tempo real em jogos e gamificação
Pub/Sub: Redis Streams como event queue simples entre microserviços (não substitui Kafka para durabilidade)
Job queues: Resque / Sidekiq / Bull para worker coordination com retry e dead letter

Características

Latência: Sub-ms in-memory (Redis); 10-100× mais lento em disco (RocksDB). Network é frequentemente o bottleneck real, não o banco
Throughput: 100k+ req/s single thread Redis; network bandwidth é o limite antes do CPU
Linguagem: RESP protocol; GET/SET/INCR/LPUSH/SADD + Lua scripting para operações atômicas complexas
HA: Redis Sentinel (failover automático) + RDB/AOF; Redis Cluster para sharding manual

Quando Evitar

Consultas por conteúdo — sem filtros, JOINs ou agregações nativas (exceto DynamoDB que é híbrido)
Persistência crítica — in-memory tem risco de perda em crash antes de snapshot/AOF fsync
Transações complexas multi-key — Redis MULTI/EXEC é limitado; sem rollback automático em falha parcial
Dados maiores que RAM — spill para disco fragmenta performance ou exige cluster com complexidade operacional
Acesso sequencial ao dataset — SCAN/KEYS é O(n) e pode bloquear event loop no Redis single-threaded

Casos de Uso com IA

RAG

Cache de embeddings já processados para evitar recomputação em chamadas repetidas (memoization de embeddings)

Agentes

Session state de conversas; LLM context armazenado em Redis com TTL automático para evitar vazamento de memória

ML Pipelines

Feature caching, embedding cache, versionamento de model artifacts em chaves versionadas

Observabilidade

Contadores de métricas e cálculos de rate em memória; RedisTimeSeries para downsampling de métricas de GPU

📌 O que ninguém te conta

O Redis foi criado por Salvatore Sanfilippo em 2009 para resolver um problema específico de estatísticas em tempo real de um portal italiano. O nome significa REmote DIctionary Server. Ele quase o chamou de "LLOOGG" (o nome do portal).

Consistência

ACID/Evt

Escala

Horizontal

Latência

Sub-ms

Use Case

Cache e sessions

Produtos RedisMemcachedDynamoDBTarantoolDragonfly

📊

// 04 · Família

Wide-Column (Column-Family)

Híbrido entre tabela relacional e key-value. Famílias de colunas por row com timestamp por célula. LSM trees para writes massivos e scale horizontal automático.

LSM TreesColumn FamiliesTunable quorumTimestampsCompaction

💡 Analogia em 30 segundos

É como um arquivo de cartas organizado por remetente e data: todas as cartas de "João" ficam juntas, ordenadas por data. Você nunca altera uma carta antiga — só acrescenta uma nova versão no topo, e o arquivoiro (compaction) remove duplicatas nos fins de semana.

A decisão de arquitetura: você precisa escrever milhões de registros por dia e nunca atualizar o passado?

Como funciona

Modelo: rowKey → {column families} → {columns} → {values, timestamps}. Cada célula é versionada por tempo
Armazenamento: LSM trees (append-only SSTables); compaction em background libera espaço e remove versões antigas
Indexação: Row key é índice primário; índices secundários são limitados ou via Solr/Elasticsearch externos
Distribuição: Sharding automático de row keys via range/hash; tablets/regions distribuídos entre nós
Consistência: Eventual em Cassandra (quorum configurável: ONE, QUORUM, ALL); HBase oferece strong consistency por linha via ZooKeeper coordination

-- Exemplo: CQL Cassandra — row key + clustering column
CREATE TABLE sensor_data (
  sensor_id TEXT,
  event_time TIMESTAMP,
  temperatura DOUBLE,
  PRIMARY KEY (sensor_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

Casos de uso reais

Time-series pesada: Milhões de pontos/dia com row key = sensor + timestamp bucket (ex: dia)
Histórico de mudanças: Versionamento nativo por timestamp de célula (HBase); audit trail automático
Logs em escala: Terabytes com chaveamento por tipo e período; scan eficiente por range
Recomendações: Item-user matrix; scanning por usuário muito rápido com row key designado para acesso pattern
Event datalake: Logs particionados por data; TTL automático para retenção compliance (GDPR/LGPD)

Características

Latência: 10-50ms dependendo do quorum e estado do compaction; leituras pós-compaction são mais rápidas
Throughput: Muito alto em write-optimized; terabytes/dia comuns em produção (Netflix, Apple usam Cassandra)
Linguagem: CQL (Cassandra, similar a SQL); Java API (HBase); Hive/Spark SQL layers para analytics
Tolerância: Perda de N-1 nós com fator de replicação N (Cassandra); HBase depende do HDFS subjacente

Quando Evitar

Transações multi-row — sem ACID cross-row nativo; aplicação deve coordenar via Saga ou compensação
Consultas ad-hoc complexas — requer pré-agregação ou export para Spark; não é para BI exploratório
JOINs — não existem nativamente; denormalizar causa duplicação de dados e complexidade de consistência
Mudanças frequentes de schema — adicionar column family é pesado e pode requerer rebuild de clusters
Dados abaixo de 100GB — overhead de sistema distribuído (gossip, repair, compaction) não se justifica; use PostgreSQL

Casos de Uso com IA

RAG

Event logs em wide-column; retrieval via row scan com timestamps ordenados para reconstruir contexto temporal

Agentes

Interaction history eficiente; scan user interactions por time window para contexto de conversa longa

ML Pipelines

Feature store backend (Feast usa Cassandra/HBase) com valores históricos por timestamp para point-in-time joins

Observabilidade

Métricas time-series em wide-column; scan de janelas para alerting em tempo real e análise de padrões

📌 O que ninguém te conta

O Cassandra foi criado no Facebook em 2008 para resolver a busca de inbox. O nome vem da mitológica Cassandra, que profetizava o futuro mas ninguém acreditava. A piada interna: "Cassandra é ótima para prever o que você quer, mas ninguém acredita que escala tanto."

Consistência

BASE

Escala

Horizontal

Latência

10-50ms

Use Case

Time-series massivo

Produtos Apache CassandraScyllaDBHBaseBigtable

🕸️

// 05 · Família

Banco de Dados em Grafo

Otimizado para relacionamentos. Nós (entidades) + arestas (relacionamentos com propriedades). Acesso via traversal, não JOINs. Ideal para redes, fraude e recomendações.

Cypher / GremlinACID single-nodeTraversalAdjacency listsGraph algorithms

💡 Analogia em 30 segundos

É como um mapa de metrô: as estações são os dados (nós) e os trilhos são os relacionamentos (arestas). Perguntar "quais amigos Ana tem em comum com Bruno" é como traçar rotas — o grafo já sabe os caminhos, não precisa consultar um índice externo.

A decisão de arquitetura: seu problema é sobre quem está conectado a quem, e não sobre o que cada um tem em seu armário?

Como funciona

Modelo: Nodes {properties} + Edges {type, properties}; labeled property graph (Neo4j, ArangoDB) ou RDF triplets {subject, predicate, object}
Armazenamento: Adjacency lists ou triplets; index-free adjacency em Neo4j — cada nó aponta diretamente para seus vizinhos em disco
Indexação: Índices em propriedades de nós + índices de aresta para acesso rápido por tipo de relacionamento
Distribuição: Particionamento vertex-cut/edge-cut; replicação cross-partition é custosa. Distribuição de grafos ainda é problema ativo de pesquisa
Consistência: ACID em single-machine (Neo4j); eventual em distribuído (JanusGraph). ArangoDB oferece cluster com consistency configurável

// Exemplo: Cypher — amigos de amigos (2 hops)
MATCH (ana:User {nome: "Ana"})
()-[:AMIGO*1..2]->(sugestao)
RETURN sugestao.nome, COUNT(*) AS peso
ORDER BY peso DESC

Casos de uso reais

Redes sociais: Mutual friends, recomendações via conexões comuns (2-3 hops). LinkedIn usa grafos para "pessoas que você talvez conheça"
Recomendações: Co-purchases, embeddings de usuário → items via caminhos no grafo (Amazon, Netflix)
Org-chart / Knowledge: Wikipedia links, hierarquias de empresa, taxonomias médicas (SNOMED CT)
Detecção de fraude: Padrões anormais em subgrafos de transações (ciclos, mules, layering)
Identity resolution: Merge de registros duplicados via relacionamentos probabilísticos (ex: mesmo CPF, email similar, endereço próximo)

Características

Latência: Sub-ms para consultas locais (1-2 hops); traversals longos (>5 hops) são custosos O(n^k)
Throughput: Variável; path finding é operação intensiva. Neo4j recomenda read replicas para offload de queries analíticas
Linguagem: Cypher (Neo4j), Gremlin (Apache TinkerPop), SPARQL (RDF/semantic web)
HA: Neo4j causal clustering; read replicas para queries; write em single master

Quando Evitar

Dados sem relacionamentos significativos — tabular puro é mais eficiente em storage e cache
Consultas apenas por atributo — SQL é mais simples sem overhead de graph engine e traversal planning
Escala massiva (bilhões de arestas) — sharding de grafo ainda é imaturo; considere precomputação de caminhos
Atualizações de alta frequência — lock contention em traversals e índices de aresta é difícil de otimizar
Analytics batch massivo — use Spark GraphX ou Giraph para computação offline em escala

Casos de Uso com IA

RAG

Knowledge graphs conectam conceitos; expansão via graph hops e entity linking para enriquecer contexto do LLM

Agentes

State machines como grafos de transições; raciocínio multi-hop em planejamento de ações sequenciais

ML Pipelines

Graph Neural Networks (GNN) treinados em estrutura de grafo (PyTorch Geometric, DGL)

Observabilidade

Trace causality em distributed systems; propagação de erros via edges para root cause analysis

📌 O que ninguém te conta

O algoritmo de "pessoas que você talvez conheça" do LinkedIn originalmente rodava em Hadoop batch e demorava horas. Quando migraram para grafo em tempo real, a latência caiu para milissegundos e a aceitação de conexões aumentou 30%.

Consistência

ACID/Evt

Escala

Complexo

Latência

ms

Use Case

Relacionamentos

Produtos Neo4jArangoDBTigerGraphJanusGraphAmazon Neptune

📈

// 06 · Família

Banco de Dados Time-Series

Otimizado para dados sequenciais com timestamp. Append-only com compressão delta encoding, rollups automáticos, tiering por temperatura dos dados.

Append-onlyDelta encodingRollupsTieringPromQL / InfluxQL

💡 Analogia em 30 segundos

É como uma fita cassete que só grava no final: você nunca rebobina para mudar uma música antiga. Quando a fita enche, você faz uma cópia resumida (rollup) e guarda a original no porão (cold tier).

A decisão de arquitetura: seu dado mais importante é o momento exato em que algo aconteceu, e você nunca muda o passado?

Como funciona

Modelo: (timestamp, metric_name, tags, value); imutável append-only por design. Cada ponto é um evento
Armazenamento: Blocos por time window; delta encoding + RLE para compressão 10:1 típica. TimescaleDB herda páginas do PostgreSQL
Indexação: Timestamp index para range queries; tag indexes para filtros de cardinalidade média. InfluxDB usa TSI (Time Series Index)
Distribuição: Sharding por timestamp ranges; hot/warm/cold tiering automático. Prometheus é single-node; clustering requer Thanos/Cortex
Consistência: Write-once = forte no nó local; imutabilidade elimina race conditions. Varia por produto: TimescaleDB (ACID via PostgreSQL), InfluxDB (write-ahead log, não transacional multi-métrica), Prometheus (local TSDB sem semântica transacional distribuída)

-- Exemplo: PromQL — latência 95th percentil última hora
histogram_quantile(0.95,
rate(http_request_duration_seconds_bucket[1h]))

Casos de uso reais

Infra monitoring: CPU, memory, disk por servidor via Telegraf/Prometheus; alertas baseados em thresholds
APM: Response times e error rates; correlação com deploys (shift left: "o que mudou antes do pico?")
IoT sensores: Temperatura, pressão — compressão é crítica para milhões de dispositivos com banda limitada
Mercado financeiro: Stock prices, crypto trades, order book snapshots; latência de ingestão é prioridade
Retenção: 1 ano high-fidelity + arquivamento em S3 por 7 anos (downsampling automático de 1min → 1h → 1d)

Características

Latência: Alguns ms em write; reads dependem do tier (SSD hot vs HDD cold vs S3 frozen)
Throughput: Centenas de milhares de pontos/segundo por nó em InfluxDB; milhões com clustering
Linguagem: InfluxQL, PromQL, SQL (TimescaleDB), M3 Query. PromQL é funcional e vetorizado
Escala: Horizontal via time-based sharding; novo dia = novo shard natural, sem hot spots de chave

Quando Evitar

Dados não-sequenciais — design assume ordem temporal; chaves aleatórias degradam performance de compressão
Atualizações retroativas — imutabilidade é limitação real; correções exigem reescrita de bloco ou out-of-band annotations
Dados sparse com muitos gaps — Key-Value ou Documento é mais eficiente em storage (menos zeros para comprimir)
Baixa cardinalidade de tags com queries simples — SQL com índice em timestamp resolve com menos overhead
Latência crítica abaixo de 100µs — I/O de storage e network não conseguem garantir consistentemente

Casos de Uso com IA

RAG

Séries temporais de eventos do sistema; retrieval por time windows relevantes para contexto de troubleshooting

Agentes

Historical patterns como context; anomaly detection para alerting proativo antes de falhas

ML Pipelines

Séries como features; forecasting (LSTM, Prophet, ARIMA); backtest em histórico com point-in-time correctness

Observabilidade

Métricas de inference latency e token throughput; correlação com performance de GPU e filas de requisição

📌 O que ninguém te conta

O Prometheus foi criado pelo SoundCloud em 2012 porque as soluções existentes (StatsD + Graphite) não conseguiam escalar com a arquitetura de microserviços. O nome vem do titã da mitologia grega que roubou o fogo dos deuses — apropriado para uma ferramenta que "rouba" métricas de sistemas em produção.

Consistência

Varia*

Escala

Horizontal

Latência

ms

Use Case

Métricas sequenciais

Produtos InfluxDBPrometheusTimescaleDBVictoriaMetricsOpenTSDB

🔍

// 07 · Família

Banco de Dados de Busca

Otimizado para full-text e relevância. Índice invertido mapeia termos → documentos com scoring BM25. Queries fuzzy, booleanas e facetadas.

Inverted IndexBM25 / TF-IDFNear-RTFacetingStemming

💡 Analogia em 30 segundos

É como o índice remissivo de um livro grosso: ao invés de ler página por página procurando "guerra", você olha no índice e vê todas as páginas que contêm a palavra. O índice também diz quais páginas têm a palavra mais vezes (relevância).

A decisão de arquitetura: seus usuários precisam encontrar coisas que eles não sabem exatamente como se chamam?

Como funciona

Modelo: Documentos com campos analisados em posting lists (term → doc_ids + posições + frequência)
Armazenamento: Inverted index comprimido em disco (Lucene segments); doc values para agregações rápidas sem descompressão
Analyzers: Pipeline de tokenização, remoção de stopwords, stemming (reduzir "correndo" → "corr"), lowercasing, sinônimos
Distribuição: Sharding por documentos; índices read-only após flush (Lucene segments imutáveis). Merge de segments é background
Consistência: Near-real-time (refresh lag 1-30s típico); não é imediato após index. Cada shard tem seu próprio refresh cycle

// Exemplo: Elasticsearch Query DSL — busca fuzzy + filtro
{
  "query": {
    "bool": {
      "must": { "match": { "titulo": { "query": "engenharia", "fuzziness": "AUTO" } } },
      "filter": { "term": { "status": "publicado" } }
    }
  }
}

Casos de uso reais

E-commerce: Busca de produtos com filtros (faceted search), autocomplete, typo tolerance ("sapato" → "sapatos")
CMS / Blogs: Busca em posts, comentários, tags com faceted navigation por categoria/autor/data
Documentação: Código-fonte indexado (GitHub search, Stack Overflow); queries com símbolos e operadores
Log analytics: ELK stack (Elasticsearch + Logstash + Kibana); query por field values e patterns em Kibana
Messaging: Busca em histórico de conversas (Discord-style) com highlighting e contexto

Características

Latência: 10-100ms para queries; reindexing é background e lento. Latência de indexing ≠ latência de search
Throughput: Alto em read; writes (indexing) são batch ou near-RT. Bulk API é recomendado para ingestão massiva
Linguagem: JSON Query DSL (Elasticsearch); Lucene Java API; Meilisearch REST simples; Solr query parsers
Relevância: BM25 balanceia term frequency vs field length; tuning por boost de campos e function scores

Quando Evitar

Queries estruturadas apenas com filtros exatos — SQL é mais eficiente sem overhead de scoring e inverted index
Atualizações contínuas de documentos — refresh lag é problema real; cada update é delete + reindex do documento
Alta cardinalidade em facets — memória para agregações explode (cardinality aggregation usa HyperLogLog++ com erro ~2%)
Transações multi-documento — sem ACID; consistência eventual entre shards. Não use como source of truth transacional
Joins complexos — denormalização necessária; mais storage e duplicação. Parent-child é limitado e lento

Casos de Uso com IA

RAG

BM25 retrieval para hybrid dense + sparse search; chunks indexados com scoring de relevância lexical

Agentes

Pesquisa iterativa; tool calls executam queries em corpus indexado informando próxima ação do agente

ML Pipelines

Document classification em corpus indexado; feature extraction de term vectors (TF-IDF) para modelos clássicos

Observabilidade

Latency percentis por tipo de query; investigação de slow logs e shard hotspots via cluster health API

📌 O que ninguém te conta

O Elasticsearch nasceu como "Compass" em 2004, projeto pessoal de Shay Banon para ajudar sua esposa (chef de cozinha) a indexar receitas. Virou empresa (Elastic) e hoje é usado por Netflix, Uber e NASA. A receita de ratatouille provavelmente ainda está em algum shard.

Consistência

Eventual

Escala

Horizontal

Latência

10-100ms

Use Case

Full-text relevância

Produtos ElasticsearchOpenSearchSolrAlgoliaMeilisearch

🧠

// 08 · Família

Banco de Dados Vetorial

Armazena embeddings (representações numéricas de alta dimensão). Busca por similaridade via ANN (HNSW, IVF). Core de RAG, recomendações semânticas e multimodal search.

HNSW / IVFANNk-NNCosine / L2Embeddings

💡 Analogia em 30 segundos

É como um mapa de estrelas: cada estrela é um documento, e a distância entre elas representa similaridade. Quando você pergunta "o que é similar a X?", o telescópio (ANN) aponta para as estrelas vizinhas sem calcular a distância até todas as bilhões de estrelas do universo.

A decisão de arquitetura: você precisa encontrar coisas "parecidas", não coisas "exatamente iguais"?

Como funciona

Modelo: Vetores densos (768–2048 dim, tipicamente float32) + metadata por item; distância (cosine, euclidean, dot product) define similaridade
Indexação: HNSW (grafos navegáveis em camadas) ou IVF (clustering prévio com centroides)
Trade-off: ANN sacrifica recall (~95-99%) por latência sub-linear O(log n). Para 100% recall, use brute-force k-NN (muito mais lento)
Distribuição: Product Quantization reduz memória em ~4×; HNSW é menos paralelizável que IVF. Sharding por hash do vetor ID é comum
Consistência: Append-only com soft deletes (tombstones); rebuild de índice é custoso e pode levar horas em bilhões de vetores

# Exemplo: Python — query de similaridade com metadata filter
import weaviate
client = weaviate.Client("http://localhost:8080")
result = client.query.get("Article", ["title"])
  .with_near_vector({"vector": embedding})
  .with_where({"path": ["category"], "operator": "Equal", "valueText": "tech"})
  .with_limit(5).do()

Casos de uso reais

RAG: Chunks textuais embeddados; k-NN retorna contexto para LLM (top-k=5-10, com reranking opcional)
Recomendações: Item embeddings via collaborative filtering ou content-based (ex: Spotify, Pinterest)
Multimodal: CLIP embeddings em mesmo vector space para texto + imagem (busca "cachorro" em fotos)
Anomaly detection: Outliers distantes do cluster normal em embedding space (fraud, drift)
Autocomplete semântico: Interpretação semântica além de prefix match (ex: "máquina de café" → "espresso maker")

Características

Latência: 10-50ms para k=100; cresce log(n) com HNSW, mas memória é O(n×M) onde M ~ 16-64 conexões por nó
Throughput: 1000s QPS em single shard para k pequeno; batch search (múltiplos vetores por query) é muito mais eficiente
APIs: Pinecone REST, Weaviate GraphQL, Milvus Python SDK, pgvector SQL (via operador `<->`)
Tolerância: Índices reconstruídos de dados imutáveis; backup dos vetores originais é obrigatório (re-embedding é caro)

Quando Evitar

Busca exata por valor — BM25 ou índices B-tree SQL são superiores e deterministicamente corretos
Dados estruturados sem embeddings — SQL filtering é mais rápido, preciso e explicável
Latência crítica abaixo de 5ms — ANN approximation, network overhead e serialização de vetores inviabilizam
Documentos muito longos — chunking obrigatório antes de embedar; perde contexto global e coerência de parágrafo
Sem modelo de embeddings treinado para seu domínio — vetores genéricos (ex: BERT base) podem ter baixa qualidade em domínios técnicos especializados

Casos de Uso com IA

RAG

Core component: embeddings recuperam contexto relevante para geração do LLM (top-k + rerank via cross-encoder)

Agentes

Long-term memory; user context embedido e retrieved entre chamadas (session persistence sem limite de context window)

ML Pipelines

Embedding models como feature extractors; transfer learning via pretrained (BERT, CLIP, Ada-002, E5)

Observabilidade

Embedding drift monitoring via comparação de distribuições (MMD, KL divergence); hallucination detection via context relevance scoring

📌 O que ninguém te conta

O pgvector (extensão PostgreSQL para vetores) foi criado por um único desenvolvedor (Andrew Kane) e se tornou uma das formas mais populares de rodar RAG sem infra extra. Em 2024, a Pinecone (saaS vetorial) ainda não era lucrativa, enquanto milhares de empresas usavam pgvector de graça.

Consistência

Eventual

Escala

Horizontal

Latência

10-50ms

Use Case

Similaridade semântica

Produtos PineconeWeaviateQdrantpgvectorMilvus

🏛️

// 09 · Família

Banco de Dados Colunar / OLAP

Otimizado para leitura analítica massiva. Armazena por coluna com compressão alta (dictionary, bit-packing, RLE). Queries agregam terabytes em segundos via SIMD.

Columnar storage10-100× compressãoSIMD vectorizationZone mapsMVCC snapshots

💡 Analogia em 30 segundos

É como uma planilha onde, ao invés de guardar linha por linha, você guarda coluna por coluna. Se 90% dos valores da coluna "cidade" são "São Paulo", você escreve "São Paulo" uma vez e aponta para ele — economizando espaço e acelerando agregações.

A decisão de arquitetura: você precisa fazer perguntas sobre bilhões de registros que já aconteceram, não sobre o que está acontecendo agora?

Como funciona

Armazenamento: Colunas separadas com dictionary encoding, bit-packing, RLE; valores repetidos comprimem agressivamente. ClickHouse usa MergeTree; DuckDB é in-process
Indexação: Zone maps (min/max por block); sparse indexes; sem B-trees tradicionais. Predicate push-down evita ler blocos irrelevantes
Consulta: Bulk scans com predicate push-down; vetorização SIMD processa milhões de valores por instrução. Paralelismo massivo (MPP)
Distribuição: Sharding por key range; cada shard replica todas as colunas. Snowflake/BigQuery separam storage (S3) de compute
Consistência: Writes em batch; MVCC snapshots; apenas reads consistentes durante query. Não é para transações interativas

-- Exemplo: ClickHouse — agregação por dimensão com filtros
SELECT
   cidade,
   SUM(revenue) AS total,
   AVG(latency) AS lat_media
FROM eventos
WHERE event_date >= '2026-01-01'
GROUP BY cidade
ORDER BY total DESC
LIMIT 100;

Casos de uso reais

BI / Analytics: Histórico de vendas e user behavior; dashboards Tableau/Looker/Metabase/Superset
Data warehouse: Consolidação de múltiplos OLTPs em star/snowflake schema; ETL/ELT pipelines
Log analytics: Status codes e error types em colunas; queries ad-hoc por engenharia sem index tuning
Detecção de fraude: Patterns em transações históricas por user/merchant em janelas longas (últimos 12 meses)
Observabilidade: Traces estruturados em colunas; latência por serviço em granularidade fina com GROUP BY

Características

Latência: Segundos para queries em TBs — batch oriented, não interativo. DuckDB local pode responder em ms para GBs
Throughput: Terabytes/dia em analytics pipeline; ingestão via batch ou stream (Kafka → ClickHouse/Snowflake)
Linguagem: SQL padrão; ClickHouse SQL, Snowflake SQL, BigQuery SQL, DuckDB (compatível com PostgreSQL dialect)
Compressão: 10-100× típico vs OLTP; dictionary values repetidas eliminam redundância. BigQuery cobra por TB scanneado, então compressão = dinheiro

Quando Evitar

Atualizações frequentes de registros — rewrite de coluna inteira é custoso; use OLTP e replique para OLAP
Latência crítica abaixo de 100ms — scan colunar é inerentemente O(n) no pior caso; cache o resultado
Poucas linhas como output — overhead de descompressão colunar não se justifica; SQLite/PostgreSQL resolve
Transações ACID interativas — eventual consistency / snapshot isolation é o padrão. Não use para checkout
Dados abaixo de 100GB — overhead de sistema distribuído desnecessário; DuckDB local ou PostgreSQL resolve

Casos de Uso com IA

RAG

Grandes corpora em warehouse; chunking estratégico para retrieval eficiente em escala (batch embedding + bulk load)

Agentes

Analytics queries como tools; raciocínio sobre dados históricos via SQL gerado pelo LLM (text-to-SQL)

ML Pipelines

Feature engineering em warehouse; Spark atop warehouse para big data training; materialized views como feature tables

Observabilidade

Análise de métricas LLM em warehouse; correlação token throughput/performance por modelo e versão de deployment

📌 O que ninguém te conta

O DuckDB foi criado por pesquisadores holandeses da CWI (mesmo instituto que criou o Python). Ele roda no browser via WebAssembly — você pode analisar gigabytes de dados em uma página web sem servidor. É o "SQLite do analytics".

Consistência

Snapshot

Escala

Horizontal

Latência

Segundos

Use Case

Analytics em escala

Produtos ClickHouseSnowflakeBigQueryRedshiftDuckDB

Bancos de Dados
Modernos

Banco de Dados Relacional (SQL)

Banco de Dados de Documentos

Banco de Dados Key-Value

Wide-Column (Column-Family)

Banco de Dados em Grafo

Banco de Dados Time-Series

Banco de Dados de Busca

Banco de Dados Vetorial

Banco de Dados Colunar / OLAP

Mapa de Decisão Arquitetural

Comparação Resumida

Família	Consistência	Escala	Latência	Throughput Write	Use Case Primário
SQL Relacional	ACID	Vertical	P50 ms	Médio	Transações complexas, CRM, ERP
Documentos	BASE	Horizontal	P50 ms	Alto	Dados flexíveis, IoT, Mobile
Key-Value	ACID/Evt	Horizontal	Sub-ms	Muito alto	Cache, sessions, rate limiting
Wide-Column	BASE	Horizontal	10-50ms	Muito alto	Time-series massivo, event logs
Grafo	ACID/Evt	Complexo	ms	Baixo–Médio	Relacionamentos, fraude, social
Time-Series	Varia*	Horizontal	ms	Muito alto	Monitoring, IoT, finanças
Busca	Eventual	Horizontal	10-100ms	Baixo	Full-text, e-commerce, logs
Vetorial	Eventual	Horizontal	10-50ms	Médio	RAG, recomendações semânticas
Colunar / OLAP	Snapshot	Horizontal	Segundos	Batch	BI, data warehouse, analytics

Bancos de DadosModernos

Banco de Dados Relacional (SQL)

Banco de Dados de Documentos

Banco de Dados Key-Value

Wide-Column (Column-Family)

Banco de Dados em Grafo

Banco de Dados Time-Series

Banco de Dados de Busca

Banco de Dados Vetorial

Banco de Dados Colunar / OLAP

Mapa de Decisão Arquitetural

Comparação Resumida

Bancos de Dados
Modernos