sábado, 4 de maio de 2024

🧩 O “Relational Problem”: quando o modelo relacional começa a ranger os dentes

Bellacosa Mainframe e o Relation Problem

🧩 O “Relational Problem”: quando o modelo relacional começa a ranger os dentes

Teve uma época — lá pelos anos 70 e 80 — em que o modelo relacional era praticamente um presente divino.
Ted Codd apareceu com tabelas, chaves, normalização e alguém pensou:

“Pronto, agora dá pra organizar o mundo inteiro em linhas e colunas.”

E funcionou. Funcionou bem demais.
Funcionou tanto que virou padrão em bancos, governos, ERPs, mainframes, folha de pagamento, compensação bancária, impostos, seguros… o pacote completo.

Só que aí veio o mundo moderno.
E ele veio sem pedir licença.

📈 A explosão de dados (ou: quando o DB começou a suar frio)

Web, mobile, redes sociais, IoT, logs, sensores, streaming, analytics em tempo real…
De repente, o banco relacional passou a ouvir frases como:

“Preciso escalar horizontalmente.”
“Tem que responder em milissegundos.”
“O schema muda toda semana.”
“Esse JSON aqui é meio… flexível.”

Nesse momento nasce o que chamamos de Relational Problem:
👉 a dificuldade crescente de gerenciar, escalar e consultar dados usando RDBMS tradicionais em ambientes cada vez maiores, mais variados e mais exigentes.

O vilão clássico?

Schemas rígidos
Joins caros
Crescimento exponencial de volume
Performance sofrendo conforme a complexidade aumenta

📌 Easter egg: se você já viu um EXPLAIN com 12 joins e custo astronômico, você já sentiu o Relational Problem na pele.

🏗️ Solução 1: Escalar pra cima (o famoso “compra mais ferro”)

A primeira reação clássica é:

“Coloca mais CPU, mais memória e mais disco.”

No mundo mainframe isso tem nome, sobrenome e fatura alta 💸.

✔️ Funciona? Funciona.
❌ Resolve pra sempre? Não.

É caro
Tem limite físico
E uma hora… acaba

👉 Vertical scaling resolve dor imediata, não o problema estrutural.

🔧 Solução 2: Otimizar até a última gota

Aí entra o arsenal conhecido:

Índices
Partitioning
Denormalização
Tuning de SQL
Estatísticas afinadas na lua certa 🌕

Isso melhora muito, mas cobra seu preço:

Mais complexidade
Mais overhead operacional
Mais chances de alguém quebrar tudo num ALTER inocente

📌 Fofoquinha: todo ambiente tem aquele índice criado “em produção às pressas” que ninguém sabe se pode remover.

🌐 Solução 3: Relacional distribuído (o meio do caminho)

Aqui a ideia é ousada:

“Vamos manter o modelo relacional, mas espalhar os dados.”

Resultado:

Mais escalabilidade
Mais disponibilidade
E… mais complexidade de consistência e transação

💡 ACID distribuído não é trivial.
Quem já estudou two-phase commit sabe que não existe almoço grátis.

🚀 Solução 4: NoSQL — o rebelde sem gravata

Aí surgem os NoSQL:

Key-value
Documento
Colunar
Grafos

Eles dizem:

“Relaxa o schema, relaxa o relacionamento, escala horizontalmente e seja feliz.”

✔️ Alta performance
✔️ Flexibilidade
✔️ Escala global

❌ Menos garantias transacionais
❌ Consistência eventualmente… eventual 😅

📌 Easter egg: NoSQL não significa “No SQL”, mas muita gente usa como “No JOIN, graças a Deus”.

🔀 Solução 5: Abordagem híbrida (o mundo real)

Na prática, o que venceu foi o híbrido:

Relacional para transação crítica
NoSQL ou Data Warehouse para analytics e volume massivo
Cada banco no seu quadrado

👉 O banco certo para o problema certo.

💬 Comentário Bellacosa:
Mainframe + DB2 continua reinando onde consistência, auditoria e confiabilidade não são opcionais.

⚖️ Os grandes trade-offs (onde mora a dor)

Resolver o Relational Problem é basicamente escolher qual dor você aceita.

🔐 Consistência vs Disponibilidade & Escala

Relacional ama ACID
Distribuído ama performance
CAP theorem fica no meio rindo da sua cara

🧱 Rigidez de schema vs Flexibilidade

Schema fixo protege a integridade
Schema flexível acelera mudança
Um trava, o outro corre… e tropeça às vezes

⚙️ Performance vs Complexidade

Tuning melhora performance
Mas aumenta custo, risco e dependência de especialistas

💰 Custo vs Controle

Hardware e licenças caros
Cloud e distribuído mais baratos (até não serem)

🏦 Quem escolhe o quê?

Bancos, governos, seguradoras
👉 Consistência, governança, auditoria
👉 Relacional forte, bem cuidado, bem documentado
Empresas web-scale, data-driven
👉 Escala, agilidade, crescimento rápido
👉 Distribuído, NoSQL, híbrido

📌 Não é sobre tecnologia “melhor”.
É sobre prioridade de negócio.

☕ Conclusão estilo café no mainframe

O Relational Problem não significa que o modelo relacional falhou.
Significa que ele foi bom demais por tempo demais em um mundo que mudou radicalmente.

A maturidade está em entender:

Onde ele brilha
Onde ele sofre
E como combiná-lo com outras abordagens

💬 Última fofoquinha:
Quem decreta a “morte do relacional” geralmente nunca precisou fechar um balanço financeiro auditado.