Gestão de bases de dados em várias nuvens: arquiteturas, exemplos de utilização e práticas recomendadas

Last reviewed 2025-04-30 UTC

Este documento descreve as arquiteturas de implementação, os exemplos de utilização e as práticas recomendadas para a gestão de bases de dados em várias nuvens. Destina-se a arquitetos e engenheiros que concebem e implementam aplicações com estado em várias nuvens.

As arquiteturas de aplicações multinuvem que acedem a bases de dados dependem do exemplo de utilização. Nenhuma arquitetura de aplicação com estado único pode suportar todos os exemplos de utilização em várias nuvens. Por exemplo, a melhor solução de base de dados para um exemplo de utilização de expansão na nuvem é diferente da melhor solução de base de dados para uma aplicação que é executada em simultâneo em vários ambientes de nuvem.

Para nuvens públicas, como a Google Cloud, existem várias tecnologias de base de dados que se adequam a exemplos de utilização de várias nuvens específicos. Para implementar uma aplicação em várias regiões numa única nuvem pública, uma opção é usar uma base de dados multirregional gerida pelo fornecedor da nuvem pública, como o Spanner. Para implementar uma aplicação que seja portátil em nuvens públicas, uma base de dados independente da plataforma pode ser uma escolha melhor, como o AlloyDB Omni ou o PostgreSQL.

Este documento apresenta uma definição de uma aplicação de base de dados com estado, seguida de uma análise de casos de utilização de bases de dados em várias nuvens. Em seguida, apresenta uma categorização detalhada do sistema de base de dados para arquiteturas de implementação em várias nuvens com base nos exemplos de utilização.

O documento também apresenta uma árvore de decisão para selecionar bases de dados, que descreve os principais pontos de decisão para selecionar uma tecnologia de base de dados adequada. Conclui com uma discussão sobre as práticas recomendadas para a gestão de bases de dados em várias nuvens.

Principais termos e definições

Esta secção fornece uma terminologia e define a aplicação de base de dados com estado genérica que é usada neste documento.

Terminologia

• Nuvem pública. Uma nuvem pública oferece infraestrutura (geralmente global) multi-inquilino e serviços que os clientes podem usar para executar as respetivas cargas de trabalho de produção. Google Cloud é uma nuvem pública que oferece muitos serviços geridos, incluindo o GKE, o GKE Enterprise e as bases de dados geridas.
• Nuvem híbrida. Uma nuvem híbrida é uma combinação de uma nuvem pública com um ou mais centros de dados no local. Os clientes de nuvem híbrida podem combinar os respetivos serviços nas instalações com serviços adicionais fornecidos por uma nuvem pública.
• Multicloud. Uma multicloud é uma combinação de várias nuvens públicas e centros de dados no local. Uma nuvem híbrida é um subconjunto de multinuvem.
• Local de implementação. Uma localização de infraestrutura é uma localização física que pode implementar e executar cargas de trabalho, incluindo aplicações e bases de dados. Por exemplo, em Google Cloud, as localizações de implementação são zonas e regiões. A um nível abstrato, uma região ou uma zona da nuvem pública e um centro de dados nas instalações são localizações de implementação.

Aplicações de base de dados com estado

Para definir exemplos de utilização de várias nuvens, é usada uma arquitetura de aplicação de base de dados com estado genérica neste documento, conforme mostrado no diagrama seguinte.

O diagrama mostra os seguintes componentes:

• Base de dados. Uma base de dados pode ser uma instância única, várias instâncias ou uma base de dados distribuída, implementada em nós de computação ou disponível como um serviço gerido na nuvem.
• Serviços de aplicações. Estes serviços são combinados como uma aplicação que implementa a lógica empresarial. Os serviços de aplicações podem ser qualquer um dos seguintes:
  • Microsserviços no Kubernetes.
  • Processos de grão grosso executados numa ou mais máquinas virtuais.
  • Uma aplicação monolítica numa máquina virtual grande.
  • Código sem servidor em funções do Cloud Run ou Cloud Run. Alguns serviços de aplicações podem aceder à base de dados. É possível implementar cada serviço de aplicação várias vezes. Cada implementação de um serviço de aplicação é uma instância desse serviço de aplicação.
• Clientes de aplicações. Os clientes de aplicações acedem à funcionalidade fornecida pelos serviços de aplicações. Os clientes de aplicações podem ser um dos seguintes:
  • Clientes implementados, em que o código é executado num computador, num portátil ou num telemóvel.
  • Clientes não implementados, em que o código do cliente é executado num navegador. As instâncias de cliente da aplicação acedem sempre a uma ou mais instâncias do serviço de aplicação.

No contexto de uma discussão sobre bases de dados multinuvem, a abstração arquitetónica de uma aplicação com estado consiste numa base de dados, em serviços de aplicações e em clientes de aplicações. Numa implementação de uma aplicação, os fatores, como a utilização de sistemas operativos ou as linguagens de programação usadas, podem variar. No entanto, estes detalhes não afetam a gestão de bases de dados multinuvem.

Filas e ficheiros como serviços de armazenamento de dados

Existem muitos recursos de persistência disponíveis para os serviços de aplicações persistirem dados. Estes recursos incluem bases de dados, filas e ficheiros. Cada recurso de persistência fornece modelos de dados de armazenamento e padrões de acesso especializados para estes modelos. Embora as filas, os sistemas de mensagens e os sistemas de ficheiros sejam usados pelas aplicações, na secção seguinte, o foco é especificamente nas bases de dados.

Embora as mesmas considerações para fatores como a localização da implementação, a partilha de estado, a replicação síncrona e assíncrona para bases de dados multinuvem sejam aplicáveis a filas e ficheiros, esta discussão está fora do âmbito deste documento.

Trabalhar em rede

Na arquitetura de uma aplicação com estado genérica (mostrada novamente no diagrama seguinte), cada seta entre os componentes representa uma relação de comunicação através de uma ligação de rede, por exemplo, um cliente de aplicação que acede a um serviço de aplicação.

Uma ligação pode estar dentro de uma zona ou em várias zonas, regiões ou nuvens. As ligações podem existir entre qualquer combinação de localizações de implementação. Em ambientes de várias nuvens, a rede entre nuvens é uma consideração importante e existem várias opções que pode usar. Para mais informações sobre a criação de redes em várias nuvens, consulte Rede entre nuvens para aplicações distribuídas e Estabelecer ligação a Google Cloud: as suas opções de rede explicadas.

Nos exemplos de utilização neste documento, pressupõe-se o seguinte:

• Existe uma ligação de rede segura entre as nuvens.
• As bases de dados e os respetivos componentes podem comunicar entre si.

Do ponto de vista não funcional, a dimensão da rede, ou seja, a taxa de transferência e a latência, podem afetar a latência e a taxa de transferência da base de dados. Do ponto de vista funcional, a rede geralmente não tem efeito.

Exemplos de utilização de bases de dados em várias nuvens

Esta secção apresenta uma seleção dos exemplos de utilização mais comuns para a gestão de bases de dados em várias nuvens. Para estes exemplos de utilização, pressupõe-se que existe uma conetividade de rede segura entre as nuvens e os nós da base de dados.

Migração de aplicações

No contexto da gestão de bases de dados em várias nuvens, a migração de aplicações refere-se à migração de uma aplicação, de todos os serviços de aplicações e da base de dados da nuvem atual para uma nuvem de destino. Existem muitos motivos pelos quais uma empresa pode decidir migrar uma aplicação, por exemplo, para evitar uma situação competitiva com o fornecedor de nuvem, modernizar a tecnologia ou reduzir o custo total de propriedade (TCO).

Na migração de aplicações, o objetivo é parar a produção na nuvem atual e continuar a produção na nuvem de destino após a conclusão da migração. Os serviços de aplicação têm de ser executados na nuvem de destino. Para implementar os serviços, pode usar uma abordagem de migração direta. Nesta abordagem, o mesmo código é implementado na nuvem de destino. Para reimplementar o serviço, podem ser usadas as tecnologias de nuvem modernas disponíveis na nuvem de destino.

Do ponto de vista da base de dados, considere as seguintes opções alternativas para a migração de aplicações:

