Bellacosa Mainframe e o misterio de como escolher um banco de dados

☕ Um Café no Bellacosa Mainframe

O 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

Translate

sábado, 4 de novembro de 2023