Reduza o custo do banco de dados e melhore a disponibilidade ao migrar para o AWS Cloud

Digamos que você tenha um aplicativo que usa tabelas de banco de dados para armazenar dados de log e clickstream. Você poderia armazenar seus dados em um banco de dados relacional para facilitar as tarefas de desenvolvimento e gerenciamento. Quando você inicia seu aplicativo, o banco de dados é gerenciável no início, mas vai ganhando centenas de gigabytes por semana. O armazenamento e a recuperação de dados, por si só, estão consumindo 20% de IOPS e CPU na sua instância de banco de dados relacional. Além disso, os aplicativos armazenam documentos XML, JSON e binários nas tabelas do banco de dados, juntamente com os dados transacionais. Dados históricos continuam crescendo a cada mês. Seus custos tradicionais de licenciamento e infraestrutura de banco de dados local estão aumentando, e gerenciar o banco de dados tornou-se um grande desafio. O que você pode fazer?

Neste post, explicamos as estratégias para reduzir os custos do banco de dados e melhorar a disponibilidade à medida que você migra para o AWS Cloud.

Tipos de Banco de Dados

Sistemas de gerenciamento de banco de dados relacionais (RDBMSs, sigla em inglês) estão no centro da maioria dos sistemas de processamento de transações. Armazenar todos os dados em um RDBMS pode:

• Causar problemas de desempenho. Tabelas maiores precisam de mais tempo para consultar os dados. Alto tráfego de leitura/gravação em um conjunto específico de tabelas retarda outras consultas em um banco de dados.
• Aumentar seu custo total de propriedade (TCO, sigla em inglês). Para entregar mais tráfego de leitura/gravação, você precisa dimensionar o banco de dados verticalmente, adicionando mais capacidade de computação e armazenamento. Mesmo que isso seja uma questão de aumento de tráfego de dados sazonal, você precisa fazer grandes investimentos iniciais para atender ao tráfego de aplicativos. Além disso, você não pode reduzir o servidor de banco de dados, o que aumenta seu TCO.
• Em vez de usar apenas o armazenamento de banco de dados relacional, seu aplicativo pode salvar suas informações em armazenamentos de dados criados para fins específicos ao migrar para o AWS. O armazenamento de dados que seu aplicativo usa depende de seu padrão de acesso. Também depende da escala em que você prevê que seus dados aumentem e da facilidade de acesso a eles. Esses tipos de armazenamento de dados, suas finalidades e exemplos de cada um são mostrados na tabela a seguir.

Use esses armazenamentos de dados em sua arquitetura de processamento para melhorar o desempenho e a disponibilidade de seu aplicativo e reduzir custos. Neste post, explicamos como minimizar o TCO de bancos de dados tradicionais locais de alto volume usando os seguintes serviços da AWS:

• DynamoDB
• Amazon S3
• Serviço Amazon de banco de dados realcional (Amazon RDS)

O diagrama a seguir mostra a refatoração de um grande banco de dados relacional em vários armazenamentos de dados, como o DynamoDB e o Amazon S3.

Por dois motivos, essa abordagem é diferente da migração de um banco de dados para um mecanismo de banco de dados (como o Oracle para o PostgreSQL) no Amazon RDS ou no Amazon EC2.

Primeiro, muitas pessoas criam aplicativos que usam mecanismos de banco de dados comerciais. Esses aplicativos podem usar um recurso específico para um mecanismo de banco de dados relacional. O mecanismo pode não estar disponível nos sistemas de banco de dados de código aberto e requer uma quantidade significativa de retrabalho. Manter o mesmo mecanismo de banco de dados relacional com uma pegada menor na arquitetura de estado final ajuda a migrar para a nuvem mais rapidamente. Dessa forma, você também minimiza a quantidade de alterações necessárias no aplicativo ou na camada do banco de dados. A migração de banco de dados semelhante é sempre mais fácil, pois os códigos e objetos do banco de dados são migrados usando ferramentas de migração de banco de dados nativas ou o Database Migration Service (DMS) da AWS.