• Migração de base de dados: se o mesmo motor de base de dados estiver disponível na nuvem de destino, é possível migrar a base de dados para criar uma implementação idêntica na nuvem de destino.
• Elevação e mudança da base de dados para o equivalente gerido: uma base de dados autogerida pode ser migrada para uma versão gerida do mesmo motor de base de dados se a nuvem de destino a fornecer.
• Modernização de bases de dados: as diferentes nuvens oferecem diferentes tecnologias de bases de dados. As bases de dados geridas por um fornecedor de nuvem podem ter vantagens, como contratos de nível de serviço (SLAs) mais rigorosos, escalabilidade e recuperação de desastres automática.

Independentemente da estratégia de implementação, a migração da base de dados é um processo que demora tempo devido à necessidade de mover dados da nuvem atual para a nuvem de destino. Embora seja possível seguir uma abordagem de exportação e importação que incorra em tempo de inatividade, é preferível uma migração com tempo de inatividade mínimo ou nulo. Esta abordagem minimiza o tempo de inatividade da aplicação e tem o menor efeito numa empresa e nos respetivos clientes. No entanto, normalmente, requer uma configuração de migração mais complexa, uma vez que envolve um carregamento inicial, replicação contínua, monitorização, validação detalhada e sincronização durante a mudança. Para suportar cenários de alternativa, tem de implementar um mecanismo de replicação inversa para sincronizar as alterações novamente com a base de dados de origem depois de mudar para a base de dados de destino.

Recuperação de desastres

A recuperação de desastres refere-se à capacidade de uma aplicação continuar a fornecer serviços aos clientes da aplicação durante uma indisponibilidade da região. Para garantir a recuperação de desastres, uma aplicação tem de ser implementada em, pelo menos, duas regiões e estar pronta para execução em qualquer altura. Em produção, a aplicação é executada na região principal. No entanto, se ocorrer uma indisponibilidade, uma região secundária torna-se a região principal. Seguem-se diferentes modelos de prontidão na recuperação de desastres:

• Hot standby. A aplicação está implementada em duas ou mais regiões (principal e secundária) e está a funcionar plenamente em todas as regiões. Se a região principal falhar, a aplicação na região secundária pode assumir imediatamente o tráfego de clientes da aplicação.
• Modo de espera a frio. A aplicação está a ser executada na região principal. No entanto, está pronta para ser iniciada numa região secundária (mas não está a ser executada). Se a região principal falhar, a aplicação é iniciada na região secundária. Ocorre uma indisponibilidade da aplicação até que esta consiga ser executada e fornecer todos os serviços da aplicação aos clientes da aplicação.
• Sem standby. Neste modelo, o código da aplicação está pronto para implementação, mas ainda não foi implementado na região secundária (e, por isso, não está a usar recursos implementados). Se uma região principal tiver uma indisponibilidade, a primeira implementação da aplicação tem de estar na região secundária. Esta implementação coloca a aplicação no mesmo estado que um modo de espera a frio, o que significa que tem de ser iniciada. Nesta abordagem, a indisponibilidade da aplicação é mais longa em comparação com o caso de espera a frio, porque a implementação da aplicação tem de ocorrer primeiro, o que inclui a criação de recursos na nuvem.

Do ponto de vista da base de dados, os modelos de prontidão abordados na lista anterior correspondem às seguintes abordagens de base de dados:

• Base de dados sincronizada transacionalmente. Esta base de dados corresponde ao modelo de espera ativa. Todas as transações na região principal são confirmadas em coordenação síncrona numa região secundária. Quando a região secundária se torna a região principal durante uma interrupção, a base de dados é consistente e fica imediatamente disponível. Neste modelo, o objetivo de ponto de recuperação (RPO) e o objetivo de tempo de recuperação (RTO) são ambos zero.
• Base de dados replicada de forma assíncrona. Esta base de dados também corresponde ao modelo de espera ativa. Uma vez que a replicação da base de dados da região principal para a região secundária é assíncrona, existe a possibilidade de, se a região principal falhar, algumas transações poderem ser replicadas para a região secundária. Embora a base de dados na região secundária esteja pronta para o carregamento de produção, pode não ter os dados mais atuais. Por este motivo, a aplicação pode incorrer numa perda de transações não recuperáveis. Devido a este risco, esta abordagem tem um RTO de zero, mas o RPO é superior a zero.
• Base de dados inativa. Esta base de dados corresponde ao modelo de espera a frio. A base de dados é criada sem dados. Quando a região principal falha, os dados têm de ser carregados para a base de dados inativa. Para ativar esta ação, tem de fazer uma cópia de segurança normal na região principal e transferi-la para a região secundária. A cópia de segurança pode ser completa ou incremental, consoante o que o motor da base de dados suporta. Em qualquer dos casos, a base de dados é reposta na última cópia de segurança e, da perspetiva da aplicação, podem perder-se muitas transações em comparação com a região principal. Embora esta abordagem possa ser rentável, o valor é atenuado pelo risco de que todas as transações desde a última cópia de segurança disponível possam ser perdidas devido ao estado da base de dados não estar atualizado.
• Nenhuma base de dados. Este modelo é equivalente ao caso sem modo de espera. A região secundária não tem nenhuma base de dados instalada e, se a região principal falhar, tem de ser criada uma base de dados. Após a criação da base de dados, tal como no caso da base de dados inativa, tem de ser carregada com dados antes de ficar disponível para a aplicação.

As abordagens de recuperação de desastres abordadas neste documento também se aplicam se for usado um cloud principal e um cloud secundário em vez de uma região principal e uma região secundária. A principal diferença é que, devido à heterogeneidade da rede entre nuvens, a latência entre nuvens pode aumentar em comparação com a distância da rede entre regiões numa nuvem. Outras discrepâncias podem resultar de diferentes funcionalidades e definições predefinidas de bases de dados geridas de diferentes fornecedores de nuvem.

A probabilidade de falha de toda a nuvem é inferior à de falha de uma região. No entanto, pode continuar a ser útil para as empresas ter uma aplicação implementada em duas nuvens. Esta abordagem pode ajudar a proteger uma empresa contra falhas ou a cumprir os regulamentos empresariais ou da indústria.

Outra abordagem de recuperação de desastres é ter uma região principal e uma região secundária, bem como uma nuvem principal e uma nuvem secundária. Esta abordagem permite que as empresas escolham o melhor processo de recuperação de desastres para resolver uma situação de falha. Para permitir a execução de uma aplicação, pode usar uma região secundária ou uma nuvem secundária, consoante a gravidade da indisponibilidade.

Aumento de capacidade da nuvem

O aumento rápido na nuvem refere-se a uma configuração que permite o aumento do tráfego de clientes da aplicação em diferentes localizações de implementação. Uma aplicação aumenta quando a procura de capacidade aumenta e uma localização em espera fornece capacidade adicional. Uma localização principal suporta o tráfego normal, enquanto uma localização de reserva pode fornecer capacidade adicional caso o tráfego de clientes da aplicação aumente além do que a localização principal pode suportar. Ambas as localizações principal e de reserva têm instâncias de serviço de aplicações implementadas.

A expansão rápida é implementada em várias nuvens, em que uma é a nuvem principal e a outra é a nuvem de reserva. É usado num contexto de nuvem híbrida para aumentar um número limitado de recursos de computação em centros de dados no local com recursos de computação na nuvem elásticos numa nuvem pública.

Para apoio técnico de bases de dados, estão disponíveis as seguintes opções:

• Implementação da localização principal. Nesta implementação, a base de dados é implementada apenas na localização principal e não na localização de espera. Quando uma aplicação tem um pico de atividade, a aplicação na localização de espera acede à base de dados na localização principal.
• Implementação de localização principal e de reserva. Esta implementação suporta a localização principal e a localização de reserva. Uma instância da base de dados é implementada em ambas as localizações e é acedida pelas instâncias do serviço de aplicações dessa localização, especialmente no caso de picos de utilização. Tal como na Recuperação de desastres dentro e entre nuvens, as duas bases de dados podem ser sincronizadas transacionalmente ou sincronizadas de forma assíncrona. Na sincronização assíncrona, pode haver um atraso. Se as atualizações estiverem a ocorrer na localização de espera, têm de ser propagadas novamente para a localização principal. Se forem possíveis atualizações simultâneas em ambas as localizações, tem de ser implementada a resolução de conflitos.

