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 mais rápidos e melhores 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 viajar pela rede. Os usuários esperam concluir suas atividades on-line sem problemas e rapidamente 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 Ativas Globais. Esse recurso permite que os dados do aplicativo gravados em uma região sejam replicados de forma transparente em várias regiões.
- Leia e grave localmente e acesse seus dados globalmente: Uma configuração ativo-ativo de tabelas Ativas Globais 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 das 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 Ativas Globais. A adição de réplicas de tabela regional é simples e pode ser feita usando APIs, Terraform ou a console do OCI.
- Resiliência Multirregional: As tabelas Ativas Globais também permitem 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 na qual a tabela será replicada e as leituras e gravações poderão ser executadas nessa tabela.
Como escolher uma configuração ativa global no NDCS?
O recurso de tabelas Ativas Globais permite que os dados de aplicativos gravados em uma região sejam replicados de forma transparente em várias regiões.
Um evento raro de falha em uma única região não deve afetar a experiência dos usuários. Por exemplo, se uma única região ficar 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 desastres 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 da configuração ativo-ativo ou 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 tenha latência mínima e uma interação perfeita, não importa onde estejam.
O recurso de tabela Ativa Global no NDCS fornece uma solução para os dois 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árias localizações geográficas em que o Oracle NoSQL Database Cloud Service está disponível. Uma arquitetura que tem 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 uma arquitetura de tabela ativa global. 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 falhar, 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 porque 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 telefone 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 do armazenamento de dados local da região. Este usuário, em seguida, 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. Então 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 essa sessão e fornece ao usuário a mesma experiência de leitura e gravação de baixa latência que a dos EUA. O usuário então 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. Em seguida, o usuário 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 e há mais de uma réplica de tabela regional, sempre que o usuário atualiza o carrinho de compras ou navega na loja de comércio eletrônico móvel, os resultados de pesquisa personalizados e outros dados são obtidos 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 do OCI (Oracle Cloud Infrastructure). É uma única área geográfica localizada na qual os clientes podem implantar seus aplicativos.
- Região 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 de 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:
- A tabela singleton deve ter pelo menos uma coluna JSON.
- O estado do esquema da tabela deve ser FROZEN.
- Na região recebedora, não deve existir uma tabela com o mesmo nome.
- Na região do receptor, o compartimento (com o mesmo nome que o da região do remetente) já deve existir.
- Antes de eliminar uma tabela, todas as réplicas da tabela regional devem ser removidas.
Observação:
No NDCS, a replicação da 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. Você pode escolher uma das réplicas regionais da tabela pai.
Workflow da Tabela Ativa Global
O que é replicado em uma tabela Global Active?
- Definição/esquema da tabela
- Índices na tabela - Número e definições de índices secundários.
- Dados na 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 Global Active. No entanto, os limites de gravação podem ser definidos para valores diferentes em cada região.
- Capacidade de Armazenamento - Como todas as réplicas regionais da tabela Ativo Global 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 Ativo Global.
- Tempo de Vida da Tabela (TTL) padrão da tabela
Adicionando uma réplica de tabela regional
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 tabela na região do remetente. Durante a vida útil da tabela Ativa Global, você pode movê-la para outro compartimento a qualquer momento.Capacidade (Unidades de Leitura, Unidades de Gravação e Armazenamento) para réplicas de tabelas 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 da tabela na região do remetente. O modo de capacidade de uma tabela Ativa Global pode ser sob demanda ou provisionado. Você também pode alterar o modo de capacidade de qualquer réplica regional para 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 regional
Tempo de Vida da Tabela (TTL) é expresso como a quantidade de tempo (número de horas ou dias) que os dados podem permanecer na tabela. O Oracle NoSQL Database Cloud Service permite que os desenvolvedores definam um tempo de expiração nas linhas da tabela, após o qual as linhas expirarão automaticamente e não estarão mais disponíveis. Após a duração especificada, as linhas expirarão automaticamente e não estarão mais disponíveis. O TTL na réplica da tabela regional é o mesmo valor que o 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 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:
- Adicionar Índice
- Eliminar Índice
- Alteração na Capacidade de Armazenamento da tabela
- Alteração na tabela TTL
- Alteração nas Unidades de Leitura
- Alteração nas unidades de Gravação
- Alteração no Modo de Capacidade de Sob Demanda 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 Ativa Global, você tem tabelas no NDCS implantadas em várias regiões e todas as regiões estão atendendo simultaneamente 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 entre as regiões de replicação, pois essas 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 Ativa Global, como os registros da tabela podem ser gravados simultaneamente na tabela em várias regiões, torna-se necessário chegar a 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. Para simplicidade, desempenho e previsibilidade, o Oracle NoSQL Cloud Service requer que um esquema seja congelado para qualquer tabela que esteja participando da replicação regional. Portanto, antes de converter uma tabela singleton em uma tabela Ativa Global, o esquema da tabela deve ser congelado e nenhuma outra alteração de esquema é permitida. Se você precisar alterar o esquema de uma tabela Ativa Global 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 serviço Oracle NoSQL Cloud preencherá novamente todas as réplicas regionais com os dados mais atuais da região de remetente.
Por que pelo menos uma coluna JSON é necessária em uma tabela ao congelar seu esquema?
A coordenação de uma alteração de esquema em réplicas de tabelas regionais é difícil e leva a possíveis casos de erro. Fornecer uma coluna JSON fornece mais flexibilidade no esquema e evita a necessidade de alteração de um esquema.
Definindo 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 exclusivos globais que identificam cada registro em uma tabela) só poderão ser usadas como identidade em tabelas Ativas Globais se puderem garantir exclusividade em todas as réplicas de tabela regionais.
- Ao usar a identidade gerada pelo sistema em uma tabela Ativa Global, 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 regional.
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 de uma tabela Ativa Global, nenhuma política ou permissão do usuário é adicionada na 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 de tabela regional.
Depois que as réplicas de tabela regional são criadas, a replicação de qualquer modificação de dados de uma região remetente para a região recebedora não requer permissão do usuário. Isso significa que a alteração de dados em uma tabela de réplica 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 de tabela regional são listadas abaixo.
Adicionar réplica:
Os usuários que desejam gerenciar réplicas de uma tabela devem ter NOSQL_TABLE_ALTER permissão na região do remetente e em todas as regiões do receptor existentes. Os usuários que desejam criar uma nova réplica precisam ter NOSQL_TABLE_CREATE permissão na região do receptor (onde 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 remetente não é criada na região recebedora. 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 de tabela para cada réplica de tabela regional criada.
Eliminar réplica:
Os usuários que desejam gerenciar réplicas de uma tabela devem ter a permissão NOSQL_TABLE_ALTER na região remetente e em todas as regiões receptoras existentes. Os usuários que desejam eliminar uma réplica precisam ter a permissão NOSQL_TABLE_DROP na região do receptor (em que uma réplica precisa ser eliminada).
Criar Índice:
Os usuários que desejam criar índices em réplicas de tabelas 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 da 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 Ativa Global, 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 Ativa Global, as alterações serão replicadas em várias regiões de forma assíncrona. Ou seja, quando você grava 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 de região será considerada final. Em todos esses casos, essa regra de resolução de conflito incorporada fará com que a atualização com o timestamp mais recente ganhe e se comprometa com o banco de dados. Essa regra também se aplica ao atualizar o valor de TTL de várias regiões simultaneamente.
As transações ACID são locais para uma região. Quando uma transação é submetida a commit, só é garantido que ela seja atômica, consistente, isolada e durável, na região em que 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 de tabela regional não é absoluta. A consistência absoluta é local para uma única região em que 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 são sempre consistentes.
As gravações de uma região remetente são replicadas em todas as regiões receptoras dentro de 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 de tabela regional na região remetente e o tempo necessário para concluir as operações de gravação na região recebedora. Eventualmente, a região do recebedor obtém a atualização da região do remetente e a região do recebedor nunca perde uma atualização de transação que aconteceu na região do remetente. Todas as réplicas de tabela regional acabarão por receber a gravação e se tornarão duráveis.
Visão geral do Atraso na réplica
Sempre que você executar uma operação de gravação (INSERT, UPDATE ou DELETE) em uma tabela Ativa Global, as alterações serão replicadas em várias regiões de forma assíncrona.
Ou seja, quando você grava 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 do receptor. 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 atraso e a estatística de atraso 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 Ativa Global
O processo de criação de uma tabela Ativa Global começa com a criação de uma tabela singleton e, em seguida, convertê-la em uma tabela Ativa Global
- Crie uma tabela singleton e certifique-se de que uma coluna seja JSON.
- Altere o estado do esquema da tabela de Mutável para Congelado.
- Decida a região na qual você 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 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 remetente para a região recebedora. À medida que os dados estão sendo copiados da região do remetente para a região do recebedor, a porcentagem de inicialização aumenta de 0 para 100. Você pode exibir o valor da porcentagem de inicialização nas informações da tabela na console do OCI, conforme mostrado abaixo. Nenhuma operação DML é permitida na nova réplica de tabela regional até que o processo de inicialização seja concluído.
