 |
| Bellacosa Mainframe e o misterio de como escolher um banco de dados |
☕
Um Café no Bellacosa MainframeO Dia em que o Arquiteto Entrou no CPD com Oito Bancos de Dados — e o Velho Programador COBOL Perguntou: “Mas Como Você Vai Acessar o Registro?”
Ou: como Db2, PostgreSQL, MongoDB, Redis, Neo4j, Elasticsearch, Time-Series, Data Warehouses, Vector Databases, RAG e uma arquitetura com tecnologia demais descobriram que o banco certo não começa no produto — começa no problema
São 03:17 da manhã.
O telefone toca.
Isso nunca é bom.
Principalmente quando você trabalha com mainframe.
Do outro lado está alguém da aplicação:
— Temos um problema em produção.
O programador COBOL, que já aprendeu que a palavra “problema” pode significar desde um espaço em branco até a paralisação econômica de um pequeno país, pergunta:
— Qual?
— Performance.
— Onde?
Silêncio.
— No banco.
Essa resposta também não ajuda muito.
— Qual banco?
Novo silêncio.
— Bem... temos PostgreSQL, Redis, Elasticsearch, MongoDB e agora colocaram um Vector Database.
O programador olha para o café.
O café olha para o programador.
Em algum lugar distante, um S0C7 sente que finalmente encontrou concorrência.
E então surge a pergunta mais importante desta história:
Por que existem cinco bancos de dados nessa aplicação?
A resposta deveria ser baseada em requisitos.
Mas existe uma possibilidade assustadora:
Porque alguém achou cada um deles interessante.
Bem-vindo ao estranho mundo da arquitetura moderna.
Hoje vamos descobrir por que escolher um banco de dados deveria começar muito antes de escolher o banco.
1. A primeira regra: não escolha o banco
Parece contraditório.
Estamos justamente tentando escolher um database e a primeira recomendação é:
Não escolha o database.
Pelo menos não ainda.
Primeiro descubra o problema.
Essa é a grande ideia da frase:
Pick the problem before the database.
Um erro comum de arquitetura acontece quando começamos pelo produto:
"Vamos usar MongoDB."
"Vamos usar PostgreSQL."
"Precisamos de Redis."
"Precisamos de Kubernetes."
"Precisamos de Vector Database."
A pergunta seguinte deveria ser sempre:
POR QUÊ?
Se a resposta for:
"Porque todo mundo está usando."
Temos um problema.
Se for:
"Porque é moderno."
Temos dois.
Se for:
"Porque IA."
O café deve ser imediatamente reforçado.
😂
Tecnologia não deveria preceder requisito.
2. O programador COBOL já conhecia essa história
Aqui aparece uma curiosidade maravilhosa.
O mundo moderno apresenta bancos especializados como se a humanidade tivesse descoberto ontem que diferentes workloads precisam de estruturas diferentes.
O mainframe conhece essa história há décadas.
Um programador poderia encontrar:
QSAM
VSAM KSDS
VSAM ESDS
VSAM RRDS
IMS
Db2
Por que não guardar tudo exatamente da mesma maneira?
Porque o modo como os dados são acessados importa.
Imagine um arquivo VSAM KSDS.
Temos uma chave:
00012345 → REGISTRO DO CLIENTE
Não estou dizendo que VSAM é Redis — são tecnologias, arquiteturas e épocas completamente diferentes.
Mas pedagogicamente existe uma ideia em comum:
Se eu conheço a chave, consigo encontrar aquilo que quero.
Agora imagine IMS.
A navegação hierárquica determina profundamente como pensamos sobre os dados.
Depois temos o modelo relacional.
Em vez de dizer:
Vá até este registro, depois siga aquele ponteiro...
podemos declarar aquilo que queremos:
SELECT NOME,
SALDO
FROM CLIENTE
WHERE CPF = :WS-CPF;
Mudou o paradigma.
Mas a pergunta fundamental continuou viva:
Como esses dados serão utilizados?
3. Antes do database existe o workload
Essa palavra merece morar permanentemente na cabeça de quem projeta sistemas:
WORKLOAD
Não pergunte apenas:
Quantos terabytes temos?
Pergunte:
Quantas leituras?
Quantas escritas?
Qual tamanho médio?
Quais consultas?
Qual concorrência?
Qual latência?
Precisamos de transações?
Precisamos de joins?
Precisamos pesquisar texto?
Precisamos percorrer relacionamentos?
Precisamos analisar bilhões de registros?
Precisamos consultar séries temporais?
Precisamos encontrar similaridade semântica?
Perceba algo interessante.
O volume sozinho não determina a tecnologia.
Um banco com 20 TB acessado predominantemente por chave pode representar um problema completamente diferente de outro banco de 20 TB utilizado para agregações analíticas.
O tamanho é igual.
O workload não.
4. Access Pattern — a pergunta que sobreviveu a todas as revoluções
Se eu pudesse acrescentar apenas uma caixa ao infográfico original, escreveria:
ACCESS PATTERN
Ou:
Como você vai procurar esses dados?
Considere uma entidade chamada CLIENTE.
Temos:
CLIENTE
-------
ID
CPF
NOME
EMAIL
ENDERECO
Parece um problema relacional perfeitamente comum.
Mas alguém pergunta:
Quero encontrar o cliente pelo CPF.
Um índice resolve elegantemente.
Outra pessoa pergunta:
Quero descobrir clientes relacionados por endereço, telefone, empresas, sócios e transações.
Agora os relacionamentos passaram para o centro do problema.
Outra:
Quero pesquisar reclamações semanticamente semelhantes feitas pelos clientes.
Entramos no território de embeddings e vetores.
Outra:
Quero analisar o comportamento desses clientes durante os últimos cinco anos.
Analytics.
Outra:
Quero descobrir quantas tentativas de login ocorreram por segundo.
Time-series.
Os clientes continuam sendo clientes.
O que mudou?
O padrão de acesso.
5. Relational Database — o velho guerreiro que se recusa a morrer
De tempos em tempos alguém anuncia:
SQL morreu.
SQL provavelmente já morreu mais vezes do que personagem de história em quadrinhos.
E continua trabalhando.
Bancos relacionais são particularmente fortes quando temos:
estrutura
relacionamentos bem definidos
integridade
transações
joins
consistência
Aqui encontramos PostgreSQL, MySQL, SQL Server, Oracle e, naturalmente para nossa história:
Db2.
A documentação da IBM define Db2 for z/OS como um sistema gerenciador de banco de dados relacional para IBM Z, com dados logicamente organizados em tabelas e mecanismos de integridade como constraints e triggers. (IBM)
Imagine uma transferência bancária:
CONTA A - R$ 1.000
CONTA B + R$ 1.000
Não queremos:
UPDATE CONTA A
↓
menos R$ 1.000
ABEND
CONTA B
↓
¯\_(ツ)_/¯
Queremos uma transação.
Em pseudo-COBOL:
EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - :WS-VALOR
WHERE NUMERO = :WS-CONTA-ORIGEM
END-EXEC.
EXEC SQL
UPDATE CONTA
SET SALDO = SALDO + :WS-VALOR
WHERE NUMERO = :WS-CONTA-DESTINO
END-EXEC.
EXEC SQL
COMMIT
END-EXEC.
Se algo der errado:
ROLLBACK
Isso não é frescura acadêmica.
É a diferença entre processamento financeiro e transformar a contabilidade numa experiência de RPG.
6. ACID — quatro letras que salvam noites de sono
Quando falamos em transações, encontramos:
A — Atomicity
C — Consistency
I — Isolation
D — Durability
Atomicidade
Ou tudo acontece ou nada acontece.
Consistência
As regras do banco continuam válidas.
Isolamento
Transações concorrentes não deveriam produzir estados absurdos.
Durabilidade
Depois do COMMIT, esperamos que aquilo continue existindo mesmo diante de falhas.
Essas propriedades ajudam a explicar por que bancos relacionais continuam tão importantes em sistemas críticos.
O PostgreSQL, por exemplo, utiliza MVCC — Multi-Version Concurrency Control — para fornecer snapshots consistentes às transações e controlar concorrência. (PostgreSQL)
Para quem trabalha com Db2, locks, isolation levels, COMMIT e ROLLBACK, nada disso parece ficção científica.
7. Document Database — quando cada registro quer ser diferente
Agora imagine uma loja.
Vendemos computadores:
{
"produto": "Notebook",
"ram": "32GB",
"cpu": "8 cores"
}
Mas também camisetas:
{
"produto": "Camiseta",
"tamanho": "G",
"tecido": "algodao"
}
E livros:
{
"produto": "Livro",
"autor": "Fulano",
"isbn": "123456"
}
Tentar representar milhares de categorias extremamente diferentes em um esquema relacional rígido pode aumentar bastante a complexidade do modelo.
Document databases podem encaixar-se muito bem aqui.
MongoDB trabalha justamente com documentos e coleções e permite modelagem por embedding e referências entre documentos. (MongoDB University)
Mas cuidado com uma frase perigosa:
“MongoDB não precisa de schema.”
A conclusão errada seria:
“Então posso jogar qualquer coisa lá.”
Não.
Flexibilidade de schema não significa ausência de modelagem.
Se você não organizar seus dados, terá apenas transferido o problema do banco para a aplicação.
8. Key-Value — a filosofia do armário numerado
Agora imagine um enorme guarda-volumes.
Você entrega:
CHAVE = 871923
Ele devolve:
VALOR
Essa é a essência conceitual de um key-value store.
Redis explica esse modelo justamente como pares chave-valor, onde uma chave única identifica um valor. Essa simplicidade favorece operações extremamente rápidas de acesso direto. (Redis)
Casos clássicos:
CACHE:CLIENTE:123
SESSION:987321
CARRINHO:USER:761
TOKEN:ABC123
RATE:API:USER42
Queremos:
CHAVE → VALOR
e queremos isso rápido.
Redis é maravilhoso nesse território.
Mas então alguém decide armazenar o ERP inteiro nele.
E seis meses depois pergunta:
Como faço quinze joins?
É o equivalente arquitetural de comprar uma Ferrari e reclamar que ela transporta poucos sacos de cimento.
A tecnologia não está errada.
O problema escolhido para ela está.
9. Graph Database — Sherlock Holmes entra no CPD
Agora imagine investigação de fraude.
Temos:
JOÃO
|
possui
|
CONTA A
|
transferiu
|
CONTA B
|
pertence
|
MARIA
|
mora
|
ENDEREÇO X
|
também usado por
|
CARLOS
A pergunta deixa de ser:
Qual é o saldo?
Passa a ser:
Quem está relacionado a quem e através de quais caminhos?
Isso é terreno natural de grafos.
Neo4j representa informações usando nodes, relationships e properties, colocando explicitamente as relações no modelo. (Neo4j Graph Intelligence Platform)
Isso pode ser poderoso para:
fraude
redes sociais
recomendações
dependências
rotas
knowledge graphs
supply chains
Podemos modelar relações em SQL?
Claro.
Essa nunca foi a pergunta.
A pergunta correta é:
Qual modelo torna o workload mais natural e eficiente?
10. Search Database — quando LIKE começa a pedir socorro
Imagine milhões de documentos.
O usuário procura:
falha autenticação usuário produção
Queremos considerar:
relevância
termos
variações
ranking
documentos
campos
filtros
Aí aparece aquele SQL:
WHERE TEXTO LIKE '%falha%'
OR TEXTO LIKE '%autenticacao%'
OR TEXTO LIKE '%login%'
OR TEXTO LIKE '%usuario%'
Em algum lugar, um DBA sente uma perturbação na Força.
Search engines como Elasticsearch foram criados justamente para workloads de pesquisa e indexação.
Mas aqui começa algo extremamente interessante.
As caixas do nosso infográfico já não possuem paredes tão rígidas.
Elasticsearch atualmente também suporta armazenamento de embeddings e pesquisa vetorial, combinando similaridade vetorial com full-text search, filtros e agregações. (Elastic)
Guarde isso.
Voltaremos ao assunto.
11. Time-Series — quando o relógio passa a fazer parte do dado
Imagine o monitoramento:
03:00 CPU 31%
03:01 CPU 34%
03:02 CPU 47%
03:03 CPU 72%
03:04 CPU 94%
03:05 CPU 99%
O tempo não é simplesmente mais uma coluna.
Ele é parte essencial da pergunta.
Queremos coisas como:
média nos últimos 10 minutos
pico nas últimas 24 horas
crescimento por hora
eventos entre T1 e T2
agregação por janela
Encontramos isso em:
IoT
sensores
observabilidade
mercado financeiro
telemetria
monitoramento
métricas
E aqui está uma distinção importante.
Ter uma coluna:
TIMESTAMP
não transforma automaticamente seu sistema em um problema de time-series.
Novamente:
workload.
12. Data Warehouse — o executivo quer cinco anos em cinco segundos
Temos então outra criatura.
O sistema operacional responde:
Qual é o saldo desta conta?
Analytics pergunta:
Qual foi o comportamento médio dos clientes entre 35 e 50 anos, separados por região, produto, mês e canal nos últimos cinco anos?
São problemas profundamente diferentes.
Temos a clássica distinção:
OLTP
versus
OLAP
OLTP
Muitas operações pequenas:
INSERT
UPDATE
DELETE
SELECT
COMMIT
OLAP
Grandes leituras e agregações:
SUM
AVG
GROUP BY
histórico
bilhões de registros
Uma metáfora:
OLTP procura rapidamente uma agulha.
OLAP examina o palheiro inteiro para explicar por que existem tantas agulhas.
É por isso que Data Warehouses e bancos analíticos existem.
E o próprio universo IBM Z hoje convive com esse modelo híbrido: a IBM posiciona Db2 for z/OS tanto como sistema de dados empresariais quanto como fonte integrada a analytics, data lakehouses e IA. (IBM)
13. Então chegou a IA carregando vetores
E finalmente chegamos à celebridade da festa:
Vector Database.
Primeiro precisamos entender embeddings.
Imagine:
"COBOL no mainframe"
transformado matematicamente em algo parecido com:
[0.127, -0.332, 0.819, ...]
Outro texto:
"programação de sistemas legados IBM Z"
também recebe uma representação vetorial.
O objetivo é possibilitar comparações matemáticas de proximidade entre representações.
Assim conseguimos fazer:
semantic search
similarity search
recommendations
RAG
Em vez de perguntar:
Contém exatamente esta palavra?
podemos perguntar:
Qual conteúdo possui significado semelhante?
Essa mudança é gigantesca.
14. RAG entra no CPD
Imagine milhares de manuais internos:
COBOL
CICS
Db2
RACF
JCL
MQ
z/OS
O usuário pergunta:
Como investigar determinado SQLCODE?
Em uma arquitetura RAG simplificada:
PERGUNTA
|
v
EMBEDDING
|
v
BUSCA VETORIAL
|
v
DOCUMENTOS RELEVANTES
|
v
LLM
|
v
RESPOSTA
Mas existe uma pegadinha.
Alguém imediatamente conclui:
Precisamos comprar um Vector Database!
Talvez.
Talvez não.
O pgvector, por exemplo, adiciona busca de similaridade vetorial ao PostgreSQL, incluindo distâncias como cosine, inner product e L2, além de índices HNSW e IVFFlat. (GitHub)
Elasticsearch também oferece pesquisa vetorial. (Elastic)
Portanto:
RAG
não implica automaticamente:
NOVO DATABASE
Essa é uma das lições mais importantes deste artigo.
15. O grande truque: as categorias estão convergindo
Nos antigos diagramas, colocávamos cada tecnologia numa caixa:
SQL
Document
Key-Value
Graph
Search
Time-Series
Analytics
Vector
Mas o mundo real está borrando essas fronteiras.
Um produto pode oferecer múltiplas capacidades.
Isso muda a pergunta.
Antes:
Qual banco implementa essa funcionalidade?
Agora também precisamos perguntar:
Meu banco atual já oferece capacidade suficiente para esse workload?
Porque cada tecnologia nova traz uma mochila operacional.
16. Polyglot Persistence — a guilda dos oito databases
Existe uma filosofia perfeitamente legítima chamada polyglot persistence.
A ideia:
Diferentes workloads podem utilizar diferentes mecanismos de persistência.
Imagine:
APLICAÇÃO
|
+----------------+----------------+
| | |
Db2 Redis Elasticsearch
| | |
OLTP Cache Search
|
+---------- Warehouse
|
+---------- Analytics
|
+---------- AI / RAG
Isso pode ser excelente.
Db2 guarda o sistema oficial de registro.
Redis acelera cache.
Elasticsearch fornece pesquisa.
Warehouse executa analytics.
Vector search atende recuperação semântica.
Graph investiga relações.
Perfeito.
Até alguém perguntar:
Quem administra tudo isso?
Silêncio.
17. Cada database adicional invoca novos monstros
Toda nova tecnologia traz consigo:
instalação
configuração
monitoramento
backup
restore
replicação
segurança
patching
upgrade
capacity planning
disaster recovery
skills
licenciamento
governança
auditoria
integração
observabilidade
Então chegamos à pergunta que deveria aparecer depois de todas as caixas do infográfico:
Precisamos realmente de outro database?
Se PostgreSQL com pgvector atende ao requisito, talvez não seja necessário adicionar outra plataforma exclusivamente para vetores.
Se Elasticsearch já existe e satisfaz o requisito de busca híbrida, talvez possamos aproveitá-lo.
Se Db2 resolve perfeitamente o workload transacional, não precisamos substituir tecnologia apenas porque surgiu algo mais elegante em uma conferência.
Arquitetura não é Pokémon.
Você não precisa capturar todos.
😂
18. CAP — quando a rede resolve participar da reunião
Quando distribuímos dados, outro problema aparece.
O famoso CAP:
Consistency
Availability
Partition tolerance
Existe uma explicação popular dizendo:
Escolha dois.
É útil como introdução, mas simplifica demais.
O ponto interessante aparece durante uma partição de rede.
Nesse cenário, sistemas distribuídos precisam lidar com trade-offs entre consistência e disponibilidade.
E então aparece uma expressão capaz de causar pequenos espasmos em programadores bancários:
Eventual Consistency.
O velho COBOLzeiro pergunta:
— O saldo está correto?
— Eventualmente.
— Eventualmente quando?
— Eventualmente.
— Chame o gerente.
😂
Eventual consistency não é ruim.
Ela pode ser perfeitamente apropriada.
Um contador de curtidas numa rede social não precisa necessariamente das mesmas garantias de uma transferência financeira.
Eis novamente nossa palavra mágica:
contexto.
19. Consistência não possui o mesmo preço em todo lugar
Imagine:
LIKES = 10.431
Durante alguns milissegundos outro usuário vê:
LIKES = 10.430
Provavelmente ninguém morrerá.
Agora:
SALDO = R$ 100.000
Um servidor acredita nisso.
Outro pensa:
SALDO = R$ 10
Temos uma reunião.
Possivelmente várias.
Portanto não existe uma única política correta de consistência para todos os sistemas.
Existe a consistência adequada ao negócio.
20. O segredo que o velho programador conhecia
Voltemos ao nosso veterano.
Ele olha para a arquitetura:
PostgreSQL
MongoDB
Redis
Neo4j
Elasticsearch
Timescale
Warehouse
Vector Database
e pergunta:
— Como vocês acessam os dados?
O jovem arquiteto começa a explicar Kubernetes, microservices, cloud-native, embeddings, service mesh...
— Não. Como vocês acessam os dados?
Silêncio.
Eis o easter egg desta história.
Essa pergunta poderia ter sido feita em 1975.
Ou 1985.
Ou 1995.
Ou 2026.
Porque tecnologia muda violentamente.
Mas determinados princípios de engenharia sobrevivem.
21. A árvore Bellacosa de escolha do database
Se eu estivesse ensinando isso a um programador COBOL iniciante, começaria assim:
QUAL É O PROBLEMA?
|
+--- Transações?
| |
| +--> RELATIONAL
|
+--- Documentos variáveis?
| |
| +--> DOCUMENT
|
+--- Busca extremamente rápida por chave?
| |
| +--> KEY-VALUE
|
+--- Relações são o problema?
| |
| +--> GRAPH
|
+--- Pesquisa textual?
| |
| +--> SEARCH
|
+--- Tempo domina o workload?
| |
| +--> TIME-SERIES
|
+--- Analytics massivo?
| |
| +--> WAREHOUSE / OLAP
|
+--- Similaridade semântica?
|
+--> VECTOR
Mas eu acrescentaria:
|
v
A TECNOLOGIA ATUAL
JÁ CONSEGUE FAZER?
/ \
SIM NÃO
| |
v v
INVESTIGUE AVALIE
PRIMEIRO NOVA TECH
Isso evita muita arquitetura desnecessária.
22. Depois escolha o produto
Somente agora começamos a discutir nomes.
Não antes.
Pergunte:
Qual throughput?
Qual latência?
Qual volume?
Qual crescimento?
Qual disponibilidade?
Qual RTO?
Qual RPO?
Qual segurança?
Qual compliance?
Qual custo?
Qual conhecimento da equipe?
Qual estratégia de backup?
Qual recuperação?
Qual suporte?
Qual lock-in?
Qual observabilidade?
E talvez a pergunta mais negligenciada:
Quem vai manter isso às 03:17?
Porque a arquitetura desenhada às 14:00 numa apresentação colorida será administrada por alguém durante um incidente.
Essa pessoa merece consideração.
23. O banco mais rápido pode ser a escolha mais lenta
Imagine que determinada tecnologia reduz uma consulta:
100 ms → 10 ms
Fantástico.
Mas para isso precisamos contratar especialistas, criar infraestrutura, replicação, monitoramento, backup, pipelines e sincronização.
Talvez economizemos:
90 ms
e gastemos:
R$ 2 milhões
+ 4 especialistas
+ 3 servidores
+ 2 ferramentas
+ 1 plantonista revoltado
Performance técnica não é o único componente da eficiência arquitetural.
Existe também:
complexidade.
24. O conceito de System of Record
Em arquiteturas híbridas existe outra pergunta fundamental:
Quem é dono da verdade?
Imagine:
Db2
Redis
Elasticsearch
Warehouse
Vector Store
O saldo aparece diferente em dois deles.
Qual vale?
Precisamos saber claramente qual é o:
System of Record.
Em muitos ambientes corporativos, sistemas transacionais em Db2 continuam exercendo exatamente esse papel. A IBM descreve Db2 for z/OS como plataforma para dados centrais de negócio e aplicações críticas, inclusive quando esses dados são integrados a cloud, analytics e IA. (IBM)
Então podemos ter:
Db2
SYSTEM OF RECORD
|
+-------+-------+
| | |
Redis Search Analytics
Esses sistemas podem possuir cópias especializadas.
Mas existe uma fonte autoritativa.
Isso evita transformar inconsistência em arqueologia.
25. Curiosidade: NoSQL nunca significou “SQL é inútil”
A explosão NoSQL nasceu de problemas reais:
escala
distribuição
flexibilidade
latência
novos workloads
Mas durante algum tempo o debate tecnológico virou quase futebol:
SQL versus NoSQL
Essa oposição é pobre.
Uma arquitetura pode perfeitamente utilizar ambos.
O problema não é escolher SQL.
Nem escolher NoSQL.
O problema é usar qualquer um deles sem entender por quê.
26. E o Db2 no meio dessa selva?
Para o programador COBOL iniciante, vale reforçar algo.
Db2 não é simplesmente:
“o lugar onde meu COBOL executa SELECT”.
Existe uma civilização inteira por baixo:
COBOL
|
Host Variables
|
SQL
|
Precompile
|
DBRM
|
BIND
|
PACKAGE
|
Access Path
|
Db2
|
Buffer Pools
|
Logs
|
IRLM
|
Storage
Quando você executa:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTE
WHERE CPF = :WS-CPF
END-EXEC.
existe muito mais acontecendo do que simplesmente “ler uma tabela”.
Temos otimização, concorrência, locks, buffers, logging, recuperação e access paths.
É por isso que compreender banco de dados não deveria significar apenas decorar SQL.
Precisamos compreender como o mecanismo atende ao workload.
27. O anti-pattern final: Resume-Driven Development
Existe um último monstro escondido nesta dungeon.
O desenvolvedor quer aprender tecnologia X.
Então encontra um problema que justifique tecnologia X.
PROBLEMA
↑
TECNOLOGIA
A ordem foi invertida.
Isso às vezes recebe o apelido de:
Resume-Driven Development.
Ou seja:
escolhemos aquilo que ficará bonito no currículo.
O currículo melhora.
A arquitetura talvez não.
😂
28. Passo a passo para escolher corretamente
Antes de aprovar um novo banco, faça este exercício.
Primeiro, descreva o problema sem mencionar nenhum produto:
Precisamos armazenar 200 milhões de eventos.
90% são escritas.
As consultas usam intervalos temporais.
Precisamos agregar por minuto/hora/dia.
Retenção de cinco anos.
Latência desejada abaixo de X.
Excelente.
Agora temos requisitos.
Segundo, descreva o access pattern.
Terceiro, determine requisitos de consistência.
Quarto, estime volume e crescimento.
Quinto, determine disponibilidade e recuperação.
Sexto, verifique tecnologias que a organização já possui.
Sétimo, compare alternativas.
Oitavo, faça benchmark representativo.
Nono, calcule custo operacional.
Décimo, somente então escolha o produto.
Essa ordem parece menos emocionante.
Mas produção costuma recompensar decisões menos emocionantes.
29. Às 04:12 finalmente encontramos o problema
Voltamos ao incidente.
Cinco bancos.
Vários microsserviços.
Dashboards piscando.
O arquiteto pergunta:
— Qual database está lento?
O programador COBOL responde:
— Nenhum.
— Como assim?
— O problema é sincronização.
Silêncio.
Db2 possui um estado.
Redis possui outro.
Elasticsearch ainda não recebeu determinado evento.
O warehouse recebeu uma carga incompleta.
E uma aplicação está consultando uma cópia acreditando ser a fonte oficial.
Não existia um problema de database.
Existia um problema de arquitetura de dados.
O velho programador toma outro gole de café.
— Então qual banco precisamos trocar?
Ele responde:
— Nenhum.
Talvez essa seja a resposta mais difícil de vender numa reunião de arquitetura.
Conclusão — o database começa na pergunta
A tecnologia moderna nos oferece uma quantidade extraordinária de opções:
Relational
Document
Key-Value
Graph
Search
Time-Series
Warehouse
Vector
Isso é fantástico.
Mas liberdade tecnológica também cria responsabilidade arquitetural.
Não existe database universal.
Também não existe obrigação de utilizar um banco diferente para cada característica da aplicação.
Ferramentas modernas inclusive cruzam fronteiras: PostgreSQL pode receber busca vetorial por meio do pgvector, enquanto Elasticsearch combina pesquisa textual, filtros, agregações e vetores. (GitHub)
Portanto, nossa sequência deveria ser:
PROBLEMA
↓
WORKLOAD
↓
ACCESS PATTERN
↓
CONSISTÊNCIA
↓
ESCALA
↓
DISPONIBILIDADE
↓
OPERAÇÃO
↓
CUSTO
↓
TECNOLOGIA
Nunca:
TECNOLOGIA DA MODA
↓
"Agora precisamos encontrar
algum problema para ela."
E talvez seja essa a grande ironia.
Depois de MongoDB, Redis, Neo4j, Elasticsearch, Data Lakes, Lakehouses, NoSQL, NewSQL, cloud databases, time-series, embeddings, RAG e Vector Databases, chegamos novamente diante daquele veterano sentado no CPD.
Ele trabalhou com arquivos sequenciais.
Conheceu VSAM.
Conheceu IMS.
Aprendeu Db2.
Sobreviveu a milhares de COMMIT, alguns ROLLBACK, incontáveis JCLs e provavelmente um SQLCODE -911 numa sexta-feira.
Ele observa nosso maravilhoso diagrama arquitetural com oito databases, toma um gole do café já frio e faz a mesma pergunta que fazia décadas atrás:
“Muito bonito. Mas como você vai acessar o registro?”
E de repente toda a arquitetura moderna cabe nessa pergunta.
Porque ferramentas envelhecem.
Produtos mudam.
Nomes comerciais desaparecem.
Paradigmas voltam usando roupas novas.
Mas entender o problema antes de escolher a solução continua sendo uma das skills mais importantes que um programador pode aprender.
Easter egg final:
EVALUATE TRUE
WHEN NEED-TRANSACTION
PERFORM USE-RELATIONAL
WHEN NEED-KEY-LOOKUP
PERFORM USE-KEY-VALUE
WHEN NEED-RELATIONSHIPS
PERFORM USE-GRAPH
WHEN NEED-SEARCH
PERFORM USE-SEARCH
WHEN NEED-SEMANTIC-SIMILARITY
PERFORM USE-VECTOR
WHEN OTHER
DISPLAY
"PERGUNTE PRIMEIRO QUAL E O PROBLEMA"
END-EVALUATE.
Só faltou uma cláusula:
WHEN ARCHITECT-SAYS
"VAMOS USAR PORQUE TODO MUNDO USA"
PERFORM MAKE-COFFEE
PERFORM ASK-WHY
UNTIL REQUIREMENT-FOUND
