Tabelas Ativas Globais no NDCS

O Oracle NoSQL Database Cloud Service suporta uma arquitetura de tabela ativa global na qual você pode criar tabelas, replicá-las em várias regiões e manter dados sincronizados entre as réplicas regionais.

As empresas de hoje precisam fornecer serviços melhores e mais rápidos aos seus clientes. A latência de rede é um parâmetro crucial para avaliar o desempenho de qualquer aplicativo. Latência de rede é o tempo mínimo que um pacote de dados leva para percorrer a rede. Os usuários esperam concluir suas atividades on-line de forma suave e rápida de qualquer lugar. Para atender a essas expectativas, as empresas precisam hospedar aplicativos e dados em regiões distribuídas mais próximas de seus usuários.

O Oracle NoSQL Database Cloud Service fornece uma solução para esses requisitos por meio de tabelas Globais Ativas. Esse recurso permite que os dados do aplicativo gravados em uma região sejam replicados de forma transparente em várias regiões.

Benefícios das Tabelas Ativas Globais:

Ler e gravar localmente e acessar seus dados globalmente: Uma configuração ativo-ativo de tabelas Globais Ativas em várias regiões garante que uma atualização executada em uma tabela em uma região seja replicada automaticamente para as réplicas da tabela em outras regiões de replicação. Os dados podem ser acessados de qualquer região replicada.
Desempenho: as tabelas Ativas Globais permitem que você leia e grave seus dados localmente, fornecendo latência de milissegundos de um dígito, que é característica do acesso local para seu aplicativo distribuído globalmente em qualquer escala. Isso pode aumentar o desempenho de aplicativos globais em grande escala e reduzir a latência para solicitações de aplicativos.
Fácil de configurar e gerenciar: O Oracle NoSQL Database Cloud Service elimina a complexidade de implantar e gerenciar a replicação de várias regiões usando tabelas Globais Ativas. A adição de réplicas de tabela regionais é simples e pode ser feita usando APIs, Terraform ou o console do OCI.
Resiliência em Várias Regiões: As tabelas Ativas Globais também permitem a tolerância a falhas no caso raro de uma falha de região. Se uma única região ficar indisponível ou off-line, as solicitações do aplicativo poderão ser redirecionadas para uma região em que a tabela seja replicada, e as leituras e gravações poderão ser executadas nessa tabela.

Como selecionar uma configuração ativa global no NDCS?

O recurso de tabelas Ativas Globais permite que os dados do aplicativo gravados em uma região sejam replicados de forma transparente em várias regiões.

Um evento raro de uma falha de região única não deve afetar a experiência dos usuários. Por exemplo, se uma única região se tornar off-line, isolada ou degradada, seu aplicativo deverá ser redirecionado para outra região e continuar a executar leituras e gravações como antes. Em suma, seu banco de dados precisa fornecer recuperação de desastre mesmo quando uma região falha. Você pode usar uma tabela Global Active no Oracle NoSQL Database Cloud Service (NDCS) para fornecer recuperação de desastres por meio de configuração ativo-ativo ou para replicar dados ativamente em várias regiões para obter baixa latência usando acesso a dados locais.

Considere as necessidades de um usuário viajante que faz compras em um site popular. Eles podem acessar o mesmo site de compras de diferentes partes do mundo no mesmo dia. Você precisa garantir que o usuário experimente uma latência mínima e uma interação perfeita, não importa onde eles estejam.

O recurso da tabela Global Active no NDCS fornece uma solução para ambos os cenários discutidos acima. Vamos explorar cada um dos dois cenários e entender como uma tabela Global Active será a melhor solução para fornecer alta disponibilidade, baixa latência e recuperação de desastres.

No primeiro cenário, suponha que sua empresa use o NDCS em Phoenix (EUA -Oeste), Frankfurt (Alemanha) e Tóquio (Japão) e você tenha uma tabela chamada ShoppingCart, que armazena as informações de compras de clientes que estão comprando em diferentes regiões do mundo. Neste exemplo, sua empresa está atendendo seus clientes por meio de data centers geograficamente mais próximos deles. Essa configuração envolve vários locais geográficos em que o Oracle NoSQL Database Cloud Service está disponível. Uma arquitetura com duas ou mais regiões distribuídas geograficamente e o serviço NoSQL Database Cloud disponível em cada uma dessas regiões é conhecida como umaarquitetura de tabela global ativa. A tabela ShoppingCart é uma tabela Ativa Global e é replicada em várias regiões.

