Quando gerenciamos bancos de dados, deparamo-nos com casos em que o desempenho de um sistema está sendo impactado pela lentidão das queries. Via de regra, esses problemas ocorrem quando a base de dados cresce demasiadamente ou quando existe um elevado número de transações simultâneas.
A solução tradicional para esses casos é o uso de um database cluster. Contudo, essa alternativa tem um custo elevado de licenciamento e manutenção, por isso, só deve ser usada em último caso.
Por outro lado, existem boas práticas de gerenciamento que possibilitam cenários de grande escalabilidade do banco de dados. Veja as recomendações a seguir:
– Cuide do espaço em disco. Reduzir o espaço ocupado aumenta 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.Portanto, exclua dados desnecessários.
– Segmente os dados legados que consiste em criar bases adicionais para guardar os dados menos acessados. Nesse modelo, mantém-se na base principal somente as informações mais recentes (ex.: histórico de pedidos de 2012-2013). Já as informações que vão “esfriando” são passadas para bases adicionais (ex.: histórico de pedidos de 2010-2011, e assim por diante). A nível de aplicação, a pesquisa do “histórico de pedidos” pode trazer os resultados mais recentes, seguidos de um link do tipo “Pesquisar pedidos anteriores a 2012”.
Existe ainda o modelo de particionamento conhecido como sharding. Ele consiste em dividir os dados em várias bases usando determinados critérios (ex.: base A com informações de usuários, base B com informações de pedidos) e criar uma lógica de programação que decida para qual base direcionar as consultas. Quando se usa sharding, o método de conexão inicial dos scripts passa ser algo como InformaBancoDadosPara(ID_Usuario).
– Otimize o desempenho. Execute periodicamente rotinas de manutenção, 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 leva bem mais tempo 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.
– Use técnicas de “query caching” sempre que possível. Dados em memória são acessados mais rapidamente que dados no disco rígido.
– Evite queries que afetam negativamente o desempenho. Não use queries do tipo “select * from” que têm um grande impacto no processamento do banco. Prefira “select coluna1, coluna2 […] from”. Restrinja o resultado das pesquisas com “where” e “limit”. Busque somente os dados realmente necessários.
– Distribua 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, ou balancear, 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 aliadas à flexibilidade da computação em nuvem permite a expansão contínua da capacidade do banco de dados.
Caso deseje avaliar o melhor cenário para crescimento do seu banco de dados, entre em contato com um Especialista em Cloud da CentralServer.
