Recursos costumavam ser caros. Recursos costumavam ser escassos. Provisionar recursos costumava ser demorado. Sendo assim, fazia sentido colocar o consumo de recursos no topo da lista quando se falava em desempenho de banco de dados.

Esses dias acabaram.

Com mais de 80% dos bancos de dados executados em ambientes virtuais, em que o hardware é cada dia mais comoditizado, o acesso a recursos físicos (CPU, memória, rede e disco) sempre que necessário é muito mais fácil. Na verdade, a Lei de Moore prevê que os avanços da tecnologia serão duplicados a cada dois anos. Bem, a maioria dos recursos físicos está certamente seguindo essa previsão, ou melhor:

• Evolução da CPU: A contagem de transistores em 2011 atingiu 2,6 milhões, subindo de 2.300 em 1971;
• Disponibilidade de memória: Limites práticos definem esse número para cerca de 256 TB. Você se lembra de quando 64 KB era fantástico?
• Largura de banda da rede: A Lei de Keck e a Lei da Fotônica de Butter preveem o crescimento da largura de banda de rede mais rápido do que o processamento, quase que dobrando a cada nove meses;
• Velocidade de disco: Com a chegada da tecnologia SSD, o acesso a armazenamento de disco rápido e abundante (bits persistidos) subiu significativamente, mas talvez não com os enormes avanços de outros recursos físicos.

Esses são apenas alguns exemplos, já que há muitas leis disponíveis que modelam o avanço da tecnologia. Independentemente das leis que estão estabelecidas, não se pode negar que o poder e os recursos da computação estão crescendo a taxas extraordinárias, e que estão ficando muito mais baratos. Um mundo de recursos físicos práticos ilimitados disponíveis para os nossos bancos de dados no futuro próximo é tão estranho?

Meramente como exercício mental, digamos que seja o mundo em que vivemos hoje. Temos acesso ilimitado a recursos físicos e, graças à virtualização, ele é dinâmico (acesso instantâneo quando necessário) e automatizado. Como os limites práticos não existem, você não gostaria que sua infraestrutura (hipervisor) alocasse automaticamente os recursos conforme a necessidade? Sem mais alertas às duas da manhã porque alguém deu início a um enorme relatório durante seu carregamento de ETL que acabou arruinando a CPU e a memória. Então, o que vem a seguir?

Processos paralisados em estado executável pertencem ao passado. Não há mais esperas de sinais. Tempo de preparação da CPU? Já era! O tamanho da fila do disco será drasticamente reduzido, se não eliminado de uma vez. Todos os bancos de dados passam a ser na memória, todas as páginas e blocos residem em cache para todos os objetos e instruções analisadas. As classificações ocorrem estritamente na memória. Determinar quando se deve analisar um plano de execução novamente agora é diferente. As estruturas de custos de paralelismo foram reformuladas em todos os principais otimizadores RDBMS.

Por que não paralelizar a execução de todas as instruções SQL se a sobrecarga associada ao processamento que usa vários threads mais o custo da execução do thread mais longo não excedem um único threading? A própria otimização baseada em custos (CBO, Cost-Based Optimization) é totalmente reformulada (provavelmente, seja necessário algum TLC mesmo no mundo do banco de dados, já que agora ele realmente existe).

Também podemos ter muito mais potência por muito menos dinheiro relativo do que há dez, cinco ou um ano. Graças à virtualização, o acesso é rápido e fácil. O reequilíbrio dinâmico da carga de trabalho da VM levará automaticamente à capacidade de realocação dinâmica de recursos no nível do sistema operacional convidado a curto prazo.

Como profissionais de banco de dados, o tempo que dedicamos a desempenho e ajuste acabou! Como assim? Não é isso? Ah, sim, você tem razão. Há muitos outros aspectos de desempenho e ajuste que estão fortemente associados aos recursos físicos. Alguns exemplos são: ajuste de consultas, lógica de lote transacional, dependências externas transacionais, modelagem de dados, indexação (mas não indexação em excesso), concorrência de diversos threads (travamento/bloqueio), tabelas de base durante a conexão, etapas de planos ineficientes etc. Lembre-se de que ineficiências e contenção ainda podem causar problemas, mesmo que os recursos sejam removidos como uma restrição.

Onde quero chegar com este exercício? Todas as pistas apontam para um futuro em que os recursos físicos continuarão diminuindo como a principal restrição em nossa infraestrutura de banco de dados. Defender a tese de que o hardware é culpado pelos problemas de desempenho seria muito simplista. Há outros fatores em jogo, como modelos de licenciamento de software (se baseado no processador), redução de pegadas de carbono, restrições de concorrência etc. É bom imaginar um mundo onde não haja tanta ênfase nas restrições de recursos físicos. Afinal, esse mundo pode estar se aproximando rapidamente.