A utilização de bases de dados sempre foi de suma importância na maioria dos projetos de software. Antes o analista ou desenvolvedor responsável pela base de dados (DBA) tinha simples escolhas para fazer. Agora ficou complexo, pois existe uma infinidade de banco de dados, e cada um com suas particularidades, diferenças e teorias. No final o objetivo é sempre o mesmo: gravar, ler e manter os dados.
Abordaremos nesse artigo o uso de réplicas para melhorar a performance e disponibilidade do banco de dados. Mas quando falamos de performance, se tratando de banco de dados, o assunto é muito abrangente. Não é simplesmente melhorar “JOINS”. Estamos entrando em um universo que envolve a escolha certa do banco de dados para a aplicação, o local físico onde este banco de dados será instalado e como devemos escrever e acessar estes dados.
A escolha do banco de dados é um assunto muito delicado, por se tratar de uma escolha metade técnica e metade pessoal. A maioria das aplicações de pequenas e médias empresas está bem servida rodando em bancos de dados relacionais como MySQL, SQL Server, Oracle e PostgresSQL. Quando existe uma demanda de data science, estas empresas o fazem em paralelo.
A escolha do local físico onde instalar o banco de dados é um tanto quanto óbvia. Provavelmente a primeira coisa que pensamos é colocar este banco de dados em uma máquina dedicada ou na nuvem. Ninguém deveria, nos dias atuais, arriscar deixar a base de dados dentro do ambiente vulnerável da empresa. O local físico onde o banco de dados deve estar tem que ser no mínimo acessível e tolerante a falhas, devendo se reestabelecer automaticamente caso ocorra alguma interrupção.
Melhorias em consultas SQL é um assunto velho e muito debatido em diversos fóruns. Mas é preciso que o analista ou desenvolvedor tenha em mente uma boa estrutura de dados, que permita consultas inteligentes e rápidas. Nos casos de grandes massas de dados e muitos acessos de leitura, é muito importante entender sobre normalização e desnormalização.
A acessibilidade, disponibilidade e contingência são essenciais em quase todas as aplicações, principalmente nas aplicações móveis e empresas de serviço online. Através do console do AWS, podemos melhorar nossa base de dados com uso de réplicas de leitura para ter mais desempenho, réplica Multi-AZ para maior segurança, ou unindo os dois recursos para obter maior desempenho e segurança. Tudo isto pode ser feito sem entender de código ou ter profundos conhecimentos de banco de dados.
Réplica de banco de dados
Atualmente, é de extrema importância entender e utilizar as réplicas de banco de dados, seja para melhorar a performance ou para servir de contingência. Com o aumento da mobilidade, as cargas de acesso a bases de dados cresceu exponencialmente. Replicar a base de dados é quase uma obrigação do desenvolvedor, é praticamente parte necessária para garantir maior acessibilidade e contingência ao sistema como um todo, principalmente sistemas críticos.
Quando uma base de dados é replicada, temos a vantagem de direcionar escritas e leituras. Só com esta pequena modificação, provavelmente podemos ganhar 50% de performance, simplesmente porque o banco de dados de escrita está ocupado somente com as escritas, e o banco de dados de leitura está ocupado somente com as leituras.
Quando temos leituras e escritas na mesma base de dados, muitas vezes temos problemas relacionados à memória e I/O. Imagine um usuário fazendo uma consulta na tabela “transações” em busca de todas as transações de uma loja durante um ano, acessando o banco de dados por meio de um sistema. Se esta consulta demora 0,5 segundos, multiplique por 100 usuários e teremos um banco de dados ocioso por 50 segundos. Neste momento, uma escrita certamente estará esperando, pois boa parte da memória está sendo utilizada para a consulta. Este é um exemplo simples, mas na realidade podemos ter problemas bem mais sérios, chegando até a travar a aplicação.
Para contornar o gargalo da memória, muitos profissionais simplesmente aumentam a capacidade das máquinas. Isto resolve em curto prazo, mas certamente ...