Em uma configuração ativo-ativo, você tem o NDCS disponível em várias regiões e os dados em todas as regiões são sincronizados. Quando uma região falha, as tabelas Ativas Globais nas outras regiões de réplica continuarão funcionando normalmente e não serão afetadas pela região com falha. Quando a região com falha voltar, sua réplica de tabela regional será sincronizada com as outras regiões. A tabela Global Active fornece recuperação de desastre na medida em que, quando uma região está inativa, seu aplicativo está conectado a outra réplica.

No segundo cenário, suponha que o usuário em Phoenix, faça compras on-line e adicione um celular ao carrinho de compras. A região NDCS da costa oeste atende a essa sessão e o usuário experimenta latência mínima de solicitação de leitura e gravação no armazenamento de dados local da região. Este usuário então entra em um avião para a Alemanha, pousa 13 horas depois, chega ao hotel, se conecta à rede Wi-Fi, vai para a loja on-line da empresa móvel e descobre que há outro modelo do telefone que parece mais atraente. Assim, o usuário decide atualizar o carrinho de compras com este novo modelo do telefone e continua a navegar na loja de comércio eletrônico móvel. O armazenamento de dados regional em Frankfurt, que é o armazenamento de dados mais proximal, atende a esta sessão e fornece ao usuário a mesma experiência de leitura e gravação de baixa latência que a dos EUA. Em seguida, o usuário viaja para o Japão e decide visitar uma loja móvel local para obter mais informações sobre os modelos móveis mais recentes. O usuário então atualiza o carrinho de compras com o modelo mais recente do telefone que está presente na loja móvel. Como o NoSQL Database Cloud Service está disponível em três regiões, uma em Phoenix, a segunda na Alemanha e a terceira no Japão, há mais de uma réplica de tabela regional, sempre que o usuário atualiza o carrinho de compras ou navega na loja de e-commerce móvel, os resultados de pesquisa personalizados e outros dados são extraídos de uma região local mais próxima do usuário. Esse tipo de processamento local oferece as latências mais baixas, o melhor desempenho e elimina o acesso à rede de longa distância.

Conceitos Básicos

Terminologia usada nas tabelas Ativas Globais:

Região: Uma região da Oracle Cloud Infrastructure (OCI).
Região do Remetente: Uma região de onde uma atualização de tabela é replicada para outras regiões.
Região do Recebedor: Uma região que recebe a atualização da tabela de outra região.
Tabela única: Uma tabela que não é replicada regionalmente.
Réplica da tabela regional: Uma réplica de uma tabela criada em outra região.
Tabela Global Ativa: Uma tabela que tem uma ou mais réplicas de tabela regional.

Regras básicas para criar e gerenciar tabelas Ativas Globais:

Os critérios a seguir devem ser atendidos para criar e gerenciar uma tabela Global Ativa.

O estado do esquema da tabela deve ser FROZEN.
Na região do receptor, uma tabela com o mesmo nome ainda não deve existir.
Na região do receptor, o compartimento (com o mesmo nome do da região do remetente) já deve existir.
Antes de eliminar uma tabela ativa global, todas as réplicas da tabela regional devem ser removidas.

Observação: No NDCS, a replicação de tabela regional é executada de forma assíncrona em segundo plano.

Você pode criar tabelas filho em uma Tabela Ativa Global. Uma tabela filho de uma tabela Ativa Global pode ser uma tabela única ou uma Tabela Ativa Global. Para tornar a tabela filho uma tabela Ativa Global, você precisa congelar o esquema da tabela filho e adicionar uma réplica regional. É possível selecionar uma das réplicas regionais da tabela pai.

Workflow da Tabela Ativa Global

O que é replicado em uma tabela Ativa Global?

Ao adicionar uma réplica de tabela regional de uma tabela NoSQL existente, você converte a tabela única em uma tabela Global Ativa. O seguinte será replicado em uma tabela.

