Tables actives globales dans NDCS

Oracle NoSQL Database Cloud Service prend en charge une architecture de table active globale dans laquelle vous pouvez créer des tables, les répliquer dans plusieurs régions et tenir à jour les données synchronisées entre les répliques régionales.

Les entreprises d'aujourd'hui doivent fournir des services plus rapides et de meilleure qualité à leurs clients. La latence réseau est un paramètre crucial pour évaluer les performances d'une application. La latence réseau est le temps minimal de déplacement d'un paquet de données sur le réseau. Les utilisateurs s'attendent à effectuer leurs activités en ligne facilement et rapidement de n'importe où. Pour répondre à ces attentes, les entreprises doivent héberger des applications et des données dans des régions réparties les plus proches de leurs utilisateurs.

Oracle NoSQL Database Cloud Service fournit une solution à ces besoins au moyen de tableaux Global Active. Cette fonction permet de répliquer de manière transparente les données d'application écrites dans une région.

Avantages des tables actives globales :

Comment sélectionner une configuration globale active dans NDCS?

La fonction Tables actives globales permet de répliquer de manière transparente les données d'application écrites dans une région sur plusieurs régions.

Un événement rare d'une défaillance d'une seule région ne doit pas avoir d'incidence sur l'expérience des utilisateurs. Par exemple, si une seule région devient hors ligne, isolée ou dégradée, votre application doit être redirigée vers une autre région et continuer à effectuer des lectures et des écritures comme précédemment. En bref, votre base de données doit fournir une récupération après sinistre, même en cas de défaillance d'une région. Vous pouvez utiliser un tableau global actif dans Oracle NoSQL Database Cloud Service (NDCS) pour assurer la reprise après sinistre au moyen d'une configuration active-active ou pour répliquer activement des données dans plusieurs régions afin d'obtenir une faible latence en utilisant l'accès aux données locales.

Considérez les besoins d'un utilisateur voyageur qui magasine à partir d'un site Web populaire. Ils peuvent accéder au même site de magasinage de différentes parties du monde le même jour. Vous devez vous assurer que l'utilisateur bénéficie d'une latence minimale et d'une interaction transparente, peu importe où il se trouve.

La fonction Table active globale de NDCS fournit une solution aux deux scénarios décrits ci-dessus. Explorons chacun des deux scénarios et comprenons comment une table Global Active sera la meilleure solution pour fournir une haute disponibilité, une faible latence et une reprise après sinistre.

Dans le premier scénario, supposons que votre société utilise NDCS à Phoenix (États-Unis - Ouest), à Francfort (Allemagne) et à Tokyo (Japon) et que vous disposiez d'une table appelée ShoppingCart, qui stocke les informations de magasinage des clients qui magasinent dans différentes régions du monde. Dans cet exemple, votre entreprise sert ses clients via des centres de données qui sont géographiquement les plus proches d'eux. Une telle configuration implique plusieurs emplacements géographiques où Oracle NoSQL Database Cloud Service est disponible. Une architecture ayant deux régions géographiquement réparties et le service NoSQL Database Cloud disponibles dans chacune de ces régions ou plus est appelée architecture de table active globale. La table ShoppingCart est une table active globale qui est répliquée dans plusieurs régions.

Dans une configuration active-active, NDCS est disponible dans plusieurs régions et les données de toutes les régions sont synchronisées. Lorsqu'une région échoue, les tables actives globales des autres régions de réplique continuent de fonctionner comme d'habitude et ne sont pas affectées par la région en échec. Lorsque la région en échec revient, sa réplique de table régionale est synchronisée avec les autres régions. La table Global Active fournit une récupération après sinistre car lorsqu'une région est en panne, votre application est connectée à une autre réplique.

