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 maintenir des 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 du réseau est un paramètre crucial pour évaluer les performances de toute application. La latence réseau est la durée minimale de déplacement d'un paquet de données sur le réseau. Les utilisateurs s'attendent à effectuer 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 permet de répondre à ces exigences via des tables Global Active. Cette fonctionnalité permet de répliquer les données d'application écrites dans une région de manière transparente dans plusieurs régions.
- Lecture et écriture locales, et accès global à vos données : une configuration active-active de tables actives globales dans plusieurs régions garantit qu'une mise à jour effectuée sur une table dans 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.
- Performances : les tables actives globales vous permettent de lire et d'écrire vos données localement, ce qui fournit une latence à un chiffre en millisecondes, caractéristique de l'accès local pour votre application distribuée globalement à n'importe quelle échelle. 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 d'API, de Terraform ou de la console OCI.
- Résilience multi-région : les tables actives globales 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 écritures peuvent être effectuées sur cette table.
Comment choisir une configuration active globale dans NDCS ?
La fonctionnalité de tables actives globales permet la réplication transparente des données d'application écrites dans une région entre plusieurs régions.
Un événement rare de panne d'une seule région ne devrait pas avoir d'impact 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 active globale dans Oracle NoSQL Database Cloud Service (NDCS) pour assurer la récupération après sinistre via 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 local aux données.
Considérez les besoins d'un utilisateur voyageur qui fait des achats à 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 les utilisateurs connaissent une latence minimale et une interaction transparente, où qu'ils se trouvent.
La fonction de table Actif global dans NDCS fournit une solution aux deux scénarios décrits ci-dessus. Explorons chacun des deux scénarios et comprenons comment une table active globale sera la meilleure solution pour fournir une haute disponibilité, une faible latence et une récupération après sinistre.
Dans le premier scénario, supposons que votre société utilise NDCS à Phoenix (US - West), Francfort (Allemagne) et Tokyo (Japon) et que vous disposez d'une table appelée ShoppingCart qui stocke les informations d'achat des clients qui effectuent des achats dans différentes régions du monde. Dans cet exemple, votre société fournit des services à ses clients via des centres de données les plus proches géographiquement d'eux. Une telle configuration implique plusieurs emplacements géographiques où Oracle NoSQL Database Cloud Service est disponible. Une architecture comportant au moins deux régions réparties géographiquement et un 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 active globale et 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 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 en ce sens que lorsqu'une région est arrêtée, votre application est connectée à une autre réplique.
Dans le deuxième scénario, supposons que l'utilisateur à 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 la latence minimale des demandes de lecture et d'écriture de la banque de données locale de la région est affectée à l'utilisateur. Cet utilisateur monte ensuite dans un 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 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 de 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 proche, sert 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 la boutique mobile. NoSQL Database Cloud Service étant disponible dans trois régions, l'une à Phoenix, l'autre en Allemagne et l'autre au Japon, il existe plusieurs répliques de tables régionales, chaque fois que l'utilisateur met à jour le panier ou navigue sur le magasin de commerce électronique mobile, les résultats de recherche personnalisés et d'autres données sont 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 élémentaires
Terminologie utilisée dans les tables Global Active :
- Région : région Oracle Cloud Infrastructure (OCI). Il s'agit d'une zone géographique unique dans laquelle les clients peuvent déployer leurs applications.
- Région 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 table d'une autre région.
- Table unique : table non répliquée au niveau régional.
- Réplique de table régionale : réplique d'une table créée dans une autre région.
- Table active globale : table contenant des 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 contenir au moins une colonne JSON.
- L'état de schéma de la table doit être FROZEN.
- Dans la région récepteur, une table portant le même nom ne doit pas déjà exister.
- Dans la région du destinataire, le compartiment (du 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 de table régionale de la table doivent être supprimées.
Remarques :
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 enfant sur une table active globale. Une table enfant d'une table active globale peut être une table unique ou une table active globale. 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 choisir l'une des répliques régionales de la table parent.
Workflow de table active globale
Qu'est-ce qui est répliqué dans une table active globale ?
- Définition/schéma de la table
- Index dans la table - Nombre et définitions des index secondaires.
- Données de la table.
- Capacité de lecture et capacité 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, de sorte que 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 la même que celle des autres répliques régionales de la table Global Active. Toutefois, les limites d'écriture peuvent être définies sur 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 vers toutes les autres répliques régionales de la table Global Active.
- Durée de vie de la table par défaut
Ajout d'une réplique de table régionale
Remarques :
Lorsque vous ajoutez une réplique de table régionale, la table de la région de 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 active globale, 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égionale
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 de l'expéditeur. Toutefois, vous pouvez modifier les valeurs de 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 active globale peut être à la demande ou provisionné. Vous pouvez également modifier le mode de capacité de n'importe quelle réplique régionale pour une table active globale après sa création. Le changement de mode de capacité est local à cette réplique régionale et n'affecte aucune autre réplique régionale de la table active globale.
Durée de vie des enregistrements dans les répliques de table régionale
La durée de vie de la table (TTL) est exprimée sous la forme d'une durée (nombre d'heures ou de jours) pendant laquelle les données peuvent résider dans la table. Oracle NoSQL Database Cloud Service permet aux développeurs de définir un délai d'expiration sur les lignes de la table, délai après lequel les lignes arrivent à expiration 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 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 heure d'expiration est répliquée 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 d'expéditeur. Au cours de cette initialisation des données de table, si la valeur de durée de vie est atteinte, ces lignes expirent et une opération de lecture ne voit pas ces enregistrements.
Portée des opérations DDL après la création de répliques de table régionale :
- Ajouter un index
- Supprimer l'index
- Modification de la capacité de stockage de la table
- Variation de la durée de vie de la table
- Variation des unités de lecture
- Modification des unités d'écriture
- Modification du mode de capacité de la demande à la provisionnée ou inversement
Considérations relatives à la modélisation de 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 NDCS sont déployées dans 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 shard et les données de la table doivent être identiques dans les régions de réplication car ces trois éléments sont une partie intrinsèque de la façon dont l'application utilise la table et comment les requêtes s'exécutent. Dans une table active globale, 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. 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 performances et de prévisibilité, Oracle NoSQL Cloud Service requiert le gel d'un schéma pour toute table participant à la réplication régionale. Par conséquent, avant de convertir une table singleton en table active globale, le schéma de la 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 rajouter les répliques régionales. Le service Oracle NoSQL Cloud remplit à nouveau toutes les répliques régionales avec les données les plus récentes de la région de l'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 des répliques de tables régionales est difficile et entraîne des cas d'erreur potentiels. La fourniture d'une colonne JSON offre plus de flexibilité dans le schéma et évite la nécessité d'une modification de schéma.
Définir l'identité dans une table active globale
-
L'identité d'un enregistrement dans une réplique de table régionale doit être unique dans toutes les répliques régionales de la table. Les clés naturelles (identificateurs uniques au niveau mondial 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égionale.
- Lors de l'utilisation de l'identité générée par le système dans une table active globale, UUID doit être utilisé. Dans la plupart des cas, la colonne d'identité ne doit pas être utilisée car elle n'est pas garantie comme unique entre les répliques de table régionale.
Stratégies et autorisations utilisateur
Les stratégies 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 active globale, aucune stratégie ni aucun droit d'accès utilisateur n'est ajouté dans la région du 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 du récepteur. 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 d'expéditeur vers la région de destinataire ne nécessite aucune autorisation 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 tables, quelle que soit l'autorisation de l'utilisateur. Les droits d'accès nécessaires à la création et à la gestion des répliques de table régionale sont répertoriés ci-dessous.
Ajouter une 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 de destinataire existantes. Les utilisateurs qui souhaitent créer une réplique doivent disposer de l'autorisation NOSQL_TABLE_CREATE dans la région du récepteur (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 d'expéditeur n'est pas créée dans la région de destinataire. Les utilisateurs qui souhaitent créer une réplique dans la région de destinataire sont chargés de créer les 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 du droit d'accès NOSQL_TABLE_ALTER dans la région d'expéditeur et dans toutes les régions de destinataire existantes. Les utilisateurs qui souhaitent supprimer une réplique doivent disposer du droit d'accès NOSQL_TABLE_DROP dans la région du récepteur (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 du droit d'accès NOSQL_INDEX_CREATE.
Supprimer l'index:
Les utilisateurs qui souhaitent supprimer des index dans des répliques de table régionale doivent disposer du droit d'accès NOSQL_INDEX_DROP.
Mettre à jour les limites de table/TTL/ :
Les utilisateurs qui souhaitent gérer les répliques d'une table doivent disposer du droit d'accès NOSQL_TABLE_ALTER dans toutes les répliques de table régionale.
Lectures, écritures et transactions ACID
Après avoir créé une table active globale, 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 lit généralement à partir d'une réplique régionale locale. Les données de la réplique régionale locale incluent également les mises à jour de 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. En d'autres termes, lorsque vous écrivez une ligne 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 la mise à jour des régions de réplique. Si plusieurs régions mettent à jour une ligne 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 de résolution de conflit intégrée entraînera la victoire 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 dans une région. Lorsqu'une transaction est validée, elle est uniquement garantie 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 identique à 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 dans 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 d'expéditeur vers les régions de destinataire sont toujours cohérentes à terme.
Les écritures d'une région d'expéditeur sont répliquées dans toutes les régions de destinataire dans un délai donné. Ce délai pour répliquer les modifications dans plusieurs régions inclut 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 effectuer les opérations d'écriture dans la région de 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égionale recevront l'écriture et deviendront durables.
Présentation 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 active globale, les modifications sont répliquées de manière asynchrone dans plusieurs régions.
En d'autres termes, lorsque vous écrivez une ligne 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 la mise à jour des régions de réplique. La latence du réseau crée un décalage dans la réplication des modifications vers les régions de récepteur. La latence pour la réplication des modifications dans 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 récepteur.
Pour plus de détails sur la mesure de décalage de réplique, reportez-vous à Détails sur le décalage de réplique.
Présentation de la création d'une table active globale
Le processus de création d'une table active globale commence par la création d'une table singleton, puis sa conversion en table active globale
- Créez une table singleton et assurez-vous qu'une colonne est JSON.
- Remplacez l'état du schéma de la table Mutable par Validé.
- Choisissez 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 remplis 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 cloud 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 émettrice vers la région récepteur. Au fur et à mesure que les données sont copiées de la région émettrice vers la région récepteur, le pourcentage d'initialisation passe de 0 à 100. Vous pouvez visualiser la valeur du pourcentage d'initialisation sous les informations de table dans la console OCI comme indiqué ci-dessous. Aucune opération DML n'est autorisée dans la nouvelle réplique de table régionale tant que le processus d'initialisation n'est pas terminé.