Definição/esquema da tabela
Índices na tabela - Número e definições de índices secundários.
Dados na tabela.
Capacidade de Armazenamento - Como todas as réplicas regionais da tabela Global Active armazenam os mesmos dados da tabela, o limite de armazenamento de uma réplica regional é copiado para todas as outras réplicas regionais da tabela Global Active.
Table Time to Live (TTL) padrão da tabela
Capacidade de leitura e capacidade de gravação - Por padrão, o limite de leitura de uma réplica regional é o mesmo de qualquer outra réplica regional da Tabela Ativa Global. No entanto, as operações de leitura são puramente locais, portanto, você pode definir opcionalmente os próprios limites de leitura de cada região. Por padrão, o limite de gravação de uma réplica regional é o mesmo de qualquer outra réplica regional da tabela Ativo Global. No entanto, os limites de gravação podem ser definidos para valores diferentes em cada região.

Observação: As tags do OCI permitem que você adicione metadados aos recursos. Uma ou mais tags podem ser associadas a uma tabela Global Ativa. As tags do OCI não são replicadas, e uma Tabela Ativa Global pode ter diferentes tags em diferentes regiões.

Adicionando uma réplica de tabela regional

Quando você replica uma tabela, ela é criada em outra região, chamada de região do receptor. Se a tabela na região do remetente for um singleton, ela será convertida em uma tabela Global Ativa. Se a tabela na região do remetente já for uma tabela Global Ativa, outra réplica regional será adicionada à tabela. A réplica regional é inicializada com os dados da tabela da região do remetente. Por exemplo, se a tabela na região do remetente tiver 1000 linhas, todos os dados serão copiados para a réplica regional recém-criada.

Observação: Quando você adiciona uma réplica de tabela regional, a tabela na região do receptor é colocada no mesmo compartimento com o mesmo nome de tabela da região do remetente. Durante a vida útil da tabela Global Active, você pode mover essa tabela para outro compartimento a qualquer momento.

Capacidade (Unidades de Leitura, Unidades de Gravação e Armazenamento) para réplicas de tabela regionais

Quando você adiciona uma réplica regional de uma tabela, os campos capacidade de leitura, capacidade de gravação e capacidade de armazenamento assumem automaticamente como padrão os valores correspondentes da tabela na região do remetente. No entanto, você pode editar e alterar os valores da capacidade de leitura e gravação da tabela na região do receptor. Não é possível alterar a capacidade de armazenamento da tabela. A tabela na região do receptor tem a mesma capacidade de armazenamento que a tabela na região do remetente. O modo de capacidade de uma tabela Global Ativa pode ser sob demanda ou provisionado. Você também pode alterar o modo de capacidade de qualquer réplica regional de uma tabela Ativa Global após sua criação. A alteração no modo de capacidade é local para essa réplica regional e não afeta nenhuma outra réplica regional da tabela Ativo Global.

TTL de registros em réplicas de tabela regionais

Tempo de Vida Útil (TTL) é expresso como o tempo (número de horas ou dias) que os dados podem viver na tabela. O Oracle NoSQL Database Cloud Service permite aos desenvolvedores definir um tempo de expiração nas linhas de tabela, após o qual as linhas expiram automaticamente e não estão mais disponíveis. Após a duração especificada, as linhas expiram automaticamente e não estão mais disponíveis. O TTL na réplica da tabela regional é o mesmo valor do TTL da tabela na região do remetente. Quando uma linha é replicada para outras regiões, seu tempo de expiração é replicado como um timestamp absoluto. Portanto, essa linha expirará ao mesmo tempo, independentemente de quando foi replicada.

Depois que uma réplica de tabela regional é criada, ela é inicializada com os dados da tabela da região do remetente. Durante essa inicialização dos dados da tabela, se o valor TTL for atingido, essas linhas expirarão e uma operação de leitura não verá esses registros.

Escopo das operações DDL após a criação de réplicas de tabela regional:

As operações DDL a seguir têm escopo global, o que significa que uma alteração em uma réplica de tabela regional é automaticamente propagada para todas as réplicas de tabela regionais.

Adicionar Índice
Eliminar Índice
Alteração na Capacidade de Armazenamento da tabela
Alteração na tabela TTL

As operações DDL a seguir têm um escopo local, o que significa uma alteração apenas na réplica de tabela regional em que ela é iniciada.

Alteração nas Unidades de Leitura
Alteração nas unidades de Gravação
Alteração no Modo de Capacidade do On-Demand para provisionado ou vice-versa

Considerações sobre Modelagem de Dados para Tabelas Ativas Globais

Por que você deve congelar o esquema de uma tabela?

