Bigtable pour les utilisateurs de DynamoDB

Ce document est destiné aux développeurs et aux administrateurs de bases de données DynamoDB qui souhaitent migrer ou concevoir des applications à utiliser avec Bigtable en tant que datastore. Avant de lire ce document, consultez la présentation de Bigtable.

Bigtable et DynamoDB sont des magasins de paires clé-valeur distribués pouvant accepter des millions de requêtes par seconde (RPS), fournir un stockage pouvant atteindre des pétaoctets de données et tolérer les défaillances de nœuds.

Bien que les ensembles de fonctionnalités de ces services de base de données soient similaires, leurs architectures sous-jacentes et leurs détails d'interaction diffèrent d'une manière qu'il est important de comprendre avant de commencer une migration. Ce document met en évidence les similitudes et les différences entre les deux systèmes de base de données.

Plan de contrôle

Dans DynamoDB et Bigtable, le plan de contrôle vous permet de configurer votre capacité, ainsi que de configurer et de gérer les ressources. DynamoDB est un produit sans serveur, et le niveau d'interaction le plus élevé avec DynamoDB se situe au niveau de la table. En mode de capacité provisionnée, c'est là que vous provisionnez vos unités de requête de lecture et d'écriture, sélectionnez vos régions et votre réplication, et gérez les sauvegardes. Bigtable n'est pas un produit sans serveur. Vous devez créer une instance avec un ou plusieurs clusters, dont la capacité est déterminée par le nombre de nœuds dont ils disposent. Pour en savoir plus sur ces ressources, consultez la page Instances, clusters et nœuds.

Le tableau suivant compare les ressources de plan de contrôle pour DynamoDB et Bigtable.

DynamoDB Bigtable
Table : collection d'éléments avec une clé primaire définie. Les tables disposent de paramètres pour les sauvegardes, la réplication et la capacité. Instance:groupe de clusters Bigtable dans différentes zones ou régions Google Cloud, entre lesquelles la réplication et le routage des connexions ont lieu. Les règles de réplication sont définies au niveau de l'instance.

Cluster:groupe de nœuds dans la même zone géographique Google Cloud, idéalement colocalisés avec votre serveur d'applications pour des raisons de latence et de réplication. La capacité est gérée en ajustant le nombre de nœuds dans chaque cluster.

Table: organisation logique des valeurs indexées par clé de ligne.

Les sauvegardes sont contrôlées au niveau de la table.
Unité de capacité de lecture (RCU) et unité de capacité d'écriture (WCU) : unités autorisant les lectures ou les écritures par seconde avec une taille de charge utile fixe. Des unités de lecture ou d'écriture vous sont facturées pour chaque opération dont la charge utile est plus importante.

Les opérations UpdateItem consomment la capacité d'écriture utilisée pour la taille maximale d'un élément mis à jour (avant ou après la mise à jour), même si celle-ci implique un sous-ensemble des attributs de l'élément.		 Nœud:ressource de calcul virtuelle chargée de lire et d'écrire des données. Le nombre de nœuds d'un cluster se traduit par des limites de débit pour les lectures, les écritures et les analyses. Vous pouvez ajuster le nombre de nœuds en fonction de la combinaison de vos objectifs de latence, du nombre de requêtes et de la taille de la charge utile.

Les nœuds SSD offrent le même débit en lecture et en écriture, contrairement à la différence significative entre les RCU et les WCU. Pour en savoir plus, consultez la section Performances pour des charges de travail types.
Partition : bloc de lignes contiguës reposant sur des disques durs SSD colocalisés avec des nœuds.

Chaque partition est soumise à une limite stricte de 1 000 WCU, 3 000 RCU et 10 Go de données.		 Tablette : bloc de lignes contiguës sauvegardées par le support de stockage de votre choix (SSD ou HDD).