Em segundo lugar, nessa abordagem, sugerimos que você identifique uma parte do banco de dados que pode ser migrada para o Amazon S3 e o Amazon DynamoDB. Você pôde ver isso no diagrama anterior. Isso ajuda você a resolver os problemas de desempenho e TCO causados ​​por dados que crescem rapidamente em logs, dados de fluxo de cliques, objetos grandes e afins.

No restante deste post, discutimos a abordagem em três partes:

• Movendo um subconjunto do banco de dados relacional para o Amazon EC2 ou o Amazon RDS.
• Movendo objetos grandes do banco de dados relacional para o Amazon S3.
• Movendo um subconjunto do banco de dados relacional para um armazenamento de dados NoSQL, como o DynamoDB.

Movendo um subconjunto de dados para o Amazon EC2 ou o Amazon RDS

A parte mais fácil dessa abordagem é identificar a parte do banco de dados que você deseja manter inalterada. Você pode migrar essa parte do banco de dados para o mesmo mecanismo de banco de dados no Amazon RDS ou pode executá-lo como um banco de dados auto gerenciado no Amazon EC2.

O Amazon RDS é um serviço gerenciado que facilita a configuração, operação e dimensionamento de um banco de dados relacional na nuvem. O Amazon RDS realiza automaticamente o trabalho envolvido na configuração de um banco de dados relacional, desde o provisionamento da capacidade de infraestrutura até a instalação do software de banco de dados. O Amazon RDS também cuida de tarefas administrativas comuns, como realizar backups e aplicar patches ao software que alimenta seu banco de dados. Com várias implantações da Zona de Disponibilidade, o Amazon RDS gerencia a replicação de dados síncronos em zonas de disponibilidade com failover automático. Ao migrar seu banco de dados para o Amazon RDS, você pode economizar em TCO, reduzir a sobrecarga operacional e atingir níveis mais altos de disponibilidade e confiabilidade para seu banco de dados relacional.

Para determinar qual parte do seu banco de dados deve permanecer inalterada, considere estas questões:

• A maioria dos dados no conjunto é um dado transacional que é lido e escrito frequentemente como linhas únicas ou grandes números de pequenos lotes?
• O processamento e armazenamento desses dados usa recursos específicos do banco de dados, como opções de banco de dados?
• O código processual que foi escrito para este conjunto de dados é difícil de alterar? Por exemplo, milhões ou linhas de código PL / SQL no banco de dados Oracle.
• O código da interface do aplicativo e do usuário que foi escrito para esse conjunto de dados é difícil de alterar?
• Seu aplicativo emite consultas SQL complexas contra esses dados e associa dados de várias tabelas?
• Seu aplicativo emite consultas SQL complexas contra esses dados e associa dados de várias tabelas?
• As definições de tabela e entidade (o número de colunas, tipos de dados e similares) em seu esquema de banco de dados permanecerão fixas à medida que seu aplicativo evoluir? Você gostaria de impor restrições em diferentes tabelas em seu modelo de dados ao armazenar os dados?

Se você respondeu “Sim” a todas ou à maioria das perguntas anteriores sobre um subconjunto de seu banco de dados relacional, esse subconjunto é mais adequado para ser migrado para o banco de dados relacional no Amazon RDS ou no Amazon EC2. O subconjunto de dados que você identifica permanece inalterado e pode ser a maioria, digamos 50% a 60% do seu banco de dados. Para determinar o tamanho desse subconjunto de dados, os administradores de banco de dados ou desenvolvedores podem consultar o dicionário de dados do banco de dados para obter o tamanho dos dados que seriam migrados para o Amazon RDS ou o Amazon EC2.

Para migrar os dados, você pode usar as ferramentas nativas do seu mecanismo de banco de dados, o AWS DMS, a Ferramenta de conversão de esquemas da AWS ou ferramentas de terceiros. O AWS DMS suporta migrações de bancos de dados homogêneos e heterogêneos. Ele suporta migrações de carga total, únicas ou migrações contínuas de bancos de dados para ajudar a reduzir o tempo de inatividade do aplicativo. Para obter mais informações sobre como migrar soluções comerciais de banco de dados para a AWS usando ferramentas nativas e o AWS DMS, consulte Práticas recomendadas para o AWS Database Migration Service.

