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 sur 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 minimum nécessaire à un paquet de données pour parcourir le réseau. Les utilisateurs s'attendent à terminer leurs activités en ligne en douceur et rapidement de n'importe où. Pour répondre à ces attentes, les entreprises doivent héberger des applications et des données dans les régions distribuées les plus proches de leurs utilisateurs.
Oracle NoSQL Database Cloud Service offre une solution à ces exigences au moyen de tables globales actives. Cette fonction permet la réplication transparente des données d'application écrites dans une région entre plusieurs régions.
- Lire et écrire localement et accéder aux données globalement : Une configuration active-active des tables actives globales dans plusieurs régions garantit qu'une mise à jour effectuée sur une table d'une région est automatiquement répliquée vers les répliques de la table dans d'autres régions de réplication. Les données sont accessibles à partir de n'importe quelle région répliquée.
- Performance : Les tables actives globales vous permettent de lire et d'écrire vos données localement, offrant une latence à une milliseconde près, ce qui est caractéristique de l'accès local pour votre application répartie globalement à toutes les échelles. Cela peut améliorer les performances des applications globales à grande échelle et réduire la latence des demandes d'application.
- Configuration et gestion faciles : Oracle NoSQL Database Cloud Service élimine la complexité du déploiement et de la gestion de la réplication multi-région à l'aide de tables Global Active. L'ajout de répliques de table régionale est simple et peut être effectué à l'aide des API, de Terraform ou de la console OCI.
- Résilience multi-région : Les tables globales actives activent également la tolérance aux pannes dans les rares cas de défaillance d'une région. Si une seule région devient indisponible ou hors ligne, les demandes d'application peuvent être redirigées vers une région où la table est répliquée, et les lectures et les écritures peuvent être effectuées sur cette table.
Comment choisir une configuration active globale dans NDCS?
La fonction Tables actives globales permet la réplication transparente des 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 devrait 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 assurer la récupération après sinistre même en cas de défaillance d'une région. Vous pouvez utiliser une table Global Active dans Oracle NoSQL Database Cloud Service (NDCS) pour fournir une récupération 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 à l'aide de 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 d'achat 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, où qu'il se trouve.
La fonction de table Global Active dans 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 la 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). Vous disposez d'une table nommée ShoppingCart qui stocke les informations d'achat des clients qui magasinent dans différentes régions du monde. Dans cet exemple, votre entreprise dessert 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 comportant deux régions réparties géographiquement ou plus et le service NoSQL Database Cloud disponibles dans chacune de ces régions est appelée architecture de table active globale. La table ShoppingCart est une table globale active 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. En cas d'échec d'une région, les tables actives globales des autres régions de réplique continueront de fonctionner comme d'habitude et ne seront 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 la récupération après sinistre en ce sens que lorsqu'une région est arrêtée, votre application est connectée à une autre réplique.
Dans le second scénario, supposons que l'utilisateur de Phoenix, achète 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 minimale de demande de lecture et d'écriture à 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 la société mobile et trouve qu'il y a 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 un magasin mobile local 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 le magasin mobile. Comme le service NoSQL Database Cloud est disponible dans trois régions, l'une à Phoenix, l'autre en Allemagne et l'autre au Japon, et qu'il existe plus d'une réplique de table régionale, chaque fois que l'utilisateur met à jour le panier ou consulte le magasin de commerce électronique mobile, les résultats de recherche personnalisés et les autres données extraites 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égion : Région d'Oracle Cloud Infrastructure (OCI). Il s'agit d'une zone géographique unique où les clients peuvent déployer leurs applications.
- Région d'expéditeur : Région à partir de laquelle une mise à jour de table est répliquée vers d'autres régions.
- Région du destinataire : Région qui reçoit la mise à jour de la table d'une autre région.
- Table type : Table qui n'est pas répliquée régionalement.
- Réplique de table régionale : Réplique d'une table créée dans une autre région.
- Table active globale : Table contenant une ou plusieurs répliques de table régionale.
Règles de base pour la création et la gestion des tables Global Active :
- La table singleton doit comporter au moins une colonne JSON.
- L'état du schéma de la table doit être FROZEN.
- Dans la région du destinataire, il ne doit pas exister de table portant le même nom.
- Dans la région du destinataire, le compartiment (avec le même nom que celui de la région de l'expéditeur) doit déjà exister.
- Avant de supprimer une table, toutes les répliques régionales de la table doivent être supprimées.
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 sur 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 Global Active, vous devez geler le schéma de la table enfant et ajouter une réplique régionale. Vous pouvez choisir l'une des répliques régionales de la table parent.
Flux de travail de la table active globale
Qu'est-ce qui est répliqué dans une table Global Active?
- Définition/schéma de table
- Index dans la table - Nombre et définitions d'index secondaires.
- Données dans la table.
- Capacité de lecture et d'écriture - Par défaut, la limite de lecture d'une réplique régionale est la même que celle des autres répliques régionales de la table active globale. Toutefois, les opérations de lecture sont purement locales. Vous pouvez éventuellement définir les limites de lecture propres à chaque région. Par défaut, la limite d'écriture d'une réplique régionale est identique à celle des autres répliques régionales de la table Global Active. Toutefois, les limites d'écriture peuvent être définies avec des valeurs différentes dans chaque région.
- Capacité de stockage - Comme toutes les répliques régionales de la table Global Active stockent les mêmes données de table, la limite de stockage d'une réplique régionale est copiée dans toutes les autres répliques régionales de la table Global Active.
- Durée de vie de la table par défaut (TTL)
Ajout d'une réplique de table régionale
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 d'expéditeur. Pendant toute 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 d'expéditeur. Toutefois, vous pouvez modifier et modifier les valeurs de la capacité de lecture et d'écriture de la table dans la région du récepteur. La capacité de stockage de la table ne peut pas être modifiée. La table de la région du récepteur a la même capacité de stockage que la table de la région de l'expéditeur. Le mode de capacité d'une table Global Active peut être sur demande ou provisionné. Vous pouvez également modifier le mode de capacité de n'importe quelle réplique régionale pour une table Global Active 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égionales
Durée de vie de la table (TTL) est exprimée en tant que période (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 rangées expirent automatiquement et ne sont plus disponibles. La durée de vie de la réplique de table régionale est la même 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 de l'expéditeur. Lors de cette initialisation des données de table, si la valeur de durée de vie est atteinte, ces rangées 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égionales :
- Ajouter un index
- Abandonner l'index
- Modification de la capacité de stockage de la table
- Modification de la durée de vie de la table
- Modification des unités de lecture
- Modification des unités d'écriture
- Modification du mode de capacité de Sur demande à provisionné ou inversement
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 Global Active, vous avez des tables dans NDCS déployées sur plusieurs régions, et toutes les régions traitent 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 sont intrinsèques à la façon dont l'application utilise la table et à 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 d'atteindre un consensus sur le schéma de la table. Pour ce faire, vous pouvez empêcher la modification du schéma, ce qui force toutes les régions à obtenir un consensus immédiat sur le schéma d'une table. Pour plus de simplicité, de performance et de prévisibilité, Oracle NoSQL Cloud Service exige qu'un schéma soit gelé pour toute table participant à la réplication régionale. Ainsi, avant de convertir une table singleton en table Global Active, 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 Global Active 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 réalimentera toutes les répliques régionales avec les données les plus récentes de la région d'expéditeur.
Pourquoi au moins une colonne JSON est-elle requise dans une table lors du gel de son schéma?
La coordination d'une modification de schéma dans les répliques de table régionales est difficile et entraîne des cas d'erreur potentiels. Le fait de fournir une colonne JSON offre plus de flexibilité dans le schéma et empêche la nécessité d'une modification du schéma.
Définition de l'identité dans une table globale active
-
L'identité d'un enregistrement dans une réplique de table régionale doit être unique pour toutes les répliques régionales de la table. Les clés naturelles (identificateurs globaux uniques qui identifient chaque enregistrement d'une table) ne peuvent être utilisées comme identité dans les tables actives globales que si elles peuvent garantir l'unicité de toutes les répliques de table régionales.
- Lors de l'utilisation d'une identité générée par le système dans une table Global Active, vous devez utiliser l'UUID. Dans la plupart des cas, la colonne d'identité ne doit pas être utilisée car elle n'est pas garantie d'être unique dans les répliques de table régionales.
Politiques et autorisations d'utilisateur
Les politiques IAM d'une table sont propres à la région d'expéditeur.
Lorsqu'un utilisateur ajoute une réplique d'une table singleton ou d'une table Global Active, aucune politique ou autorisation d'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égionales créées, la réplication de toute modification de données d'une région d'expéditeur 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épliques 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égionales sont répertorié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 du destinataire existantes. Les utilisateurs qui souhaitent 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 souhaitent 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.
Supprimer la réplique :
Les utilisateurs qui souhaitent gérer les répliques d'une table doivent disposer de l'autorisation NOSQL_TABLE_ALTER dans la région d'expéditeur et dans toutes les régions destinataires 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égionales 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égionales 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égionales.
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 de données répliquées à partir d'autres répliques de table régionales. Chaque fois que vous exécutez une opération d'écriture (INSERT, UPDATE ou DELETE) sur une table Global Active, les modifications sont répliquées sur plusieurs régions de manière asynchrone. Autrement dit, lorsque vous écrivez une ligne dans la région de l'expéditeur, l'opération d'écriture est exécutée complètement dans la région de l'expéditeur sans attendre la mise à jour des régions de réplique. Si plusieurs régions mettent à jour une rangée avec la même clé primaire, une règle est appliquée pour décider quelle mise à jour de région est considérée comme finale. Dans tous ces cas, cette règle intégrée de résolution des conflits 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 de plusieurs régions.
Les transactions ACID sont locales à une région. Lorsqu'une transaction est validée, elle n'est garantie que 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égionales n'est pas absolue. La cohérence absolue est locale à une seule région où vous effectuez l'opération de lecture. Les lectures sur les 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 du destinataire dans un délai. Ce décalage 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 d'expéditeur et le temps nécessaire pour terminer les opérations d'écriture dans la région destinataire. Finalement, la région destinataire reçoit la mise à jour de la région expéditeur et la région destinataire ne manque jamais une mise à jour de transaction qui s'est produite dans la région expéditeur. Toutes les répliques de table régionales recevront éventuellement l'écriture et deviendront durables.
Aperçu du décalage de la réplique
Chaque fois que vous exécutez une opération d'écriture (INSERT, UPDATE ou DELETE) sur une table Global Active, les modifications sont répliquées sur plusieurs régions de manière asynchrone.
Autrement dit, lorsque vous écrivez une ligne dans la région de l'expéditeur, l'opération d'écriture est exécutée complètement dans la région de l'expéditeur sans attendre la mise à jour des régions de réplique. La latence réseau crée un décalage temporel dans la réplication des modifications dans les régions de réception. La latence de réplication des modifications sur plusieurs régions inclut le temps nécessaire pour recevoir les écritures de la réplique et les appliquer dans la région du récepteur. S'il n'y a pas eu d'écritures d'application pour la table dans la région de l'expéditeur, 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 du destinataire.
Pour plus de détails sur la mesure Décalage de réplique, voir Détails sur le décalage de réplique.
Aperçu de la création d'une table Global Active
Le processus de création d'une table Global Active commence par la création d'une table singleton, puis sa conversion en table Global Active.
- Créez une table singleton et assurez-vous qu'une colonne est JSON.
- Modifiez l'état du schéma de la table de Mutable à Gelé.
- Déterminez la région dans laquelle vous souhaitez ajouter une réplique régionale de la table. Lors de l'ajout d'une réplique régionale, les champs de capacité de lecture, de capacité d'écriture et de capacité de stockage sont automatiquement alimentés avec les valeurs correspondantes de la région de l'expéditeur. Vous pouvez modifier la capacité de lecture et d'écriture de la table.
- Le service en nuage crée la table dans la région du destinataire. Si la table de la région source contient des données, elle commence à copier les données de la région de l'expéditeur vers la région du destinataire. Lorsque les données sont copiées de la région de l'expéditeur vers la région du destinataire, le pourcentage d'initialisation passe de 0 à 100. Vous pouvez voir la valeur du pourcentage d'initialisation sous les informations de la table dans la console OCI, comme illustré ci-dessous. Aucune opération LMD n'est autorisée dans la nouvelle réplique de table régionale tant que le processus d'initialisation n'est pas terminé.