Les tables sont segmentées en tablets afin d'équilibrer la charge de travail. Les tablets ne sont pas stockés sur des nœuds dans Bigtable, mais sur le système de fichiers distribué de Google, qui permet une redistribution rapide des données lors du scaling, et offre une durabilité supplémentaire en conservant plusieurs copies.
Tables globales : moyen d'augmenter la disponibilité et la durabilité de vos données en propageant automatiquement les modifications de données dans plusieurs régions. Réplication : moyen d'augmenter la disponibilité et la durabilité de vos données en propageant automatiquement les modifications de données dans plusieurs régions ou plusieurs zones d'une même région.
Non applicable (N/A) Profil d'application : paramètres indiquant à Bigtable comment acheminer un appel d'API cliente vers le cluster approprié dans l'instance. Vous pouvez également utiliser un profil d'application comme tag pour segmenter les métriques à des fins d'attribution.

Réplication géographique

La réplication permet de répondre aux exigences des clients dans les cas suivants:

  • la haute disponibilité pour la continuité des activités en cas de défaillance d'une zone ou d'une région ;
  • Placer vos données de service à proximité des utilisateurs finaux pour une diffusion à faible latence, où qu'ils se trouvent dans le monde.
  • Isolation de la charge de travail lorsque vous devez implémenter une charge de travail par lot sur un cluster et vous appuyer sur la réplication sur les clusters de diffusion.

Bigtable accepte les clusters répliqués dans autant de zones que de zones Google Cloud dans lesquelles Bigtable est disponible. La plupart des régions comportent trois zones. Bigtable réplique automatiquement les données sur plusieurs clusters selon une topologie multiprincipale, ce qui signifie que vous pouvez lire et écrire sur n'importe quel cluster. La réplication Bigtable est cohérente à terme. Pour en savoir plus, consultez la page Présentation de la réplication.

DynamoDB fournit des tables globales pour permettre la réplication des tables dans plusieurs régions. Les tables globales sont multi-principales et se répliquent automatiquement entre les régions. La réplication est cohérente à terme.

Le tableau suivant répertorie les concepts de réplication et décrit leur disponibilité dans DynamoDB et Bigtable.

Propriété DynamoDB Bigtable
Réplication multiprincipale Oui.

Vous pouvez lire et écrire dans n'importe quelle table globale.		 Oui.

Vous pouvez lire et écrire sur n'importe quel cluster Bigtable.
Modèle de cohérence Cohérence à terme.

Cohérence de type "lecture de vos écritures" au niveau régional pour les tables globales.		 Cohérence à terme.

Cohérence lecture-écriture au niveau du cluster pour toutes les tables, à condition d'envoyer à la fois les lectures et les écritures sur le même cluster.
Latence de réplication Aucun contrat de niveau de service (SLA).

Secondes		 Aucun contrat de niveau de service.

Secondes
Précision de la configuration Au niveau de la table. Au niveau de l'instance.

Une instance peut contenir plusieurs tables.
Implémentation Créez une table globale avec une instance dupliquée de table dans chaque région sélectionnée.

Niveau régional.

Réplication automatique sur les instances répliquées en convertissant une table en table globale.

DynamoDB Streams doit être activé sur les tables, et le flux doit contenir à la fois les nouvelles et les anciennes images de l'élément.

Supprimez une région pour supprimer la table globale qu'elle contient.		 Créez une instance avec plusieurs clusters.
La réplication est automatique sur tous les clusters de cette instance.

Niveau zonal.

Ajoutez et supprimez des clusters d'une instance Bigtable.
Options de réplication Par table Par instance.
Disponibilité et routage du trafic Trafic acheminé vers l'instance répliquée géographique la plus proche.

En cas d'échec, vous appliquez une logique métier personnalisée pour déterminer quand rediriger les requêtes vers d'autres régions.		 Utilisez des profils d'application pour configurer des règles de routage du trafic de cluster.

Utilisez le routage multicluster pour acheminer automatiquement le trafic vers le cluster opérationnel le plus proche.

En cas d'échec, Bigtable permet le basculement automatique entre les clusters pour la haute disponibilité.
Scaling La capacité d'écriture dans les unités de requête d'écriture répliquées (R-WRU) est synchronisée entre les instances répliquées.

