Decisão: dimensionamento de servidor

O dimensionamento correto parte do perfil da carga (OLTP, data warehouse, misto) e exige encontrar o gargalo real (CPU, I/O ou RAM). Regra de ouro: o conjunto de dados acessado com frequência (working set) deve caber na RAM; meça primeiro, depois escale, e deixe folga para picos de carga. Esta árvore ajuda a identificar a carga e a escolher o recurso e a direção de escala (vertical/horizontal) com base no gargalo.

Qual é o perfil da sua carga?

O dimensionamento começa pela carga, porque cargas OLTP e analíticas exigem perfis de recursos completamente diferentes. Qual é o trabalho predominante do sistema: muitas transações pequenas e rápidas (OLTP), relatórios/analytics com grandes scans e agregações (DWH), ou uma mistura dos dois? Se não tiver certeza, você precisa medir primeiro.

• OLTP — muitas transações pequenas e curtas (web/aplicação)
• Analytics / data warehouse (DWH) — grandes scans e agregações
• Carga mista, ou não tenho certeza
• Conheço o gargalo; devo escalar vertical ou horizontalmente?

Onde está o gargalo: RAM, I/O ou CPU?

Em OLTP, encontre o gargalo real em vez de adicionar recursos às cegas. Olhe suas métricas: os dados acessados com frequência não cabem na RAM e há muitas leituras de disco (RAM/I/O), a latência/IOPS do disco é insuficiente (I/O), ou os dados já estão em memória, mas a CPU está saturada (CPU)? Escalar o recurso errado desperdiça dinheiro e tempo.

• Os dados acessados com frequência não cabem na RAM; as leituras de disco são altas
• Os dados estão em memória, mas a latência/IOPS do disco é insuficiente (muitas gravações)
• Os dados estão em memória e o disco está bem, mas a CPU está constantemente saturada

Recomendação: meça primeiro, depois dimensione

Comprar hardware com base em palpites quase sempre resulta no tamanho errado. O perfil da carga e o gargalo surgem de métricas reais. Dimensionamento não é palpite, mas uma iteração guiada por medições.

Recomendação: adicione RAM — o working set deve caber na memória

A regra mais crítica de OLTP: os dados e índices acessados com frequência (o working set) devem caber na memória (buffer/cache). Se não couberem, toda consulta vai ao disco, a latência explode e o I/O vira o gargalo. A RAM costuma ser o investimento de maior retorno.

Recomendação: reforce a camada de I/O (IOPS/latência)

Mesmo com os dados em memória, a velocidade do disco é decisiva sob carga com muitas gravações (commit, WAL/redo/binlog, checkpoint). A questão aqui não é capacidade, mas IOPS e latência. A classe de disco errada derruba o sistema apesar de CPU/RAM rápidas.

Recomendação: resolva o gargalo de CPU (consultas primeiro, depois núcleos)

Se a CPU está saturada enquanto os dados estão em memória e o disco está bem, a causa raiz geralmente são consultas ineficientes (planos ruins, índices ausentes, muitas consultas pequenas) ou concorrência excessiva. Reduzir a carga antes de adicionar núcleos costuma ser mais barato e mais eficaz.

Recomendação: analytics/DWH — throughput, paralelismo e escala horizontal

Uma carga de data warehouse consiste em um pequeno número de consultas pesadas que varrem e agregam tabelas grandes. A prioridade aqui não é baixa latência, mas alto throughput de scan, paralelismo e, geralmente, uma arquitetura com escala horizontal.

Princípio geral: vertical vs horizontal + folga + medir primeiro

Como você escala importa tanto quanto qual recurso você escala. A escala vertical (uma máquina maior) é simples, mas tem teto e ponto único de falha; a horizontal (mais máquinas) escala, mas adiciona complexidade. Em todos os casos, deixe folga para picos de carga e valide a decisão com medições.