Dans le deuxième scénario, supposons que l'utilisateur de Phoenix effectue des achats en ligne et ajoute un téléphone mobile à son panier. La région NDCS de la côte ouest dessert cette session et l'utilisateur bénéficie d'une latence de demande de lecture et d'écriture minimale à partir du magasin de données local de la région. Cet utilisateur prend ensuite l'avion pour l'Allemagne, atterrit 13 heures plus tard, se rend à l'hôtel, se connecte au réseau Wi-Fi, se rend à la boutique en ligne de l'entreprise mobile et trouve qu'il existe un autre modèle de téléphone qui semble plus attrayant. Ainsi, l'utilisateur décide de mettre à jour le panier avec ce nouveau modèle de téléphone et continue à parcourir le magasin de commerce électronique mobile. Le magasin de données régional de Francfort, qui est le magasin de données le plus proximal, dessert cette session et offre à l'utilisateur la même expérience de lecture et d'écriture à faible latence que celle des États-Unis. L'utilisateur se rend ensuite au Japon et décide de visiter une boutique mobile locale pour obtenir plus d'informations sur les derniers modèles mobiles. L'utilisateur met ensuite à jour le panier avec le dernier modèle du téléphone présent dans la boutique mobile. Comme le service NoSQL Database Cloud est disponible dans trois régions, une à Phoenix, une deuxième en Allemagne et une troisième au Japon, et il existe plus d'une réplique de table régionale, chaque fois que l'utilisateur met à jour le panier ou parcourt le magasin de commerce électronique mobile, les résultats de recherche personnalisés et d'autres données sont extraits d'une région locale la plus proche de l'utilisateur. Ce type de traitement local offre les latences les plus faibles, les meilleures performances et élimine l'accès réseau étendu.

Concepts de base

Terminologie utilisée dans les tables actives globales :

Règles de base pour la création et la gestion des tables actives globales :

Les critères suivants doivent être satisfaits pour la création et la gestion d'une table active globale.

Note : Dans NDCS, la réplication de table régionale est effectuée de manière asynchrone en arrière-plan.

Vous pouvez créer des tables enfants dans une table active globale. Une table enfant d'une table Global Active peut être une table singleton ou une table Global Active. Pour faire de la table enfant une table active globale, vous devez geler le schéma de la table enfant et ajouter une réplique régionale. Vous pouvez sélectionner l'une des répliques régionales de la table parent.

Flux de travail de table active globale

Que réplique-t-on dans une table Global Active?

Lorsque vous ajoutez une réplique de table régionale d'une table NoSQL existante, vous convertissez la table singleton en table Global Active. Les éléments suivants seront répliqués dans une table.

Note : Les marqueurs OCI vous permettent d'ajouter des métadonnées aux ressources. Un ou plusieurs marqueurs peuvent être associés à une table active globale. Les marqueurs OCI ne sont pas répliqués et une table active globale peut avoir des marqueurs différents dans différentes régions.

Ajout d'une réplique de table régionale

Lorsque vous répliquez une table, celle-ci est créée dans une autre région, appelée région destinataire. Si la table de la région expéditrice est un singleton, elle sera convertie en table active globale. Si la table de la région expéditrice est déjà une table active globale, une autre réplique régionale est ajoutée à la table. La réplique régionale est initialisée avec les données de la table de la région expéditrice. Par exemple, si votre table dans la région d'expéditeur comporte 1000 rangées, toutes les données sont copiées dans la réplique régionale nouvellement créée.

Note : Lorsque vous ajoutez une réplique de table régionale, la table de la région destinataire est placée dans le même compartiment avec le même nom de table que la table de la région expéditrice. Pendant la durée de vie de la table Global Active, vous pouvez la déplacer vers un autre compartiment à tout moment.