Movendo objetos grandes de um banco de dados relacional para o Amazon S3

Muitos clientes projetam aplicativos que armazenam dados de Objeto Grande de Caracteres (CLOB) e Binary Large Object (BLOB) em tabelas de banco de dados relacionais. É natural fazer isso porque a maioria das soluções de banco de dados relacional permite esses tipos de dados e fornece maneiras de armazenar e acessar objetos grandes (LOBs).

Armazenar CLOBs e BLOBs em um banco de dados inclui os seguintes benefícios:

• Consistência point-in-time. Quando você restaura um banco de dados para um horário específico, todos os dados e objetos retornam ao mesmo estado em que estavam anteriormente.
• Facilidade de acesso.
• Segurança e controles de acesso.

Se seu aplicativo estiver gerando esses LOBs em gigabytes por segundo, o armazenamento e o processamento dos dados em um banco de dados relacional podem consumir uma grande quantidade de rendimento de rede, E/S de disco, CPU e memória. Para aplicativos que podem tolerar a latência transacional em segundos durante o armazenamento e a recuperação de objetos grandes, o descarregamento desses dados para o Amazon S3 pode melhorar o desempenho e a disponibilidade. O Amazon S3 oferece acesso a uma infraestrutura de armazenamento de dados altamente dimensionável, confiável, rápida e barata. Como o Amazon S3 é altamente escalonável, você pode começar pequeno e desenvolver seu aplicativo como desejar, sem comprometer o desempenho ou a confiabilidade.

Para obter a consistência point-in-time para LOBs, é necessário modificar a lógica do aplicativo para armazenar o ID da versão do objeto modificado no Amazon S3 juntamente com a transação no banco de dados relacional. Essa alteração no aplicativo é mínima em comparação com a economia de TCO e a melhoria de desempenho do aplicativo geral.

Movendo dados históricos para o Amazon S3

Muitos bancos de dados grandes contêm dados históricos que geralmente não são lidos, mas consomem armazenamento e ciclos da CPU. Talvez seja necessário reter esses dados, por exemplo, para fins de conformidade e regulamentação. Em vez de manter esses dados em um banco de dados relacional, você pode criar arquivos compactados a partir de dados em seu banco de dados relacional em um determinado período e transferi-los para o Amazon S3 ou o Amazon S3 Glacier.

Quando seu aplicativo precisar de acesso aos dados nesses arquivos, você poderá usar os recursos do Amazon S3, como o Amazon S3 Select ou o Amazon S3 Glacier Select. Essa abordagem pode reduzir significativamente os custos de armazenamento e recuperação de dados, proporcionando durabilidade (proteção de dados de longo prazo) de 99,999999999% e disponibilidade (tempo de atividade do sistema) de 99,99% em um determinado ano.

Movendo um subconjunto de dados para um repositório de dados NoSQL, como o DynamoDB

Como última parte da estratégia geral, considere o DynamoDB para armazenar um subconjunto de dados de seu banco de dados relacional. O Amazon DynamoDB é um banco de dados NoSQL totalmente gerenciado que suporta estruturas de dados de valores-chave e documentos. Ele permite descarregar as cargas administrativas de operação e dimensionamento de um banco de dados distribuído, para que você não precise se preocupar com provisionamento de hardware, ajustes e configuração, replicação, correção de software ou escalonamento de cluster.

Para identificar os dados que podem ser armazenados em um banco de dados NoSQL, como o DynamoDB, considere os seguintes fatores:

