 |
| Bellacosa Mainframe e os 20mil datoms submarinos |
☕ Um Café no Bellacosa Mainframe
Vinte Mil Datoms Submarinos: COBOL, Datomic e a Viagem ao Centro de um Banco de Dados que Decidiu que UPDATE Era uma Ideia Suspeita
🌊 Clojure, Rich Hickey, Cognitect, Nubank, Datalog, EAVT, imutabilidade, transações ACID, Transactor, peers, caches, AWS, DynamoDB e a extraordinária viagem de um COBOLzeiro acostumado a VSAM, IMS, Adabas e Db2 até uma máquina de 2012 que parecia ter sido trazida do futuro pelo capitão Nemo
Nota do diário de bordo — 2012
Existem momentos na história da tecnologia em que alguém olha para aquilo que todos fazem há décadas e comete a inconveniência de perguntar:
“Mas por que fazemos assim?”
Normalmente essa pessoa é convidada a parar de atrapalhar a reunião.
Às vezes ela cria Clojure.
Depois cria Datomic.
Se Júlio Verne tivesse trabalhado com bancos de dados, talvez Vinte Mil Léguas Submarinas começasse numa sala de processamento.
O professor Pierre Aronnax seria um programador COBOL.
Conseil seria DBA.
Ned Land provavelmente trabalharia em Produção.
E o capitão Nemo surgiria diante de uma máquina desconhecida dizendo:
— Senhores, apresento-lhes o Datomic.
O COBOLzeiro examinaria cuidadosamente o equipamento.
— Onde estão minhas tabelas?
— Não pense em tabelas.
— Onde está o UPDATE?
— Não precisamos pensar dessa maneira.
— Onde fica o servidor de banco?
— É complicado.
— Qual linguagem?
— Clojure.
Silêncio.
— Podemos voltar para o barco?
Não.
Já mergulhamos.
E estamos indo fundo.
⚓ Capítulo I — O monstro desconhecido
Para entender por que Datomic parece tão alienígena, precisamos lembrar o mundo em que apareceu.
Era 2012.
Oracle, Db2, SQL Server e PostgreSQL já eram tecnologias extremamente estabelecidas.
MongoDB havia aparecido em 2009.
Cassandra crescia.
Hadoop estava em plena ascensão.
A palavra NoSQL estava por toda parte.
A discussão frequentemente parecia:
RELACIONAL
│
│ ACID
│ SQL
│ schema
│ joins
▼
versus
NoSQL
│
│ scale-out
│ distribuição
│ schema flexível
│ eventual consistency
▼
E no meio dessa batalha aparece uma criatura estranha.
Em março de 2012, a equipe da então Relevance, depois Cognitect, apresentou Datomic ao público. A tecnologia estava profundamente ligada a Rich Hickey, criador da linguagem Clojure. A própria Cognitect contou posteriormente que a equipe havia trabalhado por quase dois anos para transformar a visão de Hickey em um banco de dados.
A edição gratuita apareceria em junho daquele mesmo ano.
Não era IBM.
Não era Oracle.
Não era Microsoft.
Não era uma universidade produzindo um protótipo acadêmico.
Era uma empresa relativamente pequena propondo:
Talvez estejamos decompondo bancos de dados de maneira errada.
O COBOLzeiro experiente imediatamente pergunta:
“E quem decidiu colocar dinheiro de cliente nisso?”
Calma.
Chegaremos lá.
🌊 Capítulo II — Antes de mergulhar, consulte os mapas antigos
Para quem começou diretamente com PostgreSQL ou MySQL, Datomic pode parecer completamente extraterrestre.
Para quem conhece a história dos bancos de dados, nem tanto.
Nossa viagem começa muito antes.
VSAM
│
▼
IMS
│
▼
ADABAS
│
▼
RELACIONAL / DB2
│
▼
DATOMIC
Cada tecnologia respondeu de maneira diferente à pergunta:
O que é um dado e como chegamos até ele?
🗃️ VSAM — encontre o registro
No VSAM KSDS você pensa naturalmente:
KEY
│
▼
INDEX
│
▼
CONTROL AREA
│
▼
CONTROL INTERVAL
│
▼
RECORD
Quer o cliente 12345?
Procure a chave.
O mundo ainda está muito próximo do armazenamento físico.
O programador conhece:
KSDS
ESDS
RRDS
LDS
E aprende rapidamente uma verdade eterna:
A maneira como organizamos dados influencia brutalmente a maneira como conseguimos acessá-los.
Guarde essa frase.
Ela voltará quando encontrarmos:
EAVT
AEVT
AVET
VAET
🌳 Capítulo III — IMS constrói uma árvore no fundo do oceano
IMS oferece outro universo.
CLIENTE
│
├── CONTA
│ │
│ └── MOVIMENTO
│
└── ENDEREÇO
Hierarquia.
Parent.
Child.
Segmentos.
DL/I.
Agora o programador precisa entender:
Qual é o caminho até meu dado?
O banco não precisa ser uma coleção de tabelas.
Esse detalhe será importante daqui a pouco.
🧙 Capítulo IV — ADABAS aparece com seus descritores
Então encontramos Adabas.
Outra filosofia.
Temos conceitos como:
FILE
FIELD
ISN
DESCRIPTOR
SUPERDESCRIPTOR
A estrutura física e a maneira lógica de localizar informações tornam-se novamente interessantes.
Nosso viajante aprende outra lição:
A visão apresentada à aplicação não precisa reproduzir literalmente a organização física.
Portanto, quando Datomic disser:
ENTITY
ATTRIBUTE
VALUE
TRANSACTION
um veterano pode estranhar.
Mas não deveria entrar em pânico.
Já vimos criaturas mais estranhas.
🏛️ Capítulo V — Db2 e a grande revolução declarativa
Então chega o modelo relacional.
Agora você pode escrever:
SELECT NOME, SALDO
FROM CONTA
WHERE CLIENTE = 12345;
Observe a revolução.
Você não disse:
vá para CI
localize índice
ande três registros
encontre ponteiro
Você disse:
Quero isto.
O otimizador decide como encontrar.
Essa abstração foi monumental.
Mas nosso cérebro passou décadas construindo outra imagem:
TABLE
│
├── ROW
├── ROW
├── ROW
└── ROW
E depois:
UPDATE CONTA
SET SALDO = 800
WHERE CLIENTE = 12345;
Antes:
SALDO = 1000
Depois:
SALDO = 800
Naturalmente Db2 possui logging, recovery, temporal tables, auditoria e uma enorme infraestrutura para preservar e reconstruir estados.
Mas nosso modelo mental da aplicação normalmente continua:
ESTADO ANTIGO
│
UPDATE
│
▼
ESTADO NOVO
É justamente aqui que o Nautilus aparece.
🐙 Capítulo VI — Capitão Rich Hickey pergunta: “Por que destruir o passado?”
Rich Hickey vem do mundo da programação funcional.
Uma de suas grandes obsessões intelectuais é estado e identidade ao longo do tempo.
Em vez de:
X = 10
X = 20
X = 30
pense:
X em T1 = 10
X em T2 = 20
X em T3 = 30
Parece uma pequena mudança.
Não é.
É a entrada para o submarino.
Datomic leva essa ideia para o banco de dados.
Em vez de pensar primordialmente:
“O banco é um conjunto de registros que vou modificando.”
pense:
“O banco acumula fatos ao longo do tempo.”
A documentação oficial descreve Datomic justamente em torno de database values imutáveis e informação acumulada transacionalmente.
Documentação oficial do Datomic
🔬 Capítulo VII — Descobrimos o Datom
A unidade fundamental é o:
DATOM
Conceitualmente:
E A V Tx Added?
Onde:
E = Entity
A = Attribute
V = Value
Tx = Transaction
Imagine:
[1001 :cliente/nome "Arthur Dent" 5001 true]
Leia:
Na transação 5001 foi afirmado que a entidade 1001 possui nome Arthur Dent.
Outro:
[1001 :cliente/limite 5000 5002 true]
Depois o limite muda.
Não precisamos imaginar simplesmente:
5000 → destruído
8000 → colocado no lugar
Podemos representar conceitualmente:
T1
CLIENTE 1001
LIMITE 5000
Depois:
T2
RETRACT
CLIENTE 1001
LIMITE 5000
ASSERT
CLIENTE 1001
LIMITE 8000
Agora Datomic conhece:
T1 → 5000
T2 → 8000
O passado continua fazendo parte da história.
⏰ Capítulo VIII — O banco possui uma máquina do tempo
Aqui Júlio Verne provavelmente pediria licença para escrever outro livro.
Imagine uma auditoria.
— Qual é o limite do cliente?
R$ 8.000
— Qual era ontem?
R$ 5.000
— E antes?
R$ 3.000
Datomic possui conceitos como:
as-of
since
history
que permitem trabalhar naturalmente com diferentes visões temporais do database.
Isso produz uma imagem maravilhosa:
DATABASE T0
│
▼
DATABASE T1
│
▼
DATABASE T2
│
▼
DATABASE T3
Você está em T3.
Mas pode perguntar como o mundo era em T1.
Para finanças, auditoria e investigação, isso é sedutor.
💰 Capítulo IX — “Agora entendi por que um banco gostou disso”
Exatamente.
Bancos vivem de perguntas temporais.
Qual era o saldo?
Quando mudou?
Qual regra estava vigente?
Quando o limite foi alterado?
Que informação conhecíamos naquele momento?
Qual transação introduziu esse fato?
Datomic torna o tempo parte fundamental do modelo.
Mas atenção!
Isso não significa automaticamente que Datomic seja melhor que Db2 para bancos.
Db2 possui recursos temporais, logs, auditoria, recovery, CDC e décadas de engenharia financeira.
A diferença interessante é filosófica:
DATOMIC
TEMPO + IMUTABILIDADE
│
▼
estão no coração
do modelo
🧭 Capítulo X — Mas quem teve coragem de escolher isso?
E aqui chegamos ao Nubank.
Quando uma instituição tradicional escolhe um database, normalmente existe um questionário quase jurássico:
Quantos bancos usam?
Há quanto tempo existe?
Quem fornece suporte?
Quantos DBAs existem?
Tem HA?
Tem DR?
Tem backup?
Tem recovery?
Tem ferramentas?
Tem referência?
Quem atende domingo às 03:00?
E essas perguntas são excelentes.
Agora imagine Datomic por volta de 2014:
Datomic
lançamento: 2012
ecossistema: pequeno
Clojure
Cognitect
Datalog
modelo incomum
COBOLzeiro:
“Vocês perderam completamente o juízo?”
😂
Mas Nubank possuía uma vantagem gigantesca:
não havia legado.
Uma instituição tradicional começa:
NOVO SISTEMA
│
▼
40 ANOS DE HISTÓRIA
│
┌───┼────┐
│ │ │
CICS DB2 IMS
│ │ │
COBOL MQ BATCH
Uma startup começa muito mais perto de:
┌───────────────────┐
│ │
│ VAZIO │
│ │
└───────────────────┘
Ela pode perguntar:
Se começássemos agora, o que escolheríamos?
Essa liberdade permitiu escolhas muito mais ousadas.
🧬 Capítulo XI — Clojure entra no submarino
E aqui finalmente chegamos à linguagem que assustou nosso COBOLzeiro.
Clojure é uma linguagem funcional da família Lisp criada por Rich Hickey.
Você encontra:
(+ 1 2)
COBOLzeiro:
— Por que o operador está antes dos números?
Capitão Nemo:
— Continue.
Depois:
(when (> saldo limite)
(bloquear-conta conta))
— Certo. Estranho, mas sobrevivo.
Então aparecem funções, estruturas persistentes, composição e imutabilidade.
A ideia central começa a emergir:
COBOL IMPERATIVO
ESTADO A
│
MOVE
COMPUTE
ADD
SUBTRACT
│
▼
ESTADO B
Clojure favorece pensar:
VALOR A
│
FUNÇÃO
│
▼
VALOR B
Sem necessariamente destruir A.
Agora coloque Datomic ao lado:
CLOJURE
│
▼
IMUTABILIDADE
│
▼
VALORES
│
▼
DATOMIC
│
▼
FATOS
│
▼
TEMPO
De repente Clojure + Datomic deixam de parecer um casamento acidental.
São parentes intelectuais.
🗺️ Capítulo XII — Datalog: SQL desapareceu!
O COBOLzeiro pergunta:
— Certo. Quero fazer um SELECT.
Capitão Nemo:
— Datalog.
— Um quê?
Uma query pode parecer:
[:find ?nome
:where
[?e :cliente/nome ?nome]]
Leia:
encontre valores ?nome onde exista uma entidade ?e cujo atributo :cliente/nome tenha esse valor.
Conceitualmente:
SELECT NOME
FROM CLIENTE;
Outra:
[:find ?nome
:where
[?e :cliente/nome ?nome]
[?e :cliente/status :ativo]]
Aproximadamente:
SELECT NOME
FROM CLIENTE
WHERE STATUS = 'ATIVO';
Não tente transformar Datalog em SQL palavra por palavra.
Aprenda a lógica.
🧭 Capítulo XIII — Quatro bússolas: EAVT, AEVT, AVET, VAET
Agora nosso velho conhecimento de VSAM retorna triunfante.
Datomic mantém diferentes ordenações dos datoms:
EAVT
AEVT
AVET
VAET
Pense:
E = ENTITY
A = ATTRIBUTE
V = VALUE
T = TRANSACTION
EAVT:
ENTITY
ATTRIBUTE
VALUE
TRANSACTION
Bom para perguntar:
O que sabemos sobre esta entidade?
AVET:
ATTRIBUTE
VALUE
ENTITY
TRANSACTION
Interessante quando buscamos entidades através de valores indexados.
O velho VSAMzeiro sorri.
“Ahhhhh. Diferentes caminhos ordenados para chegar aos dados.”
Não é VSAM.
Mas o cérebro encontrou uma ponte.
⚙️ Capítulo XIV — Onde está o database server?
Agora começa a parte realmente Verne.
No Datomic Pro clássico, temos algo como:
TRANSACTOR
│
WRITES
│
▼
STORAGE
↗ ↖
/ \
PEER PEER
│ │
QUERY QUERY
│ │
CACHE CACHE
O Transactor coordena as transações.
Os Peers podem executar consultas próximos/dentro dos processos das aplicações.
O Storage persiste informação.
É uma decomposição diferente daquela imagem clássica:
APPLICATION
│
▼
DATABASE SERVER
│
▼
DISK
🔐 Capítulo XV — ACID continua a bordo
Datomic não respondeu ao problema de escala dizendo:
“Consistência é superestimada.”
Ele mantém transações ACID.
A — Atomicity
C — Consistency
I — Isolation
D — Durability
E mantém uma ordem transacional.
Para um sistema financeiro isso é extremamente relevante.
Mas aqui aparece a primeira grande limitação arquitetural que nosso dinossauro imediatamente detectaria.
🚨 Capítulo XVI — “Onde está o gargalo?”
Leituras podem escalar horizontalmente através de peers/compute.
STORAGE
↙ ↓ ↘
PEER PEER PEER
│ │ │
READ READ READ
Bonito.
Mas as escritas precisam respeitar a coordenação transacional.
Então:
READS
│
├── PEER
├── PEER
├── PEER
└── PEER
podem escalar muito bem
Enquanto:
WRITES
│
▼
ordenação transacional
O COBOLzeiro levanta a mão.
— Qual é o limite de escrita?
Excelente pergunta.
Muito melhor que perguntar simplesmente:
“Quantos terabytes suporta?”
🧠 Capítulo XVII — CPU × memória × storage
Aqui voltamos ao capacity planning.
Datomic pode possuir uma base muito maior que a memória disponível porque trabalha com índices segmentados e camadas de cache.
Portanto:
DATABASE SIZE ≠ REQUIRED RAM
Imagine:
DATABASE = 20 TB
WORKING SET = 15 GB
CACHE/RAM = 64 GB
Potencialmente excelente.
Grande parte daquilo que a aplicação toca frequentemente cabe próximo da CPU.
Agora:
DATABASE = 2 TB
WORKING SET = 1,5 TB
CACHE/RAM = 64 GB
Problema.
QUERY
│
▼
CACHE MISS
│
▼
CACHE MISS
│
▼
STORAGE
│
▼
LATENCY
Portanto, a pergunta correta não é:
“Qual é o tamanho da base?”
É:
“Qual é o working set?”
Um veterano de buffer pool já ouviu música semelhante.
🧊 Capítulo XVIII — A imutabilidade produz caches deliciosos
Cache tradicional possui um problema clássico:
DATABASE = X
CACHE = X
DATABASE muda para Y
CACHE continua X
OPS.
Precisamos invalidar.
Atualizar.
Sincronizar.
Datomic possui segmentos imutáveis.
Um segmento histórico que era correto continua correto.
Isso produz:
IMMUTABILITY
│
▼
CACHE SEGURO
│
▼
LOCALITY
│
▼
READ PERFORMANCE
É uma consequência extremamente elegante da arquitetura.
🗄️ Capítulo XIX — Mas imutabilidade cobra aluguel no storage
Nada é grátis.
Imagine:
SALDO
T1 1000
T2 800
T3 1200
T4 950
T5 1400
Se você preserva história, está armazenando mais informação.
Além disso, Datomic mantém diferentes índices dos datoms.
Portanto:
MAIS HISTÓRIA
+
MAIS INDEXAÇÃO
=
MAIS STORAGE
Isso é intencional.
A filosofia poderia ser resumida:
Storage é relativamente barato; perder conhecimento sobre o passado pode ser caríssimo.
Em finanças, essa frase ganha outro peso.
🏎️ Capítulo XX — E a indexação precisa acompanhar o submarino
Transações produzem novos datoms.
Simplificando:
TRANSACTIONS
│
▼
MEMORY INDEX
│
▼
BACKGROUND INDEXING
│
▼
PERSISTENT INDEX
Agora imagine:
ENTRADA DE NOVOS DATOMS
>
CAPACIDADE DE INDEXAÇÃO
O memory index começa a crescer.
Se isso continuar, Datomic precisa exercer back pressure, reduzindo a capacidade de aceitar novas transações enquanto a indexação recupera terreno.
Eis uma lição universal:
Você não pode escrever eternamente mais rápido do que consegue organizar aquilo que escreveu.
Nem no Nautilus.
Nem na AWS.
Nem no z17.
☁️ Capítulo XXI — A AWS entra na expedição
Datomic Cloud utiliza serviços da AWS para diferentes funções, incluindo tecnologias como DynamoDB e S3, além de camadas de compute/cache. A arquitetura oficial detalha essa separação.
Isso permite explorar:
DURABILITY
│
▼
STORAGE
+
COMPUTE
│
▼
CACHE / QUERY
Mas lembre-se:
cloud não aboliu capacity planning.
Ela apenas mudou o formulário de compra.
Antigamente:
PRECISO DE CPU
↓
capacity planning
↓
hardware
↓
instalação
Cloud:
PRECISO DE CPU
↓
API
↓
FATURA
A física continua lá.
🐘 Capítulo XXII — Até onde uma base Datomic pode crescer?
A resposta correta não é um número mágico.
Não existe:
DATOMIC MAXIMUM =
37,42 TB
que resolva nossa arquitetura.
Precisamos analisar:
database size
+
datom count
+
working set
+
write rate
+
read rate
+
query complexity
+
cache hit ratio
+
indexing rate
+
storage latency
+
CPU
+
RAM
+
GC
+
data model
Portanto:
CAPACITY =
f(storage,
cpu,
memory,
workload,
locality,
writes,
reads,
indexes)
Muito familiar, não?
🧟 Capítulo XXIII — O fantasma chamado Garbage Collection
Lembremos:
Clojure/JVM.
Peers.
Caches.
Objetos.
RAM.
E então surge das profundezas:
GC
/ \
/ \
/ \
👻
O COBOLzeiro:
“EU SABIA!”
😂
Mais RAM nem sempre significa simplesmente:
MAIS RAM = MAIS RÁPIDO
Heap, cache, allocation patterns e garbage collection precisam ser observados.
O submarino continua sujeito às leis da JVM.
🏦 Capítulo XXIV — Então Nubank colocou tudo numa database monstruosa?
Não.
E isso é crucial.
O sucesso do Datomic dentro do Nubank não deve ser imaginado assim:
ONE DATOMIC
█████████████████████████████
TODOS OS CLIENTES
TODOS OS PRODUTOS
TODAS AS TRANSAÇÕES
█████████████████████████████
A arquitetura evoluiu em torno de muitos serviços e databases.
Ou seja, escala pode ser obtida também decompondo:
PLATFORM
│
├── SERVICE A → DATABASE A
│
├── SERVICE B → DATABASE B
│
├── SERVICE C → DATABASE C
│
└── SERVICE D → DATABASE D
Agora temos outro tipo de escalabilidade.
Em vez de perguntar:
“Até onde uma única database consegue crescer?”
perguntamos:
“Como particionamos o domínio?”
🔬 Capítulo XXV — O experimento que virou banco gigantesco
Aqui está o aspecto extraordinário.
Quando Nubank escolheu Datomic, não colocou imediatamente cem milhões de clientes sobre ele.
O processo foi aproximadamente:
STARTUP
│
▼
milhares
│
▼
centenas de milhares
│
▼
milhões
│
▼
dezenas de milhões
│
▼
100+ milhões
A arquitetura amadureceu junto com a instituição.
Esse é um experimento completamente diferente de:
BANCO TRADICIONAL
SEXTA 23:59
DESLIGAR DB2
SEGUNDA 06:00
LIGAR DATOMIC
BOA SORTE.
😂
🏭 Capítulo XXVI — Quem mais usa?
E aqui encontramos uma peculiaridade.
Datomic possui outros clientes públicos e o mantenedor fala em centenas de organizações, mas ele jamais alcançou a ubiquidade de:
Oracle
Db2
PostgreSQL
SQL Server
MongoDB
Seu ecossistema continua relativamente especializado.
Isso explica por que alguém pode trabalhar décadas com bancos de dados e praticamente nunca encontrá-lo.
Seu grafo tecnológico está muito mais próximo de:
CLOJURE
│
▼
FUNCTIONAL PROGRAMMING
│
▼
RICH HICKEY
│
▼
COGNITECT
│
▼
DATOMIC
que do universo:
COBOL
│
CICS
│
DB2
│
IMS
Os continentes existem no mesmo planeta.
Mas poucas rotas marítimas os ligavam.
💜 Capítulo XXVII — O cliente compra o construtor do submarino
Agora vem um dos melhores Easter eggs da história.
Datomic era produzido pela Cognitect.
Nubank tornou-se enorme usuário de Clojure e Datomic.
Então, em 23 de julho de 2020, Nubank anunciou a aquisição da Cognitect.
Nubank — aquisição da Cognitect
A sequência fica:
COGNITECT
│
├── CLOJURE
│
└── DATOMIC
│
▼
NUBANK
│
▼
USA MUITO
│
▼
ESCALA
│
▼
2020 ─ NUBANK COMPRA COGNITECT
É como se o passageiro do Nautilus dissesse:
“Gostei do submarino.”
E comprasse o estaleiro.
⚠️ Capítulo XXVIII — Mas quem declarou que isso era seguro para finanças?
Ninguém em Brasília publicou:
RESOLUÇÃO Nº 42
Art. 1º Datomic está aprovado.
Art. 2º Clojure está liberado.
Art. 3º Pode ir tranquilo.
😂
Reguladores normalmente não homologam linguagens e bancos de dados dessa maneira.
A responsabilidade continua com a instituição.
A pergunta regulatória é muito mais:
Você controla o risco?
Você protege os dados?
Você garante continuidade?
Você possui governança?
Você testa recuperação?
Você monitora?
Você audita?
Você consegue provar integridade?
Tecnologia é uma parte.
Arquitetura e controles são outra.
🚨 Capítulo XXIX — ACID não significa “banco seguro”
Essa distinção merece uma placa no submarino.
ACID
≠
HA
≠
DR
≠
CYBERSECURITY
≠
CORRECTNESS
≠
CAPACITY
≠
RECONCILIATION
Um database pode funcionar perfeitamente enquanto sua aplicação executa uma regra errada.
AWS OK
DATOMIC OK
NETWORK OK
CPU OK
MEMORY OK
BUSINESS RULE
↓
BUG
Parabéns.
Você possui uma infraestrutura extremamente confiável executando o cálculo errado.
Em altíssima velocidade.
💵 Capítulo XXX — Dinheiro precisa fechar
Aqui desaparecem modismos.
Não importa se usamos:
COBOL
CLOJURE
JAVA
RUST
nem:
VSAM
IMS
ADABAS
DB2
DATOMIC
Em algum momento alguém precisa provar:
SALDO INICIAL
+
CRÉDITOS
-
DÉBITOS
=
SALDO FINAL
E:
Σ DÉBITOS
=
Σ CRÉDITOS
E reconciliar:
LEDGER
↕
PIX
↕
CARTÕES
↕
LIQUIDAÇÃO
↕
CONTABILIDADE
A tecnologia pode mudar radicalmente.
A contabilidade permanece brutalmente conservadora.
E ainda bem.
🦖 Capítulo XXXI — O dinossauro faz as perguntas certas
Quando um veterano pergunta:
“Quem mais usa?”
isso não é necessariamente resistência à inovação.
É análise de risco.
Quando pergunta:
“Quem fornece suporte?”
é análise de risco.
Quando pergunta:
“Como recupera?”
é análise de risco.
Quando pergunta:
“Qual é o limite?”
é análise de risco.
Quando pergunta:
“Quem atende às 03:47?”
é experiência adquirida através de trauma operacional.
Produtos maduros carregam milhares de funcionalidades aparentemente burocráticas porque algum cliente, em algum domingo, descobriu que precisava delas.
🧭 Capítulo XXXII — O roteiro para um COBOLzeiro aprender Datomic
Não comece por Clojure.
Eu seguiria esta rota:
ETAPA 1
DATOM
E A V T
Entenda o fato.
Depois:
ETAPA 2
ENTITY
ATTRIBUTE
VALUE
Depois:
ETAPA 3
ASSERT
RETRACT
Depois:
ETAPA 4
TIME
HISTORY
AS-OF
Depois:
ETAPA 5
EAVT
AEVT
AVET
VAET
Depois:
ETAPA 6
TRANSACTOR
PEER
STORAGE
Depois:
ETAPA 7
CACHE
MEMORY INDEX
BACKGROUND INDEXING
Depois:
ETAPA 8
DATALOG
E só então:
ETAPA 9
CLOJURE
Porque aí os parênteses terão um motivo para existir.
🐋 Capítulo XXXIII — As dez perguntas universais
Pegue qualquer banco de dados.
Faça sempre estas perguntas:
1. O que representa um dado?
2. Como identifico uma entidade?
3. Como encontro o dado?
4. Como relaciono informações?
5. Como altero estado?
6. Como indexo?
7. Como transaciono?
8. Como recupero?
9. Como escalo?
10. O que acontece quando tudo dá errado?
Aplique a:
VSAM
IMS
ADABAS
DB2
DATOMIC
As respostas mudam.
As perguntas permanecem.
Isso é arquitetura.
🌊 Epílogo — O Nautilus chega ao século XXI
Depois de vinte mil datoms submarinos, nosso COBOLzeiro finalmente encontra o capitão Nemo na sala de máquinas.
— Admito que é interessante.
Nemo sorri.
— Datomic?
— Sim.
— Imutabilidade?
— Interessante.
— Datalog?
— Sobreviverei.
— Clojure?
O COBOLzeiro fica em silêncio.
— Ainda não abuse da sorte.
😂
Ele observa pela janela.
Do lado de fora passam:
EAVT
AEVT
AVET
VAET
como enormes criaturas marinhas.
No painel:
CPU 63%
MEMORY 71%
CACHE HIT 96%
INDEXING OK
STORAGE GROWING
O programador sorri.
Porque finalmente reconheceu alguma coisa.
Capacity planning.
Mudamos:
CONTROL INTERVAL
por:
DATOM
Mudamos:
BUFFER POOL
por outras camadas de:
CACHE
Mudamos:
SQL
por:
DATALOG
Mudamos:
DBMS SERVER
por uma arquitetura de:
TRANSACTOR
+
PEERS
+
STORAGE
Mudamos:
UPDATE
por uma filosofia de:
ASSERT
+
RETRACT
+
HISTORY
Mas não conseguimos eliminar:
CPU
MEMÓRIA
STORAGE
I/O
LATÊNCIA
CONTENÇÃO
INDEXAÇÃO
RECOVERY
CAPACITY
AUDITORIA
RISCO
Porque Rich Hickey pode desafiar quarenta anos de design de bancos de dados.
Pode transformar database em valor.
Pode transformar alterações em fatos.
Pode tornar o tempo uma dimensão natural.
Pode separar query, transação e armazenamento.
Pode até convencer um banco brasileiro recém-nascido a apostar numa tecnologia de aproximadamente dois anos e vê-la crescer junto com uma instituição gigantesca.
Mas existe uma força contra a qual nem Clojure consegue argumentar:
a física.
E talvez seja essa a conclusão mais bonita desta viagem.
Datomic não é interessante porque provou que Db2, IMS, Adabas ou VSAM estavam errados.
É interessante porque alguém teve coragem de perguntar se algumas decisões que considerávamos inevitáveis eram realmente inevitáveis.
Em 2012, aquilo parecia quase uma máquina de Júlio Verne.
Em 2014, escolher aquilo para ajudar a construir um banco parecia uma expedição ao fundo do oceano.
Em 2020, o passageiro comprou o estaleiro: o Nubank adquiriu a Cognitect.
E hoje podemos olhar para a experiência acumulada e descobrir algo ainda mais fascinante:
PASSADO
VSAM
IMS
ADABAS
DB2
↓
PRESENTE
DATOMIC
CLOJURE
CLOUD
↓
FUTURO
?????????
Não precisamos declarar vencedor.
O verdadeiro aprendizado está em entender por que cada geração tomou suas decisões.
Porque daqui a vinte anos algum jovem provavelmente entrará no CPD — ou seja lá como aquilo se chamar — olhará para Datomic, Kubernetes e AWS e dirá:
“Vocês realmente faziam banco desse jeito?”
O velho COBOLzeiro tomará um gole de café.
Olhará para o Nautilus atracado ao lado de um IBM Z.
E responderá:
“Meu jovem, sente-se. Essa história começou muito antes de você imaginar. Primeiro preciso lhe explicar o que era um KSDS.”
E assim começará outra viagem.
Vinte mil datoms abaixo do SELECT. ☕🌊🦖