La capacité de lecture en unités de capacité de lecture répliquées (R-RCU) est calculée par instance répliquée.		 Vous pouvez effectuer le scaling des clusters indépendamment en ajoutant ou en supprimant des nœuds de chaque cluster répliqué selon vos besoins.
Coût Les R-WRU coûtent 50% de plus que les WRU standards. Les nœuds et le stockage de chaque cluster vous sont facturés.
Il n'y a aucun coût de réplication réseau pour la réplication régionale dans plusieurs zones.
Des coûts sont facturés lorsque la réplication s'effectue dans plusieurs régions ou continents.
Contrat de niveau de service 99,999 % 99,999 %

Plan de données

Le tableau suivant compare les concepts de modèles de données pour DynamoDB et Bigtable. Chaque ligne du tableau décrit des caractéristiques analogues. Par exemple, un élément dans DynamoDB est semblable à une ligne dans Bigtable.

DynamoDB Bigtable
Élément : groupe d'attributs identifiables de manière unique parmi tous les autres éléments par sa clé primaire. La taille maximale autorisée est de 400 Ko. Ligne : une seule entité identifiée par la clé de ligne. La taille maximale autorisée est de 256 Mo.
Non disponible Famille de colonnes:espace de noms spécifié par l'utilisateur qui regroupe des colonnes.
Attribut : regroupement d'un nom et d'une valeur. Une valeur d'attribut peut être une valeur scalaire, un ensemble ou un type de document. Il n'existe aucune limite explicite concernant la taille des attributs lui-même. Toutefois, étant donné que chaque élément est limité à 400 Ko, pour un élément qui ne comporte qu'un seul attribut, la taille de cet attribut peut atteindre 400 Ko, moins la taille occupée par le nom de l'attribut. Qualificatif de colonne : identifiant unique au sein d'une famille de colonnes. L'identifiant complet d'une colonne est exprimé sous la forme Les qualificatifs de colonne sont triés de manière lexicographique dans la famille de colonnes.

La taille maximale autorisée pour un qualificatif de colonne est de 16 Ko.


Cellule:une cellule contient les données d'une ligne, d'une colonne et d'un horodatage donnés. Une cellule contient une valeur allant jusqu'à 100 Mo.
Clé primaire : identifiant unique d'un élément dans une table. Il peut s'agir d'une clé de partition ou d'une clé composite.

Clé de partitionnement: clé primaire simple composée d'un attribut. Cela détermine la partition physique dans laquelle se trouve l'élément. La taille maximale autorisée est de 2 Ko.

Clé de tri: clé déterminant l'ordre des lignes dans une partition. La taille maximale autorisée est de 1 Ko.

Clé composite: clé primaire composée de deux propriétés, la clé de partition et un attribut de clé de tri ou de plage.		 Clé de ligne : identifiant unique d'un élément dans une table. Généralement représenté par une concaténation de valeurs et de délimiteurs. La taille maximale autorisée est de 4 Ko.

Les qualificatifs de colonne peuvent être utilisés pour fournir un comportement équivalent à celui de la clé de tri de DynamoDB.

Les clés composites peuvent être créées à l'aide de clés de ligne concaténées et de qualificatifs de colonne.

Pour en savoir plus, consultez l'exemple de traduction de schéma dans la section "Conception de schéma" de ce document.
Valeur TTL : les horodatages par élément déterminent à quel moment un élément n'est plus nécessaire. Après la date et l'heure de l'horodatage spécifié, l'élément est supprimé de votre table sans consommer de débit en écriture. Récupération de mémoire : les horodatages par cellule déterminent à quel moment un élément n'est plus nécessaire. La récupération de mémoire supprime les éléments arrivés à expiration lors d'un processus en arrière-plan appelé compactage. Les stratégies de récupération de mémoire sont définies au niveau de la famille de colonnes et peuvent supprimer des éléments non seulement en fonction de leur âge, mais également en fonction du nombre de versions que l'utilisateur souhaite gérer. Vous n'avez pas besoin de vous adapter à la capacité de compactage lors du dimensionnement de vos clusters.

Opérations