• Os dados são gravados com frequência ou em alta velocidade?
• Os registros individuais têm números variáveis ​​de campos e atributos que não podem ser determinados como parte do design do esquema?
• Os dados são gravados independentemente de outras tabelas no esquema?
• Os dados podem ser lidos como eventualmente consistentes? A consistência eventual é quando os dados gravados no banco de dados podem não estar disponíveis imediatamente para leituras e, eventualmente, estarão disponíveis para leitura em segundos.
• Suas tabelas de banco de dados relacional armazenam documentos e aplicativos JSON que você pode consultar com consultas simples?
• Você precisa de um armazenamento de dados que suporte transações ACID?
• Você precisa replicar as tabelas do banco de dados globalmente (em outras palavras, através de mais de uma região da AWS) para atender sua base de usuários global com baixa latência?

Se você responder “Sim” a todas ou à maioria das perguntas anteriores para um subconjunto de seu banco de dados relacional, esse subconjunto de dados será mais adequado para ser migrado para um repositório de dados NoSQL, como o Amazon DynamoDB.

Além das considerações anteriores, não mova dados para um armazenamento de dados NoSQL que:

• É agregado de várias tabelas para a interface do usuário do seu aplicativo.
• É pesadamente usado como fonte de processamento analítico online (OLAP).
• É tratado como dados do tipo BLOB.
• Tem registros com tamanhos individuais maiores que 400 KB.
• Exigiria quantidades significativas de alterações no aplicativo.

Entender a condição do seu armazenamento de dados ajuda a decidir quais dados mover para o NoSQL e quais dados você deve continuar armazenando em um banco de dados relacional.

Entender a condição do seu armazenamento de dados ajuda a decidir quais dados mover para o armazenamento do NoSQL e quais dados você deve continuar armazenando em um banco de dados relacional. Depois de tomar a decisão de mover dados relevantes para um armazenamento de dados NoSQL, projetar um modelo de dados no DynamoDB é essencial para o desempenho com o crescimento futuro dos dados. O DynamoDB distribui dados em uma tabela em várias partições em diferentes servidores físicos. Esses dados são distribuídos com base no valor x da chave primária (a chave de partição) de uma tabela no DynamoDB. Dependendo do padrão de leitura/gravação de dados, você deve selecionar uma chave de partição que permita ao DynamoDB distribuir seus dados uniformemente pelas partições. Isso melhora o rendimento de leitura/gravação de suas tabelas. Para obter mais informações sobre como escolher a chave de partição correta no DynamoDB, consulte Escolhendo a chave de partição correta do DynamoDB.

Depois de concluir o design da tabela do DynamoDB, você pode usar o AWS DMS para migrar dados do banco de dados relacional para o DynamoDB. Para obter mais informações, consulte o Serviço de Migração de Banco de Dados AWS e o Amazon DynamoDB: O que você precisa saber.

Além dos benefícios mencionados anteriormente nesta seção, ao migrar um subconjunto de dados de seu banco de dados relacional para o DynamoDB, você paga apenas pela capacidade de leitura/gravação que provisiona para sua tabela e obtém economias de custo significativas. Além disso, agora você pode usar o DynamoDB sob demanda, o que permite atender milhares de solicitações por segundo em uma tabela do DynamoDB sem planejamento de capacidade. Para obter informações, consulte Amazon DynamoDB Preços.

Sumário

Nesta postagem do blog, você leu sobre a divisão de seus bancos de dados monolíticos em armazenamentos de dados criados para fins específicos à medida que os migra para a AWS. Você pode obter economias significativas de licenciamento e custo de infraestrutura, além de maior disponibilidade, identificando o armazenamento de dados correto para seus dados.

Se você tiver comentários sobre essa postagem do blog, poste-os na seção Comentários abaixo. Se você tiver dúvidas sobre a implementação das soluções aqui, você pode deixá-las na seção Comentários também.

Sobre os autores

Ejaz Sayyed é arquiteto de soluções para parceiros na equipe Global System Integrator do Amazon Web Services. Suas áreas de foco incluem serviços de banco de dados da AWS, bem como migrações de banco de dados e de data warehouse na AWS.

Karthik Thirugnanasambandam é um arquiteto de soluções para parceiros na Amazon Web Services. Ele trabalha com grandes integradores de sistemas globais na adoção da AWS Cloud. Ele é um DevOps e um entusiasta sem servidor. Quando não está trabalhando, ele gosta de ler e passar tempo com sua família.