O cloud bursting é um exemplo de utilização comum em nuvens híbridas para aumentar a capacidade nos centros de dados no local. Também é uma abordagem que pode ser usada em nuvens públicas quando os dados têm de permanecer num país. Em situações em que uma nuvem pública tem apenas uma região num país, é possível expandir para uma região de uma nuvem pública diferente no mesmo país. Esta abordagem garante que os dados permanecem no país, ao mesmo tempo que aborda as restrições de recursos na região das regiões da nuvem pública.

Utilização do melhor serviço na nuvem

Algumas aplicações requerem serviços e produtos na nuvem especializados que não estão disponíveis numa única nuvem. Por exemplo, uma aplicação pode realizar o processamento da lógica empresarial dos dados da empresa numa nuvem e a análise dos dados da empresa noutra nuvem. Neste exemplo de utilização, as partes de processamento da lógica empresarial e as partes de análise da aplicação são implementadas em nuvens diferentes.

Do ponto de vista da gestão de dados, os exemplos de utilização são os seguintes:

• Dados particionados. Cada parte da aplicação tem a sua própria base de dados (partição separada) e nenhuma das bases de dados está ligada diretamente entre si. A aplicação que gere os dados escreve todos os dados que têm de estar disponíveis em ambas as bases de dados (partições) duas vezes.
• Base de dados replicada de forma assíncrona. Se os dados de uma nuvem tiverem de estar disponíveis na outra, uma relação de replicação assíncrona pode ser adequada. Por exemplo, se uma aplicação de estatísticas exigir o mesmo conjunto de dados ou um subconjunto do conjunto de dados para uma aplicação empresarial, este último pode ser replicado entre as nuvens.
• Base de dados sincronizada transacionalmente. Estes tipos de bases de dados permitem-lhe disponibilizar dados a ambas as partes da aplicação. Cada atualização de cada uma das aplicações é transacionalmente consistente e está imediatamente disponível para ambas as bases de dados (partições). As bases de dados sincronizadas transacionalmente atuam eficazmente como uma única base de dados distribuída.

Serviços distribuídos

Um serviço distribuído é implementado e executado em duas ou mais localizações de implementação. É possível implementar todas as instâncias de serviço em todas as localizações de implementação. Em alternativa, é possível implementar alguns serviços em todas as localizações e alguns apenas numa das localizações, com base em fatores como a disponibilidade de hardware ou a carga limitada esperada.

Os dados numa base de dados sincronizada transacionalmente são consistentes em todas as localizações. Por conseguinte, uma base de dados deste tipo é a melhor opção para implementar instâncias de serviços em todas as localizações de implementação.

Quando usa uma base de dados replicada assíncrona, existe o risco de o mesmo item de dados ser modificado em duas localizações de implementação em simultâneo. Para determinar qual das duas alterações em conflito é o estado consistente final, tem de ser implementada uma estratégia de resolução de conflitos. Embora seja possível implementar uma estratégia de resolução de conflitos, nem sempre é simples e existem casos em que é necessária uma intervenção manual para restaurar os dados para um estado consistente.

Relocalização e comutação por falha de serviços distribuídos

Se falhar uma região da nuvem inteira, a recuperação de desastres é iniciada. Se um único serviço numa aplicação de base de dados com estado falhar (não a região nem a aplicação completa), o serviço tem de ser recuperado e reiniciado.

Uma abordagem inicial para a recuperação de desastres consiste em reiniciar o serviço com falhas na localização de implementação original (uma abordagem de reinício no local). As tecnologias como o Kubernetes reiniciam automaticamente um serviço com base na respetiva configuração.

No entanto, se esta abordagem de reinício no local não for bem-sucedida, uma alternativa é reiniciar o serviço numa localização secundária. O serviço passa da respetiva localização principal para uma localização secundária. Se a aplicação for implementada como um conjunto de serviços distribuídos, a comutação por falha de um único serviço pode ocorrer dinamicamente.

Do ponto de vista da base de dados, o reinício do serviço na sua localização de implementação original não requer uma implementação específica da base de dados. Quando um serviço é movido para uma localização de implementação alternativa e o serviço acede à base de dados, aplicam-se os mesmos modelos de prontidão que foram abordados em Serviços distribuídos anteriormente neste documento.

Se um serviço estiver a ser mudado temporariamente e se latências mais elevadas forem aceitáveis para uma empresa durante a mudança, o serviço pode aceder à base de dados em várias localizações de implementação. Embora o serviço seja mudado de localização, continua a aceder à base de dados da mesma forma que o faria a partir da respetiva localização de implementação original.

Implementação dependente do contexto

Em geral, uma implementação de aplicação única para publicar todos os clientes de aplicações inclui todos os respetivos serviços de aplicações e bases de dados. No entanto, existem exemplos de utilização excecionais. Uma única implementação de aplicação só pode publicar um subconjunto de clientes (com base em critérios específicos), o que significa que é necessária mais do que uma implementação de aplicação. Cada implementação serve um subconjunto diferente de clientes e todas as implementações juntas servem todos os clientes.

Seguem-se exemplos de utilização de uma implementação dependente do contexto:

• Quando implementa uma aplicação multi-inquilino para a qual uma aplicação é implementada para todos os pequenos inquilinos, outra aplicação é implementada para cada 10 inquilinos médios e uma aplicação é implementada para cada inquilino premium.
• Quando existe a necessidade de separar os clientes, por exemplo, clientes empresariais e clientes governamentais.
• Quando é necessário separar os ambientes de desenvolvimento, teste e produção.

Do ponto de vista da base de dados, é possível implementar uma base de dados para cada implementação de aplicação numa estratégia de implementação individual. Conforme mostrado no diagrama seguinte, esta estratégia é uma abordagem simples em que são criados dados particionados porque cada implementação tem o seu próprio conjunto de dados.

O diagrama anterior mostra o seguinte:

• Uma configuração com três implementações de uma aplicação.
• Cada conjunto de dados tem a sua própria base de dados.
• Não são partilhados dados entre as implementações.

Em muitas situações, uma implementação individual é a estratégia mais adequada. No entanto, existem alternativas.

No caso da multi-posse, os inquilinos podem ser realocados. Um pequeno inquilino pode tornar-se um inquilino médio e ter de ser realocado para uma aplicação diferente. Neste caso, as implementações de bases de dados separadas requerem a migração da base de dados. Se for implementada uma base de dados distribuída e for usada por todas as implementações em simultâneo, todos os dados do inquilino residem num único sistema de base de dados. Por este motivo, a movimentação de um inquilino entre bases de dados não requer a migração da base de dados. O diagrama seguinte mostra um exemplo deste tipo de base de dados:

O diagrama anterior mostra o seguinte:

• Três implementações de uma aplicação.
• Todas as implementações partilham uma única base de dados distribuída.
• As aplicações podem aceder a todos os dados em cada implementação.
• Não existe nenhuma partição de dados implementada.

Se uma empresa muda frequentemente os inquilinos como parte das operações do ciclo de vida, a replicação da base de dados pode ser uma alternativa útil. Nesta abordagem, os dados do inquilino são replicados entre bases de dados antes de uma migração de inquilinos. Neste caso, são usadas bases de dados independentes para diferentes implementações de aplicações e apenas configuradas para replicação imediatamente antes e durante a migração de inquilinos. O diagrama seguinte mostra uma replicação temporária entre duas implementações de aplicações durante uma migração de inquilinos.

O diagrama anterior mostra três implementações de uma aplicação com três bases de dados separadas que contêm os dados associados a cada implementação respetiva. Para migrar dados de uma base de dados para outra, pode configurar uma migração de base de dados temporária.

Portabilidade de aplicações

A portabilidade das aplicações garante que uma aplicação pode ser implementada em diferentes localizações de implementação, especialmente em diferentes nuvens. Esta portabilidade garante que uma aplicação pode ser migrada em qualquer altura, sem necessidade de reengenharia específica da migração ou desenvolvimento de aplicações adicional para preparar uma migração de aplicações.

Para garantir a portabilidade da aplicação, pode usar uma das seguintes abordagens, que são descritas mais adiante nesta secção:

• Portabilidade baseada no sistema
• Compatibilidade da API
• Portabilidade baseada na funcionalidade

