Cuidar do espaço em disco

– Mantenha o espaço em disco do banco de dados abaixo de 5 GB para aumentar a probabilidade dos dados serem acessados em memória RAM. Isto melhora o desempenho da aplicação e torna a execução das rotinas de backup mais rápida.

– Exclua dados desnecessários.

– Segmente bases para cada tipo de informação. Por exemplo:

Informações mais recentes como histórico de pedidos dos últimos 12 meses, na base principal e dados menos acessados, como histórico de pedidos de mais de um ano, na base adicional.

– Particione dados em várias bases usando determinados critérios.

Exemplo:

Base A com informações de usuários

Base B com informações de pedidos

Esse método chamado sharding, consiste em criar uma lógica de programação que decide para qual base devem ser direcionadas as consultas.

Nota: neste caso, o método de conexão inicial dos scripts é algo como InformaBancoDadosPara (ID_Usuario).

Otimizar o desempenho

– Realize manutenções periodicamente, seguindo as instruções de cada banco de dados:

  • Optimize para MySQL/MariaDB
  • Vacuum para PostgreSQL
  • Reindex para PostgreSQL e SQL Server

– Crie e mantenha índices para as colunas mais utilizadas. Uma pesquisa em uma coluna não indexada exige mais processamento e demora mais para exibir os resultados do que uma pesquisa indexada;

– Use o comando “explain” para analisar as consultas SQL realizadas no banco. Com este comando é possível descobrir se alguma coluna precisa ser indexada ou se uma tabela muito grande está causando a demora na apresentação do resultado da pesquisa;

– Utilize ferramentas de “query caching”, pois elas buscam dados na memória e não no disco rígido;

– Prefira queries como “select coluna1, coluna2.. from”, que têm menos impacto no processamento do banco.

– Você pode restringir o resultado das pesquisas com “where” e “limit” para buscar somente os dados necessários..

Distribuir a carga em múltiplos bancos

Ajuste a programação separando os métodos de escrita e leitura de dados nos scripts. Isso permite o uso de uma estrutura com replicação master/slave para distribuir a carga das consultas SQL. Nesse modelo, o servidor master pode receber escritas e leituras de dados, enquanto os slaves recebem somente leituras. Uma sugestão, por exemplo, é ter um servidor slave dedicado para geração de relatórios.

O uso dessas técnicas permite prevenir sobrecargas e resulta em um maior controle da aplicação.

Veja também: Preparando bancos de dados para o crescimento.

AVISO LEGAL: Os procedimentos descritos neste documento devem ser executados de acordo com o contexto de cada sistema, de forma a evitar impactos negativos à segurança, disponibilidade, integridade e privacidade de dados. A CentralServer se reserva o direito de modificar a qualquer tempo e sem aviso prévio as informações aqui apresentadas a fim de refletir o lançamento de novos serviços, atualizações físicas e operacionais, e evolução do estado-da-arte da tecnologia.