Les opérations de plan de données vous permettent d'effectuer des actions de création, lecture, mise à jour et suppression (CRUD) sur les données d'une table. Le tableau suivant compare les opérations de plan de données similaires pour DynamoDB et Bigtable.

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
Bigtable traite les opérations d'écriture comme des upserts.
UpdateItem
  • Écriture conditionnelle
  • Incrémenter et décrémenter
Bigtable traite les opérations d'écriture comme des upserts.
GetItem
BatchGetItem, Query et Scan		 `ReadRow`
`ReadRows` (plage, préfixe, analyse inverse)
Bigtable prend en charge l'analyse efficace par préfixe de clé de ligne, modèle d'expression régulière ou plage de clés de ligne avant ou arrière.

Types de données

Bigtable et DynamoDB sont tous deux sans schéma. Les colonnes peuvent être définies au moment de l'écriture sans que l'existence de colonnes ou les types de données ne soient appliqués au niveau de la table. De même, le type de données d'une colonne ou d'un attribut donné peut différer d'une ligne ou d'un élément à l'autre. Cependant, les API DynamoDB et Bigtable gèrent les types de données de différentes manières.

Chaque requête d'écriture DynamoDB inclut une définition de type pour chaque attribut, qui est renvoyée avec la réponse aux requêtes de lecture.

Bigtable traite tout comme des octets et s'attend à ce que le code client connaisse le type et l'encodage afin que le client puisse analyser correctement les réponses. Les opérations d'incrémentation constituent une exception, car elles interprètent les valeurs comme des entiers signés en mode big-endian de 64 bits.

Le tableau suivant compare les différences entre les types de données DynamoDB et Bigtable.

DynamoDB Bigtable
Types scalaires : renvoyés en tant que jetons de descripteur de type de données dans la réponse du serveur. Octets : les octets sont convertis selon les types souhaités dans l'application cliente.

Increment interprète la valeur comme un entier signé en mode big-endian de 64 bits.
Ensemble : collection non triée d'éléments uniques. Famille de colonnes : vous pouvez utiliser des qualificatifs de colonne comme noms de membres définis et, pour chacun d'eux, indiquer un seul octet 0 comme valeur de cellule. Les membres d'un ensemble sont triés de manière lexicographique dans leur famille de colonnes.
Mappage : collection non triée de paires clé/valeur avec des clés uniques. Famille de colonnes
Utilisez le qualificatif de colonne comme clé de mappage et valeur de cellule en tant que valeur. Les clés de mappage sont triées de manière lexicographique.
Liste : collection triée d'éléments. Qualificatif de colonne
Utilisez l'horodatage d'insertion pour obtenir l'équivalent du comportement "list_append", l'inverse de l'horodatage d'insertion pour le préfixe.

Conception de schémas

Lors de la conception d'un schéma, il est important de tenir compte de la façon dont les données sont stockées. Les principales différences entre Bigtable et DynamoDB réside dans la façon dont ils gèrent les éléments suivants:

  • Mises à jour de valeurs uniques
  • Tri des données
  • Gestion des versions des données
  • Stockage de grandes valeurs

Mises à jour de valeurs uniques

Les opérations UpdateItem dans DynamoDB consomment la capacité d'écriture pour la taille "avant" et "après" la plus élevée, même si la mise à jour implique un sous-ensemble des attributs de l'élément. Cela signifie que dans DynamoDB, vous pouvez placer les colonnes fréquemment mises à jour dans des lignes distinctes, même si, logiquement, elles appartiennent à la même ligne que d'autres colonnes.

Bigtable peut mettre à jour une cellule de manière aussi efficace, qu'il s'agisse de la seule colonne d'une ligne donnée ou d'une cellule parmi plusieurs milliers. Pour en savoir plus, consultez la section Écritures simples.

Tri des données

DynamoDB hache et distribue les clés de partitionnement de manière aléatoire, tandis que Bigtable stocke les lignes dans l'ordre lexicographique par clé de ligne et laisse à l'utilisateur le soin de gérer le hachage.

La distribution des clés aléatoires n'est pas optimale pour tous les modèles d'accès. Elle réduit le risque de plages de lignes actives, mais elle rend coûteux et inefficaces les modèles d'accès impliquant des analyses qui dépassent les limites de partition. Ces analyses illimitées sont courantes, en particulier pour les cas d'utilisation ayant une dimension temporelle.

La gestion de ce type de modèle d'accès (analyse qui traverse les limites de partition) nécessite un index secondaire dans DynamoDB, mais Bigtable le gère sans avoir besoin d'un index secondaire. De même, dans DynamoDB, les opérations de requête et d'analyse sont limitées à 1 Mo de données analysées, ce qui nécessite une pagination au-delà de cette limite. Bigtable n'a pas de telles limites.

Malgré ses clés de partition distribuées de manière aléatoire, DynamoDB peut toujours avoir des partitions à chaud si une clé de partition choisie ne répartit pas uniformément le trafic, ce qui affecte le débit. Pour résoudre ce problème, DynamoDB conseille la segmentation en écriture, qui consiste à répartir les écritures de manière aléatoire sur plusieurs valeurs de clé de partition logique.

Pour appliquer ce modèle de conception, vous devez créer un nombre aléatoire à partir d'un ensemble fixe (par exemple, de 1 à 10), puis utiliser ce nombre comme clé de partition logique. Étant donné que la clé de partitionnement est aléatoire, les écritures dans la table sont réparties de manière uniforme sur toutes les valeurs de la clé de partitionnement.

Bigtable qualifie cette procédure de salage de clés et peut constituer un moyen efficace d'éviter les tablets actifs.

Gestion des versions des données

Chaque cellule Bigtable possède un code temporel, et le code temporel le plus récent est toujours la valeur par défaut de toute colonne donnée. La gestion des versions est un cas d'utilisation courant des horodatages, qui consiste à écrire une nouvelle cellule dans une colonne différenciée des versions précédentes des données de cette ligne et de cette colonne par son horodatage.

DynamoDB n'a pas ce type de concept et nécessite des conceptions de schémas complexes pour permettre la gestion des versions. Cette approche implique de créer deux copies de chaque élément : une copie avec le préfixe de numéro de version de zéro, tel que v0_, au début de la clé de tri, et une autre copie avec le préfixe de numéro de version 1, tel que v1_. Chaque fois que l'élément est mis à jour, utilisez le préfixe de version suivant dans la clé de tri de la version mise à jour, puis copiez le contenu mis à jour dans l'élément avec le préfixe de version zéro. Cela garantit que la dernière version de n'importe quel élément peut être localisée à l'aide du préfixe zéro. Cette stratégie nécessite non seulement la maintenance de la logique côté application, mais elle rend également les écritures de données très coûteuses et lentes, car chaque écriture nécessite une lecture de la valeur précédente et deux écritures.

Transactions sur plusieurs lignes et grande capacité de lignes

Bigtable n'est pas compatible avec les transactions multilignes. Toutefois, comme cela vous permet de stocker des lignes beaucoup plus volumineuses que des éléments dans DynamoDB, vous pouvez souvent obtenir la transactionnalité prévue en concevant vos schémas pour regrouper les éléments pertinents sous une clé de ligne partagée. Pour obtenir un exemple illustrant cette approche, consultez la section Modèle de conception de table unique.

Stocker de grandes valeurs

Étant donné qu'un élément DynamoDB, qui est analogue à une ligne Bigtable, est limité à 400 Ko, le stockage de grandes valeurs nécessite de diviser la valeur entre les éléments ou de les stocker sur d'autres supports tels que S3. Ces deux approches augmentent la complexité de votre application. En revanche, une cellule Bigtable peut stocker jusqu'à 100 Mo et une ligne Bigtable peut en gérer jusqu'à 256 Mo.

Exemples de traduction de schéma

Les exemples de cette section traduisent des schémas de DynamoDB vers Bigtable en tenant compte des principales différences de conception des schémas.

Migrer des schémas de base

Les catalogues de produits sont un bon exemple pour illustrer le modèle de clé-valeur de base. Voici ce à quoi un tel schéma peut ressembler dans DynamoDB.

Clé primaire Attributs
Clé de partitionnement Touche de tri Description Prix Thumbnail
chapeaux fédoras#marqueA Fabriqué à partir de laine de première qualité... 30 https://storage…
chapeaux fédoras#marqueB Toile résistante à l'eau et durable 28 https://storage…
chapeaux gavroche#marqueB Ajoutez une touche de charme vintage à votre look de tous les jours. 25 https://storage…
chaussures baskets#marqueA Sortez avec style et confort avec... 40 https://storage…
chaussures baskets#marqueB Des éléments classiques avec des matériaux contemporains... 50 https://storage…

Pour cette table, le mappage de DynamoDB à Bigtable est simple: vous convertissez la clé primaire composite de DynamoDB en clé de ligne Bigtable composite. Vous créez une famille de colonnes (SKU) contenant le même ensemble de colonnes.

SKU
Clé de ligne Description Prix Thumbnail
chapeaux#fédoras#marqueA Fabriqué à partir de laine de première qualité... 30 https://storage…
chapeaux#fédoras#marqueB Toile résistante à l'eau et durable 28 https://storage…
chapeaux#chapeau#marqueB Ajoutez une touche de charme vintage à votre look de tous les jours. 25 https://storage…
chaussures#baskets#marqueA Sortez avec style et confort avec... 40 https://storage…
chaussures#baskets#marqueB Des éléments classiques avec des matériaux contemporains... 50 https://storage…

Modèle de conception à table unique

Un modèle de conception de table unique rassemble ce que serait plusieurs tables d'une base de données relationnelle en une seule table dans DynamoDB. Vous pouvez suivre l'approche de l'exemple précédent et dupliquer ce schéma tel quel dans Bigtable. Toutefois, il est préférable de résoudre les problèmes du schéma au cours du processus.

Dans ce schéma, la clé de partitionnement contient l'ID unique d'une vidéo, ce qui permet de colocaliser tous les attributs associés à cette vidéo pour un accès plus rapide. Compte tenu des limites de taille des éléments de DynamoDB, vous ne pouvez pas placer un nombre illimité de commentaires en texte libre sur une seule ligne. Par conséquent, une clé de tri avec le modèle VideoComment#reverse-timestamp est utilisée pour faire de chaque commentaire une ligne distincte dans la partition, triée dans l'ordre chronologique inverse.

Supposons que cette vidéo compte 500 commentaires et que le propriétaire souhaite la supprimer. Cela signifie que tous les commentaires et attributs de la vidéo doivent également être supprimés. Pour effectuer cette opération dans DynamoDB, vous devez analyser toutes les clés de cette partition, puis envoyer plusieurs requêtes de suppression, en répétant chacune d'elles. DynamoDB accepte les transactions multilignes, mais cette requête de suppression est trop volumineuse pour être effectuée en une seule transaction.

Clé primaire Attributs
Clé de partitionnement Touche de tri UploadDate Formats
0123 Vidéo 2023-09-10T15:21:48 {"480": "https://storage...", "720": "https://storage...", "1080p": "https://storage..."}
Commentaire vidéo#98765481 Contenu
J'aime beaucoup ça. Les effets spéciaux sont incroyables.
Commentaire vidéo#86751345 Contenu
Il semble y avoir un problème audio à 1:05.
VideoStatsLikes Nombre
3
VideoStatsViews Nombre
156
0124 Vidéo 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
Commentaire vidéo#97531849 Contenu
J'ai partagé ça avec tous mes amis.
Commentaire vidéo#87616471 Contenu
Le style me rappelle un réalisateur de cinéma, mais je n'arrive pas à mettre le doigt dessus.
VideoStats ViewCount
45

Modifiez ce schéma lors de la migration afin de simplifier votre code et d'accélérer et d'économiser les requêtes de données. Les lignes Bigtable ont une capacité beaucoup plus importante que les éléments DynamoDB et peuvent gérer un grand nombre de commentaires. Pour gérer les cas où une vidéo reçoit des millions de commentaires, vous pouvez définir une règle de récupération de mémoire afin de ne conserver qu'un nombre fixe de commentaires les plus récents.

Étant donné que les compteurs peuvent être mis à jour sans avoir à mettre à jour l'intégralité de la ligne, vous n'avez pas besoin de les diviser non plus. Vous n'avez pas non plus besoin d'utiliser une colonne "UploadDate" ni de calculer un horodatage inversé et d'en faire votre clé de tri, car les horodatages Bigtable vous fournissent automatiquement les commentaires dans l'ordre chronologique inverse. Cela simplifie considérablement le schéma. Si une vidéo est supprimée, vous pouvez supprimer de manière transactionnelle la ligne de la vidéo, y compris tous les commentaires, dans une seule requête.

Enfin, comme les colonnes dans Bigtable sont classées par ordre lexicographique, vous pouvez les renommer de manière à permettre une analyse rapide (des propriétés de la vidéo aux N premiers commentaires les plus récents) en une seule requête de lecture. C'est ce que vous devez faire une fois la vidéo chargée. Vous pourrez ensuite parcourir les autres commentaires à mesure que l'utilisateur les fera défiler.

Attributs
Clé de ligne Formats J'aime Vues UserComments
0123 {"480": "https://storage...", "720": "https://storage...", "1080p": "https://storage..."} @2023-09-10T15:21:48 3 156 J'aime beaucoup ça. Les effets spéciaux sont incroyables. @ 2023-09-10T19:01:15
Il semble y avoir un problème audio à 1:05. @ 2023-09-10T16:30:42
0124 {"480": "https://storage...", "720":"https://storage..."} @2023-09-10T17:03:21 45 Le style me rappelle un réalisateur de cinéma, mais je n'arrive pas à mettre le doigt dessus. @2023-10-12T07:08:51

Modèle de conception de liste d'adjacence

Envisagez une version légèrement différente de cette conception, que DynamoDB appelle souvent le modèle de conception de liste de contiguïté.

Clé primaire Attributs
Clé de partitionnement Touche de tri DateCreated Détails
Invoice-0123 Invoice-0123 2023-09-10T15:21:48 {"discount": 0,10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
Payment-0680 2023-09-10T15:21:40 {"amount_usd": 120, "bill_to":"Jean...",
"address":"123 Abc St..."}
Payment-0789 2023-09-10T15:21:31 {"amount_usd": 120, "bill_to":"Jane...",
"address":"13 rue Xyz..."}
Invoice-0124 Invoice-0124 2023-09-09T10:11:28 {"discount": 0,20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
Payment-0327 2023-09-09T10:11:10 {"amount_usd": 180, "bill_to":"Pierre...",
"address":"321 rue Cba..."}
Payment-0275 2023-09-09T10:11:03 {"amount_usd": 70, "bill_to":"Kate...",
"address":"21 Zyx St..."}

Dans ce tableau, les clés de tri ne sont pas basées sur le temps, mais plutôt sur les ID de paiement. Vous pouvez donc utiliser un modèle orienté colonnes différent et séparer les colonnes de ces ID dans Bigtable, avec des avantages semblables à l'exemple précédent.

Facture Paiement
clé de ligne Détails 0680 0789
0123 {"discount": 0,10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
@ 2023-09-10T15:21:48		 {"amount_usd": 120, "bill_to":"John...",
"address":"123 Abc St..."} @ 2023-09-10T15:21:40		 {"amount_usd": 120, "bill_to":"Jane...",
"address":"13 Xyz St..."}
@ 2023-09-10T15:21:31
clé de ligne Détails 0275 0327
0124 {"discount": 0,20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
@ 2023-09-09T10:11:28		 {"amount_usd": 70, "bill_to":"Kate...",
"address":"21 Zyx St..."}
@ 2023-09-09T10:11:03		 {"amount_usd": 180, "bill_to":"Bob...",
"address":"321 Cba St..."}
@ 2023-09-09T10:11:10

Comme vous pouvez le voir dans les exemples précédents, avec une conception de schéma appropriée, le modèle orienté colonnes de Bigtable peut s'avérer assez puissant et fournir de nombreux cas d'utilisation nécessitant des transactions multilignes coûteuses, une indexation secondaire ou un comportement en cascade lors de la suppression dans d'autres bases de données.

Étapes suivantes