A portabilidade baseada no sistema usa os mesmos componentes técnicos que são usados em todas as implementações possíveis. Para garantir a portabilidade baseada no sistema, cada tecnologia tem de estar disponível em todas as potenciais localizações de implementação. Por exemplo, se uma base de dados como o PostgreSQL for um candidato, a respetiva disponibilidade em todos os potenciais locais de implementação tem de ser verificada para o período esperado. O mesmo se aplica a todas as outras tecnologias, por exemplo, linguagens de programação e tecnologias de infraestrutura. Conforme mostrado no diagrama seguinte, esta abordagem estabelece um conjunto de funcionalidades comuns em todas as localizações de implementação com base na tecnologia.

O diagrama anterior mostra uma implementação de aplicação portátil em que a aplicação espera o mesmo sistema de base de dados exato em todas as localizações para as quais é implementada. Uma vez que o mesmo sistema de base de dados é usado em cada localização, a aplicação é portátil. A aplicação pode esperar que o mesmo sistema de base de dados seja usado na implementação. Por conseguinte, pode assumir-se que a interface e o comportamento do sistema de base de dados são exatamente os mesmos.

No contexto das bases de dados, no sistema de compatibilidade com a API, o cliente usa uma biblioteca de acesso à base de dados específica (por exemplo, uma biblioteca cliente do MySQL) para garantir que consegue estabelecer ligação a qualquer implementação em conformidade que possa estar disponível num ambiente de nuvem. O diagrama seguinte ilustra a compatibilidade da API.

O diagrama anterior mostra a portabilidade da aplicação com base na API do sistema de base de dados, em vez do sistema de base de dados. Embora os sistemas de base de dados possam ser diferentes em cada uma das localizações, a API é a mesma e expõe a mesma funcionalidade. A aplicação é portátil porque pode assumir a mesma API em cada localização, mesmo que o sistema de base de dados subjacente seja uma tecnologia de base de dados diferente.

Na portabilidade baseada na funcionalidade, podem ser usadas diferentes tecnologias em diferentes nuvens que oferecem a mesma funcionalidade. Por exemplo, pode ser possível restringir a utilização de bases de dados ao modelo relacional. Uma vez que qualquer sistema de base de dados relacional pode suportar a aplicação, podem ser usados diferentes sistemas de base de dados em diferentes versões em diferentes nuvens sem afetar a portabilidade da aplicação. Uma desvantagem da portabilidade baseada na funcionalidade é que só pode usar as partes do modelo de base de dados que todos os sistemas de bases de dados relacionais suportam. Em vez de um sistema de base de dados compatível com todas as nuvens, tem de ser usado um modelo de base de dados. O diagrama seguinte mostra um exemplo de arquitetura para a portabilidade baseada na funcionalidade.

Conforme mostra o diagrama anterior, a API do sistema de base de dados e o sistema de base de dados podem ser diferentes em cada localização. Para garantir a portabilidade, a aplicação tem de usar apenas as partes de cada sistema de base de dados e de cada API que estão disponíveis em cada localização. Uma vez que apenas um subconjunto de cada sistema de base de dados está normalmente disponível em cada localização, a aplicação tem de restringir a sua utilização a esse subconjunto.

Para garantir a portabilidade de todas as opções nesta secção, a arquitetura completa tem de ser implementada continuamente em todas as localizações de destino. Todos os exemplos de testes de unidades e sistemas têm de ser executados em relação a estas implementações. Estes são requisitos essenciais para que as alterações nas infraestruturas e tecnologias sejam detetadas e resolvidas antecipadamente.

Prevenção da dependência de fornecedores

A prevenção da dependência de fornecedores (bloqueio) ajuda a mitigar o risco de dependência de uma tecnologia e de um fornecedor específicos. É superficialmente semelhante à portabilidade de aplicações. A prevenção da dependência de fornecedores aplica-se a todas as tecnologias usadas e não apenas aos serviços na nuvem. Por exemplo, se o MySQL for usado como um sistema de base de dados e instalado em máquinas virtuais nas nuvens, não existe nenhuma dependência do ponto de vista da nuvem, mas existe uma dependência do MySQL. Uma aplicação que seja portátil em várias nuvens pode continuar a depender de tecnologias fornecidas por fornecedores diferentes dos da nuvem.

Para evitar a dependência de fornecedores, todas as tecnologias têm de ser substituíveis. Por este motivo, é necessária uma abstração completa e estruturada de todas as funcionalidades da aplicação para que cada serviço de aplicação possa ser reimplementado numa base tecnológica diferente sem afetar a forma como a aplicação é implementada. Do ponto de vista da base de dados, esta abstração pode ser feita separando a utilização de um modelo de base de dados de um sistema de gestão de base de dados específico.

Sistema de gestão de base de dados de produção existente

Embora muitas aplicações multinuvem sejam desenvolvidas com sistemas de base de dados como parte do respetivo design, muitas empresas desenvolvem aplicações multinuvem como parte do respetivo esforço de modernização de aplicações. Estas aplicações são desenvolvidas com a suposição de que a aplicação recentemente concebida e implementada acede às bases de dados existentes.

Existem muitos motivos para não incorporar bases de dados existentes num esforço de modernização. Podem estar a ser usadas funcionalidades específicas que não estão disponíveis noutros sistemas de base de dados. Uma empresa pode ter bases de dados com processos de gestão complexos e bem estabelecidos, o que torna a mudança para um sistema diferente impraticável ou antieconómica. Em alternativa, uma empresa pode optar por modernizar uma aplicação na primeira fase e modernizar a base de dados na segunda fase.

Quando uma empresa usa um sistema de base de dados existente, o criador da aplicação multinuvem tem de decidir se vai ser a única base de dados usada ou se é necessário adicionar um sistema de base de dados diferente para diferentes localizações de implementação. Por exemplo, se for usada uma base de dados no local e a aplicação também precisar de ser executada no Google Cloud, tem de considerar se os serviços de aplicação implementados no Google Cloud acedem à base de dados no local. Em alternativa, se uma segunda base de dados deve ser implementada emGoogle Cloud e para os serviços de aplicações executados localmente.

Se for implementada uma segunda base de dados em Google Cloud, o exemplo de utilização pode ser o mesmo que os exemplos de utilização abordados em Expansão na nuvem ou Serviços distribuídos. Em qualquer caso, a mesma discussão sobre a base de dados aplica-se como nestas secções. No entanto, está limitada à funcionalidade em várias localizações que a base de dados existente no local pode suportar, por exemplo, a sincronização e a replicação.

Padrões de implementação

Os exemplos de utilização abordados neste documento levantam uma questão comum do ponto de vista da base de dados: se as bases de dados estiverem em mais do que uma localização de implementação, qual é a relação entre elas?

Os principais tipos de relações (padrões de implementação), que são abordados na secção seguinte, são os seguintes:

• Particionada sem dependência entre bases de dados
• Replicação unidirecional assíncrona
• Replicação bidirecional com resolução de conflitos
• Sistema distribuído sincronizado totalmente ativo-ativo

É possível mapear cada exemplo de utilização neste documento para um ou mais dos quatro padrões de implementação.

Na discussão seguinte, pressupõe-se que os clientes acedem diretamente aos serviços de aplicações. Consoante o exemplo de utilização, pode ser necessário um equilibrador de carga para direcionar dinamicamente o acesso do cliente às aplicações, conforme mostrado no diagrama seguinte.

No diagrama anterior, um equilibrador de carga na nuvem direciona as chamadas de cliente para uma das localizações disponíveis. O balanceador de carga garante que as políticas de balanceamento de carga são aplicadas e que os clientes são direcionados para a localização correta da aplicação e da respetiva base de dados.

Particionada sem dependência entre bases de dados

Este padrão de implementação é o mais simples de todos os padrões abordados neste documento: cada localização ou nuvem tem uma base de dados e as bases de dados contêm conjuntos de dados particionados que não dependem uns dos outros. Um item de dados é armazenado apenas numa base de dados. Cada partição de dados está localizada na sua própria base de dados. Um exemplo deste padrão é uma aplicação multi-inquilino em que um conjunto de dados está numa ou noutra base de dados. O diagrama seguinte mostra duas aplicações totalmente particionadas.

Conforme mostra o diagrama anterior, uma aplicação é implementada em duas localizações, cada uma responsável por uma partição do conjunto de dados completo. Cada item de dados reside apenas num dos locais, o que garante um conjunto de dados particionado sem replicação entre os dois.

Um padrão de implementação alternativo para bases de dados particionadas é aquele em que o conjunto de dados está completamente particionado, mas continua a ser armazenado na mesma base de dados. Existe apenas uma base de dados que contém todos os conjuntos de dados. Embora os conjuntos de dados sejam armazenados na mesma base de dados, estão completamente separados (particionados) e uma alteração a um não provoca alterações noutro. O diagrama seguinte mostra duas aplicações que partilham uma única base de dados.

O diagrama anterior mostra o seguinte:

• Duas implementações de aplicações que partilham uma base de dados comum, que se encontra na primeira localização.
• Cada aplicação pode aceder a todos os dados na implementação porque o conjunto de dados não está particionado.

Replicação unidirecional assíncrona

Este padrão de implementação tem uma base de dados principal que é replicada para uma ou mais bases de dados secundárias. A base de dados secundária pode ser usada para acesso de leitura, mas a aplicação tem de ter em conta o potencial atraso na replicação. Um exemplo deste padrão é quando a melhor base de dados para um exemplo de utilização específico é usada como a base de dados principal e a base de dados secundária é usada para estatísticas. O diagrama seguinte mostra duas aplicações a aceder a bases de dados replicadas unidirecionalmente.

Conforme mostra o diagrama anterior, uma das duas bases de dados é uma réplica da outra. A seta no diagrama indica a direção da replicação: os dados do sistema de base de dados na localização 1 são replicados para o sistema de base de dados na localização 2.

Replicação bidirecional com resolução de conflitos

Este padrão de implementação tem duas bases de dados principais que são replicadas de forma assíncrona entre si. Se os mesmos dados forem escritos ao mesmo tempo em cada base de dados (por exemplo, a mesma chave primária), pode causar um conflito de escrita. Devido a este risco, tem de existir uma resolução de conflitos para determinar qual é o último estado durante a replicação. Este padrão pode ser usado em situações em que a probabilidade de um conflito de gravação é rara. O diagrama seguinte mostra duas aplicações a aceder a bases de dados replicadas bidirecionalmente.

Conforme mostra o diagrama anterior, cada base de dados é replicada para a outra base de dados. As duas replicações são independentes entre si, conforme indicado no diagrama por duas setas azuis separadas. Uma vez que as duas replicações são independentes, pode surgir um conflito se, por acaso, o mesmo item de dados for alterado por cada uma das aplicações e replicado em simultâneo. Neste caso, tem de ocorrer a resolução de conflitos.

Sistema distribuído sincronizado totalmente ativo-ativo

Este padrão de implementação tem uma única base de dados com uma configuração ativa-ativa (também primária-primária). Numa configuração ativo-ativo, uma atualização dos dados em qualquer base de dados principal é transacionalmente consistente e replicada de forma síncrona. Um exemplo de utilização deste padrão é a computação distribuída. O diagrama seguinte mostra duas aplicações a aceder a uma base de dados principal-principal totalmente sincronizada.

Conforme mostra o diagrama anterior, esta disposição garante que cada aplicação acede sempre ao último estado consistente, sem atrasos nem risco de conflitos. Uma alteração numa base de dados fica imediatamente disponível na outra base de dados. Qualquer alteração é refletida em ambas as bases de dados quando ocorre uma confirmação de transação de alteração.

Categorização do sistema de base de dados

Nem todos os sistemas de gestão de bases de dados podem ser usados igualmente bem para os padrões de implementação abordados neste documento. Consoante o exemplo de utilização, pode apenas ser possível implementar um padrão de implementação ou uma combinação de padrões de implementação com apenas um subconjunto de sistemas de base de dados.

Na secção seguinte, os diferentes sistemas de base de dados são categorizados e mapeados para os quatro padrões de implementação.

É possível categorizar bases de dados por diferentes dimensões, como o modelo de dados, a arquitetura interna, o modelo de implementação e os tipos de transações. Na secção seguinte, para efeitos de gestão de bases de dados em várias nuvens, são usadas duas dimensões:

• Arquitetura de implementação. A arquitetura de como um sistema de gestão de bases de dados é implementado em recursos de nuvens (por exemplo, motores de computação ou geridos na nuvem).
• Modelo de distribuição. O modelo de distribuição suportado por um sistema de base de dados (por exemplo, instância única ou totalmente distribuída).

Estas duas dimensões são as mais relevantes no contexto dos exemplos de utilização de várias nuvens e podem suportar os quatro padrões de implementação derivados dos exemplos de utilização de bases de dados de várias nuvens. Uma categorização popular baseia-se nos modelos de dados suportados por um sistema de gestão de bases de dados. Alguns sistemas suportam apenas um modelo (por exemplo, um modelo de gráfico). Outros sistemas suportam vários modelos de dados em simultâneo (por exemplo, modelos relacionais e de documentos). No entanto, no contexto da gestão de bases de dados em várias nuvens, esta categorização não é relevante porque as aplicações em várias nuvens podem usar qualquer modelo de dados para a respetiva implementação em várias nuvens.

Sistema de base de dados por arquitetura de implementação

A gestão de bases de dados em várias nuvens inclui as seguintes quatro classes principais de arquitetura de implementação para sistemas de gestão de bases de dados:

• Bases de dados na nuvem integradas. As bases de dados na nuvem integradas são concebidas, criadas e otimizadas para funcionar com a tecnologia na nuvem. Por exemplo, alguns sistemas de bases de dados usam o Kubernetes como plataforma de implementação e usam a funcionalidade do Kubernetes. CockroachDB e YugaByte são exemplos deste tipo de base de dados. Podem ser implementadas em qualquer nuvem que suporte o Kubernetes.
• Bases de dados geridas pelo fornecedor de nuvem. As bases de dados geridas pelo fornecedor de nuvem são criadas com tecnologia específica do fornecedor de nuvem e são um serviço de base de dados gerido por um fornecedor de nuvem específico. O Spanner, Bigtable, Firestore> e o AlloyDB para PostgreSQL são exemplos deste tipo de base de dados. As bases de dados geridas pelo fornecedor de nuvem só estão disponíveis na nuvem do fornecedor de nuvem e não podem ser instaladas nem executadas noutro local. No entanto, o AlloyDB para PostgreSQL é totalmente compatível com o PostgreSQL.
• Bases de dados pré-nuvem. As bases de dados pré-nuvem existiam antes do desenvolvimento da tecnologia de nuvem (por vezes, há muito tempo) e, normalmente, são executadas em hardware bare metal e máquinas virtuais (VMs). PostgreSQL, MySQL e SQL Server são exemplos deste tipo de base de dados. Estes sistemas podem ser executados em qualquer nuvem que suporte as VMs ou o hardware bare metal necessários.
• Bases de dados geridas por parceiros do Cloud. Algumas nuvens públicas têm parceiros de bases de dados que instalam e gerem as bases de dados dos clientes na nuvem pública. Por este motivo, os clientes não têm de gerir estas bases de dados. O MongoDB Atlas, o MariaDB e o ScyllaDB são exemplos deste tipo de base de dados.

Existem algumas variantes destas categorias principais. Por exemplo, um fornecedor de bases de dados que implemente uma base de dados criada para a nuvem também pode fornecer uma instalação na tecnologia criada para a nuvem e uma oferta gerida aos clientes na nuvem fornecida pelo fornecedor. Esta abordagem é equivalente ao fornecedor que disponibiliza uma nuvem pública que suporta apenas a respetiva base de dados como o único serviço.

As bases de dados pré-nuvem também podem estar em contentores e podem ser implementadas num cluster do Kubernetes. No entanto, estas bases de dados não usam funcionalidades específicas do Kubernetes, como o dimensionamento, o serviço múltiplo ou a implementação multipod.

Os fornecedores de bases de dados podem estabelecer parcerias com mais do que um fornecedor de nuvem pública ao mesmo tempo, oferecendo a respetiva base de dados como uma base de dados gerida por parceiros na nuvem em mais do que uma nuvem pública.

Sistema de base de dados por modelo de distribuição

Os diferentes sistemas de gestão de bases de dados são implementados de acordo com os modelos de distribuição na arquitetura de uma base de dados. Os modelos para bases de dados são os seguintes:

