 |
| Bellacosa Mainframe uma visão escalando banco de dados |
☕ Um Café no Bellacosa Mainframe
Escalando Bancos de Dados sem Entrar em Hiperespaço
Quando um Programador COBOL Descobre que um Banco de Dados Também Pode Crescer Como uma Galáxia — e que o Verdadeiro Vilão Nunca Foi a CPU, Mas a Arquitetura
"NÃO ENTRE EM PÂNICO."
Esta talvez seja a frase mais importante para qualquer programador COBOL que acabou de ouvir alguém dizer:
"O banco não aguenta mais."
Se você leu O Guia do Mochileiro das Galáxias, sabe que o Universo inteiro parece funcionar na base da improvisação extremamente sofisticada.
No mundo dos bancos de dados corporativos acontece exatamente a mesma coisa.
Tudo parece simples.
Até o dia em que o sistema recebe dez vezes mais usuários.
Depois cem vezes.
Depois mil vezes.
E, de repente, aquele pequeno Db2 que atendia tranquilamente uma agência bancária agora precisa responder milhões de consultas por minuto, conversar com centenas de aplicações, suportar APIs REST, aplicativos móveis, sistemas em nuvem, filas MQ, microsserviços, IA, analytics e ainda continuar respondendo em menos de alguns milissegundos.
É nesse momento que o Padawan COBOL olha para o monitor 3270 e pergunta:
— Mestre... colocamos mais memória?
O mestre apenas toma um gole de café e responde:
— Jovem viajante... escalar um banco nunca foi apenas comprar um computador maior.
Pegue sua toalha.
Hoje vamos atravessar a galáxia da escalabilidade.
Capítulo 1 — O Universo Sempre Cresce
Existe uma lei cósmica da computação.
Todo sistema que funciona...
...um dia ficará pequeno.
Não importa se é:
um banco digital
um supermercado
uma companhia aérea
uma seguradora
um ERP
um sistema COBOL criado em 1989
Todos crescem.
Mais usuários.
Mais dados.
Mais integrações.
Mais consultas.
Mais relatórios.
Mais APIs.
Mais inteligência artificial.
Mais tudo.
O curioso é que o programa COBOL continua praticamente igual.
O que muda é o mundo ao redor.
O Primeiro Erro dos Iniciantes
O iniciante normalmente acredita que desempenho significa:
"Comprar um servidor maior."
Isso funciona...
...até deixar de funcionar.
Imagine uma biblioteca.
Você pode comprar uma mesa maior.
Depois uma sala maior.
Depois um prédio maior.
Mas chega um momento em que o problema não é mais o tamanho do prédio.
É a organização dos livros.
Com bancos de dados acontece exatamente isso.
O Computador Não é o Gargalo
Essa talvez seja uma das maiores descobertas da carreira.
Na maioria dos grandes ambientes, CPU não é o primeiro problema.
Os verdadeiros inimigos costumam ser:
SQL ruim
índices mal projetados
bloqueios
espera por disco
leitura desnecessária
cache inexistente
excesso de conexões
modelo de dados inadequado
programas fazendo milhares de acessos repetidos
É como tentar atravessar a galáxia usando um foguete com o freio de mão puxado.
Primeira Lei Galáctica do Bellacosa
Nunca compre hardware antes de descobrir onde está o gargalo.
Os mestres do desempenho investigam.
Não adivinham.
Capítulo 2 — Scale Up: Alimentando o Dragão
A primeira técnica chama-se Vertical Scaling.
Ou simplesmente:
Scale Up.
Imagine um servidor.
Ele possui:
8 CPUs
64 GB RAM
2 TB SSD
O sistema cresce.
A solução mais simples é trocar por outro servidor.
Agora temos:
64 CPUs
1 TB RAM
40 TB NVMe
Nada muda para o programador.
Os programas COBOL continuam funcionando.
O endereço do Db2 continua igual.
O CICS nem percebe.
É como trocar uma Kombi por um caminhão.
Vantagens
É simples.
É rápido.
Não exige alterar programas.
Não exige redistribuir dados.
Não exige reescrever aplicações.
Mas existe um problema...
Não existe computador infinito.
Mais cedo ou mais tarde você chega ao maior equipamento disponível.
E então?
Curiosidade Galáctica
Os mainframes IBM são praticamente os campeões mundiais do Scale Up.
Eles conseguem crescer verticalmente em níveis que servidores convencionais dificilmente alcançam.
É uma das razões pelas quais bancos e seguradoras continuam utilizando IBM Z.
Capítulo 3 — Scale Out: Construindo uma Frota Espacial
Agora imagine outra filosofia.
Ao invés de um computador gigantesco...
Temos cem computadores menores.
Todos trabalhando juntos.
Esse é o Horizontal Scaling.
Também chamado:
Scale Out.
Agora o banco não mora em apenas uma máquina.
Ele mora em várias.
É como transformar um único cargueiro imperial em uma frota inteira.
Onde isso aparece?
MongoDB
Cassandra
CockroachDB
Yugabyte
Redis Cluster
ElasticSearch
Kafka
Netflix
Amazon
Todos trabalham distribuindo carga.
A vantagem
Quando precisa crescer...
Basta adicionar mais nós.
A desvantagem
Tudo fica absurdamente mais complicado.
Agora aparecem palavras assustadoras.
Leader Election.
Consensus.
Replication.
Consistency.
Split Brain.
Network Partition.
Failover.
Latência.
É aqui que muitos arquitetos passam a dormir menos.
Easter Egg nº 1
Assim como Marvin, o robô depressivo do Guia do Mochileiro, muitos bancos distribuídos também passam boa parte do tempo "pensando" se todos os nós ainda concordam entre si.
Essa conversa silenciosa entre servidores é muito mais frequente do que imaginamos.
Capítulo 4 — Replicação: Clones Não São Ficção Científica
Imagine que existe apenas um banco.
Todo mundo consulta.
Todo mundo grava.
Logo ele fica sobrecarregado.
Então surge uma ideia genial.
Copiar o banco.
Criamos:
Banco Principal
↓
Replica 1
Replica 2
Replica 3
Agora milhões de usuários podem consultar as réplicas.
Enquanto apenas um servidor recebe gravações.
O segredo
Na maioria dos sistemas:
Leitura representa mais de 90%.
Escrita representa apenas uma pequena parcela.
Então distribuir leituras faz enorme diferença.
Tipos
Leader-Follower
Primary-Replica
Multi-Leader
Cada um possui vantagens diferentes.
Curiosidade
Em muitos bancos digitais brasileiros, milhões de consultas de saldo são atendidas por réplicas, preservando o banco principal para as operações financeiras.
Capítulo 5 — Sharding: Dividindo a Galáxia
Imagine uma tabela.
CLIENTES
2 bilhões de registros.
Não cabe mais.
Então fazemos algo brilhante.
Dividimos.
Clientes A-H
Clientes I-P
Clientes Q-Z
Ou:
Sul
Sudeste
Nordeste
Centro-Oeste
Norte
Cada servidor guarda apenas parte do universo.
Esse processo chama-se Sharding.
O desafio
Como descobrir em qual servidor determinado cliente está?
Entra em cena:
Hash.
Range.
Geo.
Tenant.
UUID.
Essa escolha parece simples.
Na prática pode definir o sucesso ou o fracasso de toda uma arquitetura.
Capítulo 6 — Cache: A Memória Fotográfica
Imagine uma página mostrando um produto.
Milhões consultam.
Pouquíssimos alteram.
Por que perguntar ao banco toda vez?
Melhor guardar em memória.
É isso que Redis faz.
É isso que Memcached faz.
É exatamente o mesmo princípio dos Buffer Pools do Db2.
Guardar o que é usado frequentemente para evitar acessar o disco.
Curiosidade Mainframe
Muitos iniciantes descobrem Redis antes de descobrirem Buffer Pools.
Na prática...
Os Buffer Pools do Db2 já aplicam esse conceito há décadas.
Mudam as tecnologias.
Os princípios permanecem.
Capítulo 7 — Read/Write Splitting
Outra técnica elegante.
Toda escrita vai para o servidor principal.
Toda leitura vai para as réplicas.
INSERT
↓
Primary
SELECT
↓
Replica
Resultado?
Muito menos carga.
Muito mais desempenho.
Capítulo 8 — Connection Pool
Abrir conexão custa caro.
Muito caro.
Imagine mil usuários.
Cada um abre.
Fecha.
Abre.
Fecha.
Abre.
Fecha.
O banco enlouquece.
Connection Pool mantém conexões abertas.
As aplicações apenas reutilizam.
É como um elevador.
Ninguém constrói um elevador novo toda vez que quer subir um andar.
Capítulo 9 — Índices: O Índice do Guia do Mochileiro
Imagine procurar uma palavra em um livro de mil páginas.
Sem índice.
Você folheia tudo.
Com índice.
Vai direto para a página.
É exatamente isso que um índice faz.
Mas cuidado
Todo índice precisa ser atualizado.
Mais índices significam:
INSERT mais lento.
UPDATE mais lento.
DELETE mais lento.
Existe equilíbrio.
Easter Egg nº 2
No universo de Douglas Adams existe um peixe chamado Babel Fish.
No universo dos bancos existe algo parecido.
Chama-se Índice.
Ele traduz bilhões de registros em poucos milissegundos.
Capítulo 10 — Arquivamento
Nem tudo precisa permanecer no banco principal.
Pedidos de dez anos atrás.
Logs antigos.
Eventos históricos.
Podem ir para armazenamento frio.
S3.
Glacier.
Arquivos históricos.
No mainframe, tabelas particionadas e estratégias de arquivamento mantêm o ambiente produtivo enxuto sem perder a rastreabilidade.
Capítulo 11 — Otimização de SQL
Talvez o maior superpoder de todos.
Um SQL ruim pode consumir minutos.
O mesmo SQL otimizado pode responder em milissegundos.
Ferramentas como EXPLAIN PLAN, Visual Explain e o EXPLAIN do Db2 revelam como o otimizador "pensa". Ler um plano de acesso é quase como acompanhar um mapa estelar: você enxerga por onde a consulta está viajando, onde ela desperdiça energia e onde encontra atalhos.
Pequenas mudanças fazem enorme diferença:
evitar
SELECT *filtrar cedo
usar índices adequados
reduzir JOINs desnecessários
manter estatísticas atualizadas com
RUNSTATSreorganizar tabelas quando necessário com
REORG
Muitas vezes, um único índice ou uma condição de busca mais seletiva elimina milhões de leituras de páginas.
Capítulo 12 — Database Federation
Existe uma diferença importante entre dividir dados e dividir responsabilidades.
No Sharding, uma mesma tabela é repartida.
Na Federação, cada domínio possui seu próprio banco.
Financeiro.
RH.
CRM.
Logística.
Cada equipe evolui independentemente.
É o equivalente arquitetural de uma federação planetária: cada planeta governa seus próprios assuntos, mas todos cooperam quando necessário.
Capítulo 13 — Bancos Distribuídos: A Federação Interplanetária
Sistemas como Cassandra, CockroachDB, YugabyteDB e DynamoDB nasceram para funcionar em múltiplas regiões geográficas.
Eles já incorporam mecanismos para:
replicação automática;
tolerância a falhas;
eleição de líderes;
sincronização entre nós;
recuperação após falhas;
distribuição transparente dos dados.
A ideia é que a perda de um servidor — ou até de um data center inteiro — não interrompa o serviço.
É um objetivo ambicioso e exige algoritmos sofisticados, como Raft e Paxos, que coordenam o consenso entre máquinas espalhadas pelo mundo.
O Que Isso Tem a Ver com COBOL?
Aqui está o grande segredo.
Muitos iniciantes acreditam que essas discussões pertencem apenas ao universo da nuvem.
Não pertencem.
Um programa COBOL faz:
EXEC SQL
SELECT ...
END-EXEC.
Ele não sabe se o dado veio:
do servidor principal;
de uma réplica;
de um cache;
de uma partição;
de um cluster distribuído.
Quem decide isso é a arquitetura.
É por isso que um bom programador COBOL não estuda apenas a linguagem. Ele entende como o ecossistema inteiro funciona.
O Paralelo com o IBM Z
No IBM Z, muitos desses conceitos existem há décadas, ainda que com nomes diferentes.
Os Buffer Pools funcionam como um cache inteligente.
O Parallel Sysplex permite múltiplas imagens do z/OS trabalhando juntas.
O Data Sharing do Db2 distribui a carga entre membros do grupo.
Ferramentas de replicação sincronizam bancos locais e remotos.
WLM (Workload Manager) distribui recursos conforme a prioridade do negócio.
Ou seja, quando alguém fala em "arquitetura moderna", um veterano de mainframe costuma sorrir discretamente. Diversas dessas ideias já eram aplicadas em ambientes IBM muito antes de se tornarem populares na computação em nuvem.
As Doze Ferramentas do Mochileiro de Banco de Dados
Antes de encerrar sua viagem, coloque estes itens na mochila:
Scale Up — quando um servidor maior resolve.
Scale Out — quando vários servidores trabalham juntos.
Replicação — distribua leituras e aumente a disponibilidade.
Sharding — divida dados gigantes em partes administráveis.
Cache — mantenha o que é mais usado perto do processador.
Read/Write Splitting — especialize quem lê e quem grava.
Connection Pooling — reutilize conexões, não desperdice recursos.
Índices Inteligentes — acelere buscas sem exagerar.
Arquivamento — mantenha o banco principal enxuto.
SQL Otimizado — o ganho mais barato e frequentemente o mais impactante.
Federação — separe domínios de negócio.
Bancos Distribuídos — pense globalmente quando o negócio exigir.
Curiosidades Galácticas
O primeiro gargalo raramente é a CPU; na maioria das vezes, é uma decisão arquitetural tomada anos antes.
O Db2 possui um dos otimizadores de consultas mais sofisticados do mercado, capaz de escolher automaticamente entre diferentes planos de acesso.
Em muitos sistemas corporativos, mais de 90% das operações são leituras, justificando o uso intenso de réplicas e caches.
Um índice pode acelerar uma consulta em milhares de vezes, mas também aumentar o custo de cada atualização da tabela.
Grandes empresas costumam combinar várias dessas técnicas simultaneamente: cache, replicação, particionamento, arquivamento e otimização de consultas trabalham em conjunto.
Última Página do Guia
No fim da jornada, o Padawan pergunta ao Mestre Bellacosa:
— Afinal... qual é a melhor técnica de escalabilidade?
O mestre sorri, toma mais um gole de café e responde:
— A melhor técnica é descobrir primeiro qual problema você realmente tem. Não existe algoritmo mágico, servidor infinito ou banco de dados perfeito. Existe observação, medição, entendimento da carga de trabalho e escolhas conscientes.
O Padawan olha para o 3270, vê o Db2 respondendo em poucos milissegundos e finalmente compreende.
Escalar um banco de dados não é construir o maior computador da galáxia.
É construir uma arquitetura capaz de continuar funcionando quando a galáxia inteira decidir acessá-la ao mesmo tempo.
E, como diria o Guia do Viajante das Galáxias, nunca se esqueça da sua toalha. No universo da engenharia de software, ela pode não limpar Buffer Pools nem reorganizar índices, mas certamente lembrará você de manter a calma enquanto procura o verdadeiro gargalo escondido entre bilhões de registros.