Capacité (unités de lecture, unités d'écriture et stockage) pour les répliques de table régionales

Lorsque vous ajoutez une réplique régionale d'une table, les champs Capacité de lecture, Capacité d'écriture et Capacité de stockage prennent automatiquement par défaut les valeurs correspondantes de la table dans la région expéditeur. Toutefois, vous pouvez modifier et modifier les valeurs de la capacité de lecture et de la capacité d'écriture de la table dans la région destinataire. Impossible de modifier la capacité de stockage de la table. La table de la région destinataire a la même capacité de stockage que la table de la région expéditrice. Le mode de capacité d'une table active globale peut être soit sur demande, soit provisionné. Vous pouvez également modifier le mode de capacité d'une réplique régionale pour une table active globale après sa création. La modification du mode de capacité est locale à cette réplique régionale et n'affecte aucune autre réplique régionale de la table Global Active.

Durée de vie des enregistrements dans les répliques de table régionale

Durée de vie de la table (TTL) est exprimée en tant que durée (nombre d'heures ou de jours) pendant laquelle les données sont autorisées à vivre dans la table. Oracle NoSQL Database Cloud Service permet aux développeurs de définir un délai d'expiration pour les rangées de table, après quoi les rangées expirent automatiquement et ne sont plus disponibles. Après la durée spécifiée, les lignes expirent automatiquement et ne sont plus disponibles. La durée de vie dans la réplique de table régionale est la même valeur que celle de la table dans la région de l'expéditeur. Lorsqu'une ligne est répliquée vers d'autres régions, son délai d'expiration est répliqué en tant qu'horodatage absolu. Par conséquent, cette ligne expirera en même temps, quel que soit le moment où elle a été répliquée.

Une fois qu'une réplique de table régionale est créée, elle est initialisée avec les données de la table de la région expéditrice. Lors de cette initialisation des données de table, si la valeur de durée de vie est atteinte, ces lignes expireront et une opération de lecture ne verra pas ces enregistrements.

Portée des opérations LDD après la création des répliques de table régionale :

Les opérations LDD suivantes ont une portée globale, ce qui signifie qu'une modification d'une réplique de table régionale est automatiquement propagée vers toutes les répliques de table régionale.

Les opérations LDD suivantes ont une portée locale, ce qui signifie qu'elles ne sont modifiées que dans la réplique de table régionale où elles sont lancées.

Considérations relatives à la modélisation des données pour les tables actives globales

Pourquoi devez-vous geler le schéma d'une table?

Dans une configuration de table active globale, des tables dans NDCS sont déployées dans plusieurs régions, et toutes les régions servent simultanément des demandes de lecture et d'écriture. L'application se connectant à NDCS doit être conçue pour se connecter à la région de réplication la plus proche. La clé primaire, la clé de partition et les données de la table doivent être identiques dans toutes les régions de réplication, car ces trois éléments font partie intégrante de l'utilisation de la table par l'application et de l'exécution des interrogations. Dans une table Global Active, comme les enregistrements de table peuvent être écrits simultanément dans la table dans plusieurs régions, il devient nécessaire de parvenir à un consensus sur le schéma de la table. Vous pouvez le faire en empêchant la modification du schéma, forçant toutes les régions à un consensus immédiat sur le schéma d'une table. Pour des raisons de simplicité, de performance et de prévisibilité, Oracle NoSQL Cloud Service nécessite qu'un schéma soit gelé pour toute table participant à la réplication régionale. Ainsi, avant de convertir une table singleton en table active globale, le schéma de table doit être gelé et aucune autre modification de schéma n'est autorisée. Si vous devez modifier le schéma d'une table active globale après avoir créé des répliques régionales, vous devez d'abord supprimer toutes les répliques régionales, modifier le schéma de la table, puis ajouter de nouveau les répliques régionales. Le service Oracle NoSQL Cloud alimentera de nouveau toutes les répliques régionales avec les données les plus récentes de la région de l'expéditeur. Pour cette raison, il est recommandé d'avoir au moins une colonne JSON dans la table car elle offre plus de flexibilité dans le schéma et évite d'avoir à modifier le schéma.

Définition d'une identité dans une table active globale

Politiques et autorisations d'utilisateur

Les politiques IAM d'une table sont propres à la région de l'expéditeur.

Lorsqu'un utilisateur ajoute une réplique d'une table singleton ou d'une table Global Active, aucune politique ou autorisation utilisateur n'est ajoutée dans la région destinataire. L'utilisateur de la région source qui souhaite créer et gérer des répliques doit également disposer des privilèges nécessaires dans la région destinataire. Sinon, vous obtenez une erreur lorsque l'utilisateur ajoute une réplique de table régionale.

Une fois les répliques de table régionale créées, la réplication de toute modification de données d'une région expéditrice vers la région destinataire ne nécessite aucune autorisation d'utilisateur. Cela signifie que la modification des données dans une table de réplica sera répliquée dans toutes les autres répliques de table, quelle que soit l'autorisation de l'utilisateur. Les autorisations nécessaires pour créer et gérer les répliques de table régionale sont indiquées ci-dessous.

Ajouter une réplique :

Les utilisateurs qui veulent gérer les répliques d'une table doivent disposer de l'autorisation NOSQL_TABLE_ALTER dans la région de l'expéditeur et dans toutes les régions de réception existantes. Les utilisateurs qui veulent créer une nouvelle réplique doivent disposer de l'autorisation NOSQL_TABLE_CREATE dans la région destinataire (où une réplique doit être créée). Lorsque vous créez une réplique de table régionale, l'autorisation de lecture et d'écriture existante de la table dans la région de l'expéditeur n'est pas créée dans la région du destinataire. Les utilisateurs qui veulent créer une nouvelle réplique dans la région destinataire sont responsables de la création des autorisations de lecture et d'écriture de table pour chaque réplique de table régionale qu'ils créent.

Déposer la réplique :

Les utilisateurs qui veulent gérer les répliques d'une table doivent disposer de l'autorisation NOSQL_TABLE_ALTER dans la région de l'expéditeur et dans toutes les régions de réception existantes. Les utilisateurs qui souhaitent supprimer une réplique doivent disposer de l'autorisation NOSQL_TABLE_DROP dans la région destinataire (où une réplique doit être supprimée).

Créer un index :

Les utilisateurs qui souhaitent créer des index dans des répliques de table régionale doivent disposer de l'autorisation NOSQL_INDEX_CREATE.

Supprimer l'index :

Les utilisateurs qui souhaitent supprimer des index dans des répliques de table régionale doivent disposer de l'autorisation NOSQL_INDEX_DROP.

Mettre à jour les limites de table/TTL/ :

Les utilisateurs qui veulent gérer les répliques d'une table doivent disposer de l'autorisation NOSQL_TABLE_ALTER dans toutes les répliques de table régionale.

Lectures, écritures et transactions ACID

Après avoir créé une table Global Active, vous pouvez effectuer des opérations de lecture ou d'écriture sur la table à l'aide des API d'accès aux données ou des instructions LMD existantes.

Pour une latence optimale, votre application est généralement lue à partir d'une réplique régionale locale. Les données de la réplique régionale locale incluront également les mises à jour des données répliquées à partir d'autres répliques de table régionale. Chaque fois que vous exécutez une opération d'écriture (INSERT, UPDATE ou DELETE) sur une table active globale, les modifications sont répliquées de manière asynchrone dans plusieurs régions. Autrement dit, lorsque vous écrivez une rangée dans la région de l'expéditeur, l'opération d'écriture est entièrement exécutée dans la région de l'expéditeur sans attendre que les régions de réplique soient mises à jour. Si plusieurs régions mettent à jour un enregistrement avec la même clé primaire, une règle est appliquée pour décider quelle région la mise à jour est considérée comme finale. Dans tous ces cas, cette règle de résolution de conflit intégrée entraînera le gain et la validation de la mise à jour avec l'horodatage le plus récent dans la base de données. Cette règle s'applique également lors de la mise à jour simultanée de la valeur de durée de vie à partir de plusieurs régions.

Les transactions ACID sont locales à une région. Lorsqu'une transaction est validée, elle n'est garantie que comme atomique, cohérente, isolée et durable, dans la région où l'écriture a eu lieu. La sémantique du modèle de cohérence d'une réplique de table régionale est la même que celle d'une table non répliquée. La cohérence des répliques de table régionale n'est pas absolue. La cohérence absolue est locale à une seule région où vous effectuez l'opération de lecture. Les lectures des données répliquées de la région de l'expéditeur vers les régions du destinataire sont toujours cohérentes en fin de compte.

Les écritures d'une région d'expéditeur sont répliquées dans toutes les régions de réception dans un délai. Ce délai pour répliquer les modifications dans plusieurs régions comprend le temps nécessaire pour recevoir les données de la réplique de table régionale dans la région expéditrice et le temps nécessaire pour terminer les opérations d'écriture dans la région destinataire. Finalement, la région du destinataire reçoit la mise à jour de la région de l'expéditeur et la région du destinataire ne manque jamais une mise à jour de transaction qui s'est produite dans la région de l'expéditeur. Toutes les répliques de table régionales finiront par recevoir l'écriture et deviendront durables.

Aperçu du décalage de réplique

Chaque fois que vous exécutez une opération d'écriture (INSERT, UPDATE ou DELETE) sur une table active globale, les modifications sont répliquées de manière asynchrone dans plusieurs régions.

Autrement dit, lorsque vous écrivez une rangée dans la région de l'expéditeur, l'opération d'écriture est entièrement exécutée dans la région de l'expéditeur sans attendre que les régions de réplique soient mises à jour. La latence du réseau crée un décalage dans la réplication des modifications apportées aux régions de réception. La latence pour la réplication des modifications dans plusieurs régions inclut le temps nécessaire pour recevoir des écritures à partir de la réplique et les appliquer dans la région destinataire. S'il n'y a pas eu d'écritures d'application pour la table dans la région expéditrice, le service utilise les mécanismes ping pour calculer une approximation du décalage, et la statistique de décalage sera toujours disponible dans la région destinataire.

Pour plus de détails sur la mesure de décalage de réplique, voir Informations détaillées sur le décalage de réplique.

Aperçu de la création d'une table active globale

Le processus de création d'une table Global Active commence par la création d'une table singleton, puis par sa conversion en table Global Active.

Les étapes de création d'une table active globale sont indiquées ci-dessous.