• Instância única. Uma única instância da base de dados é executada numa VM ou num contentor e funciona como um sistema centralizado. Este sistema gere todo o acesso à base de dados. Uma vez que a instância única não pode ser ligada a nenhuma outra instância, o sistema de base de dados não suporta a replicação.
• Ativo-passivo com várias instâncias. Nesta arquitetura comum, várias instâncias da base de dados estão associadas. A associação mais comum é uma relação ativa-passiva em que uma instância é a instância de base de dados ativa que suporta ambas as instâncias e grava e lê. Um ou mais sistemas passivos são só de leitura e recebem todas as alterações da base de dados da principal de forma síncrona ou assíncrona. Os sistemas passivos podem fornecer acesso de leitura. A configuração ativo-passivo também é denominada primária-secundária ou origem-réplica.
• Ativo-ativo com várias instâncias. Nesta arquitetura relativamente invulgar, cada instância é uma instância ativa. Neste caso, cada instância pode executar transações de leitura e escrita e fornecer consistência de dados. Por este motivo, para evitar inconsistências nos dados, todas as instâncias são sempre sincronizadas.
• Ativo-ativo com várias instâncias e resolução de conflitos. Este também é um sistema relativamente invulgar. Cada instância está disponível para acesso de leitura e escrita. No entanto, as bases de dados são sincronizadas num modo assíncrono. As atualizações simultâneas do mesmo item de dados são permitidas, o que leva a um estado inconsistente. Uma política de resolução de conflitos tem de decidir qual dos estados é o último estado consistente.
• Partilha em várias instâncias. A divisão em partições baseia-se na gestão de partições (desarticuladas) de dados. Uma instância de base de dados separada gere cada partição. Esta distribuição é escalável porque é possível adicionar mais fragmentos dinamicamente ao longo do tempo. No entanto, as consultas entre partições podem não ser possíveis, uma vez que esta funcionalidade não é suportada por todos os sistemas.

Todos os modelos de distribuição abordados nesta secção podem suportar a divisão em partições e podem ser um sistema dividido em partições. No entanto, nem todos os sistemas são concebidos para oferecer uma opção de divisão. A divisão horizontal é um conceito de escalabilidade e, geralmente, não é relevante para a seleção de bases de dados de arquitetura em ambientes de várias nuvens.

Os modelos de distribuição são diferentes para bases de dados geridas na nuvem e por parceiros. Uma vez que estas bases de dados estão associadas à arquitetura de um fornecedor de nuvem, estes sistemas implementam arquiteturas baseadas nas seguintes localizações de implementação:

• Sistema zonal. Um sistema de base de dados gerido por zonas está associado a uma zona. Quando a zona está disponível, o sistema de base de dados também está disponível. No entanto, se a zona ficar indisponível, não é possível aceder à base de dados.
• Sistema regional. Uma base de dados gerida regionalmente está associada a uma região e é acessível quando, pelo menos, uma zona é acessível. Qualquer combinação de zonas pode ficar inacessível.
• Sistema entre regiões. Um sistema inter-regional está associado a duas ou mais regiões e funciona corretamente quando, pelo menos, uma região está disponível.

Um sistema inter-regional também pode suportar um sistema entre nuvens se a base de dados puder ser instalada em todas as nuvens que uma empresa pretende usar.

Existem outras alternativas possíveis às arquiteturas de base de dados geridas abordadas nesta secção. Um sistema regional pode partilhar um disco entre duas zonas. Se qualquer uma das duas zonas ficar inacessível, o sistema de base de dados pode continuar na zona restante. No entanto, se uma indisponibilidade afetar ambas as zonas, o sistema de base de dados fica indisponível, mesmo que outras zonas possam continuar totalmente online.

Mapeamento de sistemas de bases de dados para padrões de implementação

A tabela seguinte descreve a relação entre os padrões de implementação e as arquiteturas de implementação abordados neste documento. Os campos indicam as condições necessárias para que uma combinação seja possível, com base no padrão de implementação e na arquitetura de implementação.

Arquitetura de implementação	Padrão de implementação
	Particionada sem dependência entre bases de dados	Replicação unidirecional assíncrona	Replicação bidirecional com resolução de conflitos	Sistema distribuído sincronizado totalmente ativo-ativo
Bases de dados na nuvem incorporadas	Possível para todas as nuvens que fornecem tecnologia de nuvem incorporada usada por sistemas de bases de dados. Se a mesma base de dados não estiver disponível, podem ser usados sistemas de base de dados diferentes.	Base de dados na nuvem que oferece replicação.	Base de dados na nuvem que oferece replicação bidirecional.	Base de dados na nuvem que oferece sincronização primária-primária.
Bases de dados geridas pelo fornecedor de nuvem	Os sistemas de base de dados podem ser diferentes em diferentes nuvens.	A réplica não tem de ser a base de dados gerida pelo fornecedor de nuvem (consulte A função da tecnologia de migração de bases de dados em padrões de implementação).	Apenas numa nuvem, não em várias nuvens, se a base de dados fornecer replicação bidirecional.	Apenas numa nuvem, não em várias nuvens, se a base de dados fornecer sincronização primária-primária.
Bases de dados pré-nuvem	Os sistemas de base de dados podem ser iguais ou diferentes em nuvens diferentes.	A replicação é possível em várias nuvens.	O sistema de base de dados oferece replicação bidirecional e resolução de conflitos.	O sistema de base de dados oferece sincronização primária-primária.
Bases de dados geridas por parceiros na nuvem	Os sistemas de base de dados podem ser diferentes em diferentes nuvens. Se o parceiro fornecer um sistema de base de dados gerido em todas as nuvens necessárias, pode usar a mesma base de dados.	A réplica não tem de ser a base de dados gerida pelo fornecedor de nuvem. Se o parceiro fornecer um sistema de base de dados gerido em todas as nuvens necessárias, pode usar a mesma base de dados.	O sistema de base de dados oferece replicação bidirecional e resolução de conflitos.	O sistema de base de dados oferece sincronização primária-primária.

Se um sistema de base de dados não fornecer replicação incorporada, pode ser possível usar a tecnologia de replicação de base de dados. Para mais informações, consulte O papel da tecnologia de migração de bases de dados nos padrões de implementação.

A tabela seguinte relaciona os padrões de implementação com os modelos de distribuição. Os campos indicam as condições para as quais a combinação é possível, dado um padrão de implementação e um modelo de distribuição.

Modelo de distribuição	Padrão de implementação
	Particionada sem dependência entre bases de dados	Replicação unidirecional assíncrona	Replicação bidirecional com resolução de conflitos	Sistema distribuído sincronizado totalmente ativo-ativo
Instância única	Possível com o mesmo ou um sistema de base de dados diferente nas nuvens envolvidas.	Não aplicável	Não aplicável	Não aplicável
Ativo-passivo com várias instâncias	Possível com o mesmo ou um sistema de base de dados diferente nas nuvens envolvidas.	A replicação é possível entre nuvens.	A replicação é possível entre nuvens.	Não aplicável
Ativo-ativo com várias instâncias	Possível com o mesmo ou um sistema de base de dados diferente nas nuvens envolvidas.	Não aplicável	Não aplicável	A sincronização é possível entre nuvens.
Ativo-ativo com várias instâncias e resolução de conflitos	Possível com o mesmo ou um sistema de base de dados diferente nas nuvens envolvidas.	Não aplicável	Não aplicável	Aplicável se a replicação bidirecional for possível em várias nuvens.

Algumas implementações de modelos de distribuição que adicionam abstração adicional com base na tecnologia de base de dados subjacente não têm um modelo de distribuição incorporado, por exemplo, o Postgres-BDR, um sistema ativo-ativo. Estes sistemas estão incluídos na tabela anterior na respetiva categoria. Do ponto de vista da multinuvem, é irrelevante a forma como um modelo de distribuição é implementado.

Migração e replicação de bases de dados

Consoante o exemplo de utilização, uma empresa pode ter de migrar uma base de dados de uma localização de implementação para outra. Em alternativa, para o processamento a jusante, pode ter de replicar os dados de uma base de dados para outra localização. Na secção seguinte, a migração e a replicação de bases de dados são abordadas com mais detalhe.

Migração de base de dados

A migração de bases de dados é usada quando uma base de dados está a ser movida de uma localização de implementação para outra. Por exemplo, uma base de dados executada num centro de dados nas instalações é migrada para ser executada na nuvem. Após a conclusão da migração, a base de dados é encerrada no centro de dados no local.

