Replicando DB relacional na nuvem da Amazon

Este artigo discute como podemos melhorar o desempenho, disponibilidade e segurança do PostgreSQL utilizando os recursos da Amazon Aws.

Fique por dentro
Este artigo mostra como melhorar o desempenho, disponibilidade e segurança em bases de dados relacionais utilizando os recursos do Amazon Web Services (AWS). Vamos tratar da importância de fazer réplicas de leitura mostrando as três maneiras comuns de implementar este recurso através da nuvem da Amazon. Este artigo contém informações valiosas para quem deseja garantir disponibilidade, acessibilidade e segurança para seus dados. Além de disponibilidade, você pode aplicar este conhecimento para obter contingência e performance. Estas informações também servem para quem deseja conhecer as ferramentas do AWS e seus recursos direcionados para bancos relacionais.

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."

[...] continue lendo...

Artigos relacionados