Mode Écrire dans n'importe quelle région (non primaire)

Le mode d'écriture dans n'importe quelle région, illustré dans le schéma suivant, est entièrement actif-actif et n'impose aucune restriction quant à l'endroit où une opération d'écriture peut avoir lieu. N'importe quelle région peut accepter une demande écrite à tout moment. Il s'agit du mode le plus simple, mais il ne peut être utilisé qu'avec certains types d'applications. Ce mode convient à toutes les tables MRSC. Il convient également aux tables MREC lorsque toutes les opérations d'écriture sont idempotentes. Idempotent signifie qu'ils sont reproductibles en toute sécurité afin que les opérations d'écriture simultanées ou répétées entre les régions ne soient pas en conflit, par exemple lorsqu'un utilisateur met à jour ses coordonnées. Cela fonctionne également bien pour un ensemble de données avec ajout uniquement où toutes les opérations d'écriture sont des insertions uniques sous une clé primaire déterministe, ce qui constitue un cas particulier d'idempotent. Enfin, ce mode convient aux MREC où le risque de conflits d'opérations d'écriture est acceptable.

Le mode Écrire dans n'importe quelle région est l'architecture la plus simple à implémenter. Le routage est plus facile car n'importe quelle région peut être la cible d'écriture à tout moment. Le basculement est plus facile, car avec les tables MRSC, les éléments sont toujours synchronisés, et avec les tables MREC, toutes les opérations d'écriture récentes peuvent être rejouées autant de fois que nécessaire dans n'importe quelle région secondaire. Dans la mesure du possible, votre conception doit suivre ce mode d'écriture.

Par exemple, plusieurs services de streaming vidéo utilisent des tableaux globaux pour suivre les signets, les critiques, les indicateurs de statut des visionnages, etc. Ces déploiements utilisent des tables MREC car ils nécessitent des répliques dispersées dans le monde entier, chaque réplique fournissant des opérations de lecture et d'écriture à faible latence. Ces déploiements peuvent utiliser l'écriture dans n'importe quel mode Region tant qu'ils garantissent que chaque opération d'écriture est idempotente. Ce sera le cas si chaque mise à jour, par exemple la définition d'un nouveau code temporel, l'attribution d'un nouvel avis ou la définition d'un nouveau statut de montre, attribue directement le nouvel état à l'utilisateur, et que la prochaine valeur correcte pour un article ne dépend pas de sa valeur actuelle. Si, par hasard, les demandes d'écriture de l'utilisateur sont acheminées vers différentes régions, la dernière opération d'écriture persistera et l'état global se stabilisera en fonction de la dernière affectation. Les opérations de lecture dans ce mode finiront par devenir cohérentes, retardées par la dernière ReplicationLatency valeur.

Autre exemple : une entreprise de services financiers utilise des tables globales dans le cadre d'un système visant à tenir à jour le décompte des achats par carte de débit pour chaque client, afin de calculer les remises en argent de ce client. Ils veulent conserver un RunningBalance article par client. Ce mode d'écriture n'est pas naturellement idempotent car au fur et à mesure que les transactions entrent, elles modifient l'équilibre en utilisant une ADD expression dans laquelle la nouvelle valeur correcte dépend de la valeur actuelle. En utilisant les tables MRSC, ils peuvent toujours écrire dans n'importe quelle région, car chaque ADD appel fonctionne toujours en fonction de la toute dernière valeur de l'article.

Un troisième exemple concerne une entreprise qui fournit des services de placement d'annonces en ligne. Cette société a décidé qu'un faible risque de perte de données serait acceptable pour simplifier la conception de l'écriture dans n'importe quel mode régional. Lorsqu'ils diffusent des annonces, ils ne disposent que de quelques millisecondes pour récupérer suffisamment de métadonnées afin de déterminer l'annonce à diffuser, puis pour enregistrer l'impression de la publicité afin de ne pas répéter la même annonce rapidement. Ils utilisent des tables globales pour obtenir à la fois des opérations de lecture à faible latence pour les utilisateurs finaux du monde entier et des opérations d'écriture à faible latence. Ils enregistrent toutes les impressions publicitaires d'un utilisateur dans un seul élément, représenté sous la forme d'une liste croissante. Ils utilisent un élément au lieu de l'ajouter à une collection d'articles, ce qui leur permet de supprimer les anciennes impressions publicitaires lors de chaque opération de rédaction sans avoir à payer pour une opération de suppression. Cette opération d'écriture n'est pas idempotente ; si le même utilisateur final voit des publicités diffusées depuis plusieurs régions à peu près au même moment, il est possible qu'une opération d'écriture pour une impression publicitaire en remplace une autre. Le risque est qu'un utilisateur voie une publicité se répéter de temps en temps. Ils ont décidé que c'était acceptable.