As principais abordagens à migração de bases de dados são as seguintes:

• Recortar e guardar. A VM e os discos que executam as instâncias da base de dados são copiados para o ambiente de destino tal como estão. Depois de copiados, são iniciados e a migração fica concluída.
• Exportação e importação, bem como cópia de segurança e restauro. Ambas as abordagens usam a funcionalidade do sistema de base de dados para externalizar uma base de dados e recriá-la na localização de destino. Normalmente, a exportação/importação baseia-se num formato ASCII, enquanto a cópia de segurança e o restauro se baseiam num formato binário.
• Migração sem inatividade. Nesta abordagem, é migrada uma base de dados enquanto os sistemas de aplicações acedem ao sistema de origem. Após um carregamento inicial, as alterações são transmitidas da origem para a base de dados de destino através de tecnologias de captura de dados de alterações (CDC). A aplicação incorre em tempo de inatividade desde o momento em que é interrompida no sistema de base de dados de origem até ser reiniciada no sistema de base de dados de destino após a conclusão da migração.

A migração de bases de dados torna-se relevante em exemplos de utilização de várias nuvens quando uma base de dados é movida de uma nuvem para outra ou de um tipo de motor de base de dados para outro.

A migração de bases de dados é um processo multifacetado. Para mais informações, consulte os artigos Migração de base de dados: conceitos e princípios (parte 1) e Migração de base de dados: conceitos e princípios (parte 2).

As tecnologias de base de dados incorporadas podem ser usadas para fazer a migração da base de dados, por exemplo, exportação e importação, cópia de segurança e restauro, ou protocolos de replicação incorporados. Quando o sistema de origem e o sistema de destino são sistemas de bases de dados diferentes, as tecnologias de migração são a melhor opção para a migração de bases de dados. O Database Migration Service, o Striim e o Debezium são exemplos de tecnologias de migração de bases de dados.

Replicação de base de dados

A replicação de bases de dados é semelhante à migração de bases de dados. No entanto, durante a replicação da base de dados, o sistema de base de dados de origem permanece no local enquanto todas as alterações são transmitidas para a base de dados de destino.

A replicação da base de dados é um processo contínuo que envia alterações da base de dados de origem para a base de dados de destino. Quando este processo é assíncrono, as alterações chegam à base de dados de destino após um pequeno atraso. Se o processo for síncrono, as alterações ao sistema de origem são feitas ao sistema de destino ao mesmo tempo e às mesmas transações.

Além de replicar uma origem para uma base de dados de destino, uma prática comum é replicar dados de uma base de dados de origem para um sistema de estatísticas de destino.

Tal como na migração de bases de dados, se estiverem disponíveis protocolos de replicação, pode usar a tecnologia de base de dados integrada para a replicação de bases de dados. Se não existirem protocolos de replicação incorporados, é possível usar tecnologia de replicação, como o Datastream, o Striim ou o Debezium.

O papel da tecnologia de migração de bases de dados nos padrões de implementação

A tecnologia de base de dados incorporada para ativar a replicação não está geralmente disponível quando são usados diferentes sistemas de base de dados em padrões de implementação, por exemplo, a replicação assíncrona (heterogénea). Em alternativa, pode implementar tecnologia de migração de bases de dados para ativar este tipo de replicação. Alguns destes sistemas de migração também implementam a replicação bidirecional.

Se a tecnologia de migração ou replicação de bases de dados estiver disponível para os sistemas de bases de dados usados em combinações marcadas como "Não aplicável" na Tabela 1 ou na Tabela 2 em Mapeamento de sistemas de bases de dados para padrões de implementação, pode ser possível usá-la para a replicação de bases de dados. O diagrama seguinte mostra uma abordagem para a replicação da base de dados através de uma tecnologia de migração.

No diagrama anterior, a base de dados na localização 1 é replicada para a base de dados na localização 2. Em vez de uma replicação direta do sistema de base de dados, é implementado um servidor de migração para implementar a replicação. Esta abordagem é usada para sistemas de base de dados que não têm funcionalidade de replicação de base de dados incorporada na respetiva implementação e que precisam de depender de um sistema separado do sistema de base de dados para implementar a replicação.

Seleção de base de dados multicloud

Os exemplos de utilização de bases de dados em várias nuvens, combinados com a categorização do sistema de base de dados, ajudam a decidir que bases de dados são mais adequadas para um determinado exemplo de utilização. Por exemplo, para implementar o exemplo de utilização na Portabilidade de aplicações, existem duas opções. A primeira opção é garantir que o mesmo motor de base de dados está disponível em todas as nuvens. Esta abordagem garante a portabilidade do sistema. A segunda opção é garantir que o mesmo modelo de dados e interface de consulta estão disponíveis para todas as nuvens. Embora os sistemas de base de dados possam ser diferentes, a portabilidade é fornecida numa interface funcional.

As árvores de decisão nas secções seguintes mostram os critérios de tomada de decisões para os exemplos de utilização de bases de dados em várias nuvens neste documento. As árvores de decisões sugerem a melhor base de dados a considerar para cada exemplo de utilização.

Práticas recomendadas para o sistema de base de dados existente

Se um sistema de base de dados estiver em produção, tem de ser tomada uma decisão sobre se o mantém ou o substitui. O diagrama seguinte mostra as perguntas a fazer no seu processo de decisão:

As perguntas e as respostas na árvore de decisão são as seguintes:

• Existe um sistema de base de dados em produção?
  • Se não existir nenhum sistema de base de dados em produção, selecione um sistema de base de dados (avance para a secção Decisão sobre a gestão de bases de dados em várias nuvens).
  • Se um sistema de base de dados estiver em produção, avalie se deve ser mantido.
• Se um sistema de base de dados estiver em produção, avalie se deve ser mantido.
  • Se o sistema de base de dados deve ser mantido, a decisão é tomada e o processo de decisão está concluído.
  • Se o sistema de base de dados tiver de ser alterado ou se a decisão ainda estiver a ser tomada, selecione um sistema de base de dados (avance para a secção Decisão sobre a gestão de bases de dados em várias nuvens).

Decisão sobre a gestão de bases de dados em várias nuvens

A seguinte árvore de decisões destina-se a um exemplo de utilização com um requisito de base de dados com várias localizações (incluindo uma implementação de base de dados em várias nuvens). Usa o padrão de implementação como base para os critérios de tomada de decisões.

As perguntas e as respostas na árvore de decisão são as seguintes:

• Os dados estão divididos em diferentes bases de dados sem qualquer dependência entre bases de dados?
  • Se sim, podem ser selecionados sistemas de base de dados iguais ou diferentes para cada localização.
  • Em caso negativo, avance para a pergunta seguinte.
• A replicação unidirecional assíncrona é necessária?
  • Em caso afirmativo, avalie se um sistema de replicação de base de dados é aceitável.
    • Se sim, selecione sistemas de base de dados iguais ou diferentes que sejam compatíveis com o sistema de replicação.
    • Se não, selecione um sistema de base de dados que possa implementar um modelo de distribuição ativo-passivo.
    • Em caso negativo, avance para a pergunta seguinte.
• Selecione um sistema de base de dados com instâncias sincronizadas.
  • A resolução de conflitos é aceitável?
    • Se sim, selecione um sistema de base de dados de replicação bidirecional ou um sistema de base de dados ativo-ativo.
    • Se não, selecione um sistema ativo-ativo.

Se for implementado mais do que um exemplo de utilização de várias nuvens, uma empresa tem de decidir se quer usar um sistema de base de dados para suportar todos os exemplos de utilização ou vários sistemas de base de dados.

Se uma empresa quiser usar um sistema de base de dados para suportar todos os exemplos de utilização, o sistema com a melhor sincronização é a melhor escolha. Por exemplo, se a replicação unidirecional for necessária, bem como instâncias sincronizadas, a melhor escolha são as instâncias sincronizadas.

A hierarquia da qualidade de sincronização é (de nenhuma a melhor): particionada, replicação unidirecional, replicação bidirecional e replicação totalmente sincronizada.

Práticas recomendadas de implementação

Esta secção realça as práticas recomendadas a seguir quando escolhe uma base de dados para a migração ou o desenvolvimento de aplicações multicloud.

Sistema de gestão de bases de dados existente

Pode ser uma boa prática manter uma base de dados e não fazer alterações ao sistema de base de dados, a menos que seja exigido por um exemplo de utilização específico. Para uma empresa com um sistema de gestão de bases de dados estabelecido e que tenha processos de desenvolvimento, operacionais e de manutenção eficazes, pode ser melhor evitar fazer alterações.

Um exemplo de utilização de expansão rápida na nuvem que não requer um sistema de base de dados na nuvem pode não precisar de uma alteração da base de dados. Outro exemplo de utilização é a replicação assíncrona para uma localização de implementação diferente na mesma nuvem ou para outra nuvem. Para estes exemplos de utilização, uma boa abordagem é implementar uma referência e verificar se a comunicação entre localizações e a latência satisfazem os requisitos da aplicação quando acedem à base de dados.

Sistema de base de dados como serviço do Kubernetes

Se uma empresa estiver a considerar executar um sistema de base de dados no Kubernetes como um serviço baseado em StatefulSets, tem de ter em conta os seguintes fatores:

• Se a base de dados fornecer o modelo de base de dados exigido pela aplicação.
• Fatores não funcionais que determinam como a operacionalização é implementada num sistema de base de dados como um serviço do Kubernetes. Por exemplo, como é feita a escalabilidade (aumentar e diminuir a escala), como são geridas a cópia de segurança e o restauro e como a monitorização é disponibilizada pelo sistema. Para ajudar as empresas a compreenderem os requisitos de um sistema de base de dados baseado no Kubernetes, devem usar as suas experiências com bases de dados como ponto de comparação.
• Alta disponibilidade e recuperação de desastres. Para oferecer alta disponibilidade, o sistema tem de continuar a funcionar quando uma zona numa região falha. A base de dados tem de conseguir fazer rapidamente a comutação por falha de uma zona para outra. No melhor cenário possível, a base de dados tem uma instância em execução em cada zona totalmente sincronizada para um RTO e um RPO de zero.
• Recuperação de desastres para resolver a falha de uma região (ou nuvem). Num cenário ideal, a base de dados continua a funcionar numa segunda região com um RPO e um RTO de zero. Num cenário menos ideal, a base de dados na região secundária pode não estar totalmente atualizada em relação a todas as transações da base de dados principal.

Para determinar a melhor forma de executar uma base de dados no Kubernetes, uma avaliação completa da base de dados é uma boa abordagem, especialmente quando o sistema tem de ser comparável a um sistema em produção fora do Kubernetes.

Sistema de base de dados independente do Kubernetes

Nem sempre é necessário que uma aplicação implementada como serviços no Kubernetes tenha a base de dados em execução no Kubernetes ao mesmo tempo. Existem muitos motivos pelos quais um sistema de base de dados tem de ser executado fora do Kubernetes, por exemplo, processos estabelecidos, conhecimento do produto numa empresa ou indisponibilidade. As bases de dados geridas por parceiros na nuvem e fornecedores de nuvem enquadram-se nesta categoria.

É igualmente possível e viável executar uma base de dados num Compute Engine. Quando seleciona um sistema de base de dados, é uma boa prática fazer uma avaliação completa da base de dados para garantir que todos os requisitos de uma aplicação são cumpridos.

Do ponto de vista do design da aplicação, a partilha de ligações é uma consideração de design importante. Um serviço de aplicação que aceda a uma base de dados pode usar um conjunto de ligações internamente. A utilização de uma pool de ligações é boa para a eficiência e reduz a latência. Os pedidos são retirados do conjunto sem necessidade de serem iniciados, e não há espera pela criação de ligações. Se a aplicação for dimensionada adicionando instâncias do serviço de aplicações, cada instância cria um conjunto de ligações. Se as práticas recomendadas forem seguidas, cada conjunto pré-cria um conjunto mínimo de ligações. Sempre que é criada outra instância do serviço de aplicação para o escalamento de aplicações, são adicionadas ligações à base de dados. Do ponto de vista do design, uma vez que as bases de dados não podem suportar um número ilimitado de ligações, a adição de ligações tem de ser gerida para evitar a sobrecarga.

Melhor sistema de base de dados versus portabilidade do sistema de base de dados

Ao selecionar sistemas de bases de dados, é comum as empresas selecionarem o melhor sistema de bases de dados para satisfazer os requisitos de uma aplicação. Num ambiente de várias nuvens, pode selecionar a melhor base de dados em cada nuvem e ligá-las entre si com base no exemplo de utilização. Se estes sistemas forem diferentes, qualquer replicação, unidirecional ou bidirecional, requer um esforço significativo. Esta abordagem pode ser justificada se a vantagem de usar o melhor sistema compensar o esforço necessário para o implementar.

No entanto, é uma boa prática considerar e avaliar em simultâneo uma abordagem para um sistema de base de dados que esteja disponível em todas as nuvens necessárias. Embora uma base de dados deste tipo possa não ser tão ideal como a melhor opção, pode ser muito mais fácil de implementar, operar e manter um sistema deste tipo.

Uma avaliação simultânea do sistema de base de dados demonstra as vantagens e as desvantagens de ambos os sistemas de base de dados, o que oferece uma base sólida para a seleção.

Replicação do sistema de base de dados incorporado versus externo

Para exemplos de utilização que requerem um sistema de base de dados em todas as localizações de implementação (zonas, regiões ou nuvens), a replicação é uma funcionalidade importante. A replicação pode ser assíncrona, bidirecional ou replicação ativa-ativa totalmente sincronizada. Nem todos os sistemas de base de dados suportam todas estas formas de replicação.

Para os sistemas que não suportam a replicação como parte da respetiva implementação do sistema, podem ser usados sistemas como o Striim para complementar a arquitetura (conforme abordado na secção Migração da base de dados).

Uma prática recomendada é avaliar sistemas de gestão de bases de dados alternativos para determinar as vantagens e as desvantagens de um sistema com replicação incorporada ou um sistema que requer tecnologia de replicação.

Uma terceira classe de tecnologia também desempenha um papel neste caso. Esta classe fornece suplementos aos sistemas de base de dados existentes para oferecer replicação. Um exemplo é o MariaDB Galera Cluster. Se o processo de avaliação o permitir, a avaliação destes sistemas é uma boa prática.

Bases de dados multimodelos

As bases de dados multimodelos oferecem uma gestão de dados flexível e escalável na nuvem e em aplicações em tempo real. As bases de dados multimodelos suportam vários modelos de dados, como documentos, gráficos, chave-valor, família de colunas e relacionais, numa interface de consulta e num motor de armazenamento unificados. Estas capacidades oferecem vantagens como as seguintes:

• Gestão simplificada: os programadores gerem vários tipos de dados num único sistema de base de dados, o que ajuda a reduzir a complexidade operacional e os custos gerais.
• Desenvolvimento mais rápido: as bases de dados multimodelos oferecem a flexibilidade de usar o modelo de dados ideal para diferentes necessidades. Esta flexibilidade pode acelerar o desenvolvimento e ajudar a adaptar-se mais rapidamente aos requisitos em constante mudança.
• Integração mais fácil: uma interface de consulta unificada e um motor de armazenamento minimizam a complexidade da ligação e sincronização de bases de dados distintas.
• Consultas melhoradas: os programadores podem consultar e combinar dados em diferentes modelos, o que permite estatísticas mais detalhadas e funcionalidades de aplicações mais sofisticadas.
• Poupança de custos: menos sistemas de bases de dados traduzem-se em custos mais baixos para licenciamento, hardware e despesas operacionais.
• Desempenho otimizado: ao escolher o modelo de dados mais adequado para tarefas específicas, pode melhorar potencialmente o desempenho da aplicação.

Por exemplo, o Spanner oferece funcionalidades multimodelos com suporte do dialeto PostgreSQL. Esta capacidade permite-lhe criar apps inteligentes baseadas em IA usando dados relacionais e NoSQL, consultar relações complexas com o Spanner Graph e usar a pesquisa vetorial para a pesquisa semântica.

O que se segue?

• Saiba mais sobre os padrões de arquitetura híbrida e multicloud.
• Leia acerca dos padrões para associar outros fornecedores de serviços na nuvem ao Google Cloud.
• Saiba mais sobre as arquiteturas de monitorização e registo para implementações híbridas e multicloud no Google Cloud.
• Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.

Colaboradores

Autor: Alex Cârciu | Solutions Architect