Em uma configuração de tabela Global Ativa, você tem tabelas no NDCS implantadas em várias regiões, e todas as regiões estão atendendo simultaneamente a solicitações de leitura e gravação. O aplicativo que se conecta ao NDCS deve ser projetado para estabelecer conexão com a região de replicação mais próxima. A chave primária, a chave de partição e os dados da tabela devem ser idênticos nas regiões de replicação, pois esses três são uma parte intrínseca de como o aplicativo usa a tabela e como as consultas são executadas. Em uma tabela Global Ativa, como os registros de tabela podem ser gravados simultaneamente na tabela em várias regiões, torna-se necessário obter um consenso sobre o esquema da tabela. Você pode fazer isso impedindo que o esquema seja alterado, forçando todas as regiões a um consenso imediato sobre o esquema de uma tabela. Por simplicidade, desempenho e previsibilidade, o Oracle NoSQL Cloud Service requer o congelamento de um esquema para qualquer tabela que esteja participando da replicação regional. Assim, antes de converter uma tabela única em uma tabela Ativa Global, o esquema da tabela deve ser congelado e nenhuma alteração de esquema adicional é permitida. Caso precise alterar o esquema de uma tabela Global Ativa após criar réplicas regionais, primeiro elimine todas as réplicas regionais, altere o esquema da tabela e, em seguida, adicione novamente as réplicas regionais. O Oracle NoSQL Cloud Service preencherá novamente todas as réplicas regionais com os dados mais atuais da região do remetente. Por esse motivo, recomenda-se ter pelo menos uma coluna JSON na tabela, pois ela fornece mais flexibilidade no esquema e impede a necessidade de uma alteração de esquema.

Definindo a Identidade em uma Tabela Ativa Global

A identidade de um registro em uma réplica de tabela regional deve ser exclusiva em todas as réplicas regionais da tabela. As chaves naturais (identificadores globais exclusivos que identificam cada registro em uma tabela) só poderão ser usadas como identidade nas tabelas do Global Active se puderem garantir a exclusividade em todas as réplicas de tabela regionais.
Ao usar a identidade gerada pelo sistema em uma tabela Global Ativa, o UUID deve ser usado. Na maioria dos casos, a coluna de identidade não deve ser usada porque não é garantido que seja exclusiva entre réplicas de tabela regionais.

Políticas e permissões do usuário

As políticas de IAM de uma tabela são específicas para a região do remetente.

Quando um usuário adiciona uma réplica de uma tabela singleton ou Global Active, nenhuma política ou permissão de usuário é adicionada à região do receptor. O usuário na região de origem que deseja criar e gerenciar réplicas também deve ter os privilégios necessários na região do receptor. Caso contrário, você receberá um erro quando o usuário adicionar uma réplica da tabela regional.

Depois que as réplicas da tabela regional forem criadas, a replicação de qualquer modificação de dados de uma região do remetente para a região do destinatário não exigirá permissão do usuário. Isso significa que a alteração de dados em uma tabela de réplicas será replicada em todas as outras réplicas de tabela, independentemente da permissão do usuário. As permissões necessárias para criar e gerenciar as réplicas da tabela regional estão listadas abaixo.

Adicionar réplica:

Os usuários que desejam gerenciar réplicas de uma tabela devem ter a permissão NOSQL_TABLE_ALTER na região do remetente e em todas as regiões do recebedor existentes. Os usuários que desejam criar uma nova réplica precisam ter a permissão NOSQL_TABLE_CREATE na região do receptor (em que uma réplica deve ser criada). Quando você cria uma réplica de tabela regional, a permissão de leitura e gravação existente da tabela na região do remetente não é criada na região do recebedor. Os usuários que desejam criar uma nova réplica na região do receptor são responsáveis por criar as permissões de leitura e gravação da tabela para cada réplica da tabela regional que eles criam.

Eliminar réplica:

Criar Índice:

Os usuários que desejam criar índices em réplicas de tabela regionais precisam ter a permissão NOSQL_INDEX_CREATE .

Eliminar Índice:

Os usuários que desejam eliminar índices em réplicas de tabelas regionais precisam ter a permissão NOSQL_INDEX_DROP .

Atualizar limites de tabela/TTL/:

Os usuários que desejam gerenciar réplicas de uma tabela devem ter a permissão NOSQL_TABLE_ALTER em todas as réplicas de tabela regional.

Leituras, Gravações e transações ACID

Depois de criar uma tabela Global Active, você pode executar operações de leitura ou gravação na tabela usando as APIs de acesso a dados ou instruções DML existentes.

Para obter a melhor latência, seu aplicativo geralmente será lido em uma réplica regional local. Os dados na réplica regional local também incluirão as atualizações de dados replicadas de outras réplicas de tabela regional. Sempre que você executar uma operação de gravação (INSERT, UPDATE ou DELETE) em uma tabela Global Active, as alterações serão replicadas em várias regiões de forma assíncrona. Ou seja, quando você escreve uma linha na região do remetente, a operação de gravação é executada completamente na região do remetente sem aguardar a atualização das regiões de réplica. Se várias regiões atualizarem uma linha com a mesma chave primária, uma regra será aplicada para decidir qual atualização da região será considerada final. Em todos esses casos, essa regra de resolução de conflito integrada fará com que a atualização com o timestamp mais recente ganhe e faça commit no banco de dados. Essa regra também se aplica ao atualizar o valor TTL de várias regiões simultaneamente.

As transações ACID são locais para uma região. Quando uma transação é confirmada, ela é garantida apenas como atômica, consistente, isolada e durável, na região onde a gravação ocorreu. A semântica do modelo de consistência de uma réplica de tabela regional é a mesma de uma tabela não replicada. A consistência das réplicas da tabela regional não é absoluta. A consistência absoluta é local para uma única região na qual você executa a operação de leitura. As leituras dos dados que estão sendo replicados da região do remetente para as regiões do destinatário sempre são consistentes.

As gravações de uma região do remetente são replicadas em todas as regiões do destinatário em um intervalo de tempo. Esse intervalo de tempo para replicar as alterações em várias regiões inclui o tempo necessário para receber os dados da réplica da tabela regional na região do remetente e o tempo necessário para concluir as operações de gravação na região do receptor. Eventualmente, a região do receptor obtém a atualização da região do remetente e a região do destinatário nunca perde uma atualização de transação que aconteceu na região do remetente. Todas as réplicas da tabela regional receberão a gravação e se tornarão duráveis.

Visão Geral do Atraso da Réplica

Sempre que você executar uma operação de gravação (INSERT, UPDATE ou DELETE) em uma tabela Global Active, as alterações serão replicadas em várias regiões de forma assíncrona.

Ou seja, quando você escreve uma linha na região do remetente, a operação de gravação é executada completamente na região do remetente sem aguardar a atualização das regiões de réplica. A latência da rede cria um intervalo de tempo na replicação das alterações nas regiões receptoras. A latência para replicar as alterações em várias regiões inclui o tempo necessário para receber gravações da réplica e aplicá-las na região do receptor. Se não houver gravações de aplicativo para a tabela na região do remetente, o serviço usará os mecanismos de ping para calcular uma aproximação do lag, e a estatística de lag ainda estará disponível na região do receptor.

Para obter mais detalhes sobre a métrica Lag de Réplica, consulte Detalhes sobre Lag de Réplica.

Visão geral da criação de uma tabela Global Ativa

O processo de criação de uma tabela Ativa Global começa com a criação de uma tabela única e, em seguida, a conversão em uma tabela Ativa Global

As etapas para criar uma tabela Global Ativa são listadas abaixo.

Crie uma tabela singleton.
Altere o estado do esquema da tabela de Mutável para Congelado.
Decida a região em que deseja adicionar uma réplica regional da tabela. Ao adicionar uma réplica regional, os campos de capacidade de leitura, capacidade de gravação e capacidade de armazenamento são preenchidos automaticamente com os valores correspondentes da região do remetente. Você pode alterar a capacidade de leitura e gravação da tabela.
O serviço de nuvem cria a tabela na região do receptor. Se a tabela na região de origem tiver dados, ela começará a copiar dados da região do remetente para a região do recebedor. À medida que os dados estão sendo copiados da região do remetente para a região do destinatário, a porcentagem de inicialização aumenta de 0 para 100. Você pode exibir o valor da porcentagem de inicialização sob as informações da tabela na console do OCI, conforme mostrado abaixo. Nenhuma operação DML é permitida na nova réplica da tabela regional até que o processo de inicialização seja concluído.

Descrição da ilustração singletab_set.png