Bigtable pour les utilisateurs de DynamoDB

Ce document s'adresse aux développeurs DynamoDB et aux administrateurs de bases de données 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 capables de prendre en charge des millions de requêtes par seconde (RPS), de fournir un espace de stockage évolutif jusqu'à plusieurs pétaoctets de données et de tolérer les défaillances de nœud.

Bien que les ensembles de fonctionnalités de ces services de base de données soient similaires, leurs architectures sous-jacentes et les détails des interactions diffèrent de manière importante, ce qui est important à 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é, et de configurer et de gérer les ressources. DynamoDB est un produit sans serveur, et le niveau d'interaction le plus élevé avec DynamoDB est le niveau de la table. En mode capacité provisionnée, vous provisionnez vos unités de requêtes 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. Pour en savoir plus sur ces ressources, consultez la section Instances, clusters et nœuds.

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

DynamoDB	Bigtable
Table : ensemble d'éléments avec une clé primaire définie. Les tables comportent des 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 lesquels la réplication et le routage de connexion se produisent. 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é avec votre serveur d'application 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 de valeurs indexée par la 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 permettant des lectures ou des écritures par seconde avec une taille de charge utile fixe. Vous êtes facturé pour les unités de lecture ou d'écriture pour chaque opération avec des tailles de charge utile plus importantes.Les opérations , et UpdateItem consomment la capacité d'écriture utilisée pour la plus grande taille d'un élément mis à jour, avant ou après la mise à jour, même si la mise à jour implique un sous-ensemble des attributs de l'élément.	Nœud:ressource de calcul virtuel 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 pour les lectures et les écritures, 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, basé sur des disques SSD colocalisés avec des nœuds. Chaque partition est soumise à une limite stricte de 1 000 UC, 3 000 UC et 10 Go de données.	Tablette : bloc de lignes contiguës basé sur 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ées sur les nœuds de Bigtable, mais sur le système de fichiers distribué de Google, ce qui permet de redistribuer rapidement les données lors de la mise à l'échelle 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 : méthode permettant 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 router un appel d'API cliente vers le cluster approprié dans l'instance. Vous pouvez également utiliser un profil d'application en tant que tag pour segmenter les métriques d'attribution.

Réplication géographique

La réplication permet de répondre aux exigences des clients pour les éléments suivants:

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

Bigtable est compatible avec les clusters répliqués dans autant de zones disponibles dans un maximum de huit régions Google Cloud où Bigtable est disponible. La plupart des régions en comptent trois. Pour en savoir plus, consultez la page Régions et zones.

Bigtable réplique automatiquement les données entre les clusters dans une topologie multi-principale. Vous pouvez donc lire et écrire sur n'importe quel cluster. La réplication Bigtable est cohérente à terme. Pour en savoir plus, consultez la section Présentation de la réplication.

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

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

Propriété	DynamoDB	Bigtable
Réplication multi-maître	Oui. Vous pouvez lire et écrire dans n'importe quelle table globale.	Oui. Vous pouvez lire et écrire dans n'importe quel cluster Bigtable.
Modèle de cohérence	Cohérent à terme Cohérence écriture-lecture (read-your-writes) au niveau régional pour les tables globales.	Cohérent à terme Cohérence de type "lecture de vos écritures" au niveau du cluster pour toutes les tables, à condition que vous envoyiez les lectures et les écritures au même cluster.
Latence de réplication	Aucun contrat de niveau de service (SLA) Secondes	Aucun SLA. Secondes
Précision de la configuration	Au niveau de la table.	Au niveau de l'instance. Une instance peut contenir plusieurs tables.
Mise en œuvre	Créez une table globale avec un réplica de table dans chaque région sélectionnée. Niveau régional. Replication automatique entre les réplicas en convertissant une table en table globale. Les tables doivent avoir activé DynamoDB Streams, et le flux doit contenir à la fois la nouvelle et l'ancienne image de l'article. Supprimez une région pour supprimer le tableau global dans cette région.	Créez une instance avec plusieurs clusters. La réplication est automatique entre les clusters de cette instance. Au niveau zonal. Ajoutez et supprimez des clusters d'une instance Bigtable.
Options de réplication	Par table.	Par instance.
Routage et disponibilité du trafic	Trafic acheminé vers le réplica géographique le plus proche. En cas de défaillance, 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 les règles de routage du trafic de cluster. Utilisez le routage multicluster pour acheminer automatiquement le trafic vers le cluster sain le plus proche. En cas de défaillance, Bigtable prend en charge le basculement automatique entre les clusters pour la haute disponibilité.
Échelle	La capacité d'écriture en unités de requêtes d'écriture répliquées (R-WRU) est synchronisée entre les réplicas. La capacité de lecture en unités de capacité de lecture répliquées (R-RCU) est par réplication.	Vous pouvez faire évoluer les clusters indépendamment en ajoutant ou en supprimant des nœuds de chaque cluster répliqué selon les besoins.
Coût	Les WRU R coûtent 50% plus cher que les WRU standards.	Vous êtes facturé pour les nœuds et le stockage de chaque cluster. Aucuns frais de réplication réseau ne sont facturés pour la réplication régionale entre les zones. Des coûts sont facturés lorsque la réplication s'effectue entre des régions ou des continents.
Contrat de niveau de service	99,999 %	99,999 %

Plan de données

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

DynamoDB	Bigtable
Élément : groupe d'attributs qui est unique parmi tous les autres éléments grâce à sa clé primaire. La taille maximale autorisée est de 400 Ko.	Ligne : entité unique identifiée par la clé de ligne. La taille maximale autorisée est de 256 Mo.
N/A	Famille de colonnes:espace de noms spécifié par l'utilisateur qui regroupe les colonnes.
Attribut : regroupement d'un nom et d'une valeur. La valeur d'un attribut peut être un scalaire, un ensemble ou un type de document. Il n'existe aucune limite explicite sur la taille de l'attribut lui-même. Toutefois, comme chaque élément est limité à 400 ko, pour un élément qui ne comporte qu'un seul attribut, l'attribut peut atteindre 400 ko moins la taille occupée par le nom de l'attribut.	Qualificatif de colonne : identifiant unique d'une colonne dans une famille de colonnes. L'identifiant complet d'une colonne s'exprime sous la forme famille-de-colonnes:qualificatif-de-colonne. Les qualificatifs de colonne sont triés par ordre lexicographique au sein de 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 code temporel donnés. Une cellule contient une valeur pouvant atteindre 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 partition: clé primaire simple, composée d'un seul attribut. Cela détermine la partition physique où se trouve l'élément. La taille maximale autorisée est de 2 Ko. Clé de tri: clé qui détermine 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 une clé de tri ou un attribut de plage.	Clé de ligne : identifiant unique d'un élément dans un tableau. Représenté généralement par une concaténation de valeurs et de séparateurs. La taille maximale autorisée est de 4 Ko. Les qualificateurs de colonne peuvent être utilisés pour obtenir 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 et de qualificatifs de colonne concaténés. Pour en savoir plus, consultez l'exemple de traduction de schéma dans la section "Conception de schéma" de ce document.
Time to live (durée de vie) : les codes temporels par élément déterminent quand un élément n'est plus nécessaire. Après la date et l'heure du code temporel spécifié, l'élément est supprimé de votre table sans consommer de débit d'écriture.	Récupération de mémoire : les codes temporels par cellule déterminent quand un élément n'est plus nécessaire. La récupération de mémoire supprime les éléments expirés 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 aussi en fonction du nombre de versions que l'utilisateur souhaite conserver. Vous n'avez pas besoin de tenir compte de la capacité de compaction lors du dimensionnement de vos clusters.

Opérations

Les opérations du plan de données vous permettent d'effectuer des actions de création, de lecture, de mise à jour et de 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 mises à jour.
UpdateItem Écriture conditionnelle Incrémentation et décrémentation	CheckAndMutateRow ReadModifyWriteRow Bigtable traite les opérations d'écriture comme des mises à jour.
GetItem BatchGetItem, Query, Scan	ReadRow ReadRows (plage, préfixe, analyse inverse) Bigtable prend en charge une analyse efficace par préfixe de clé de ligne, par expression régulière ou par plage de clé de ligne avant ou arrière.

Types de données

Bigtable et DynamoDB sont sans schéma. Les colonnes peuvent être définies au moment de l'écriture, sans aucune application à l'échelle de la table pour l'existence des colonnes ou les types de données. De même, un type de données de colonne ou d'attribut donné peut varier d'une ligne ou d'un élément à l'autre. Toutefois, les API DynamoDB et Bigtable traitent les types de données de manière différente.

Chaque requête d'écriture DynamoDB inclut une définition de type pour chaque attribut, qui est renvoyée avec la réponse pour les 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 qu'il 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 de 64 bits en mode big-endian.

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

DynamoDB	Bigtable
Types scalaires : renvoyés sous forme de jetons de décriteur de type de données dans la réponse du serveur.	Octets : les octets sont convertis en types prévus dans l'application cliente. Incrément interprète la valeur comme un entier signé 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 de l'ensemble. Pour chacun d'eux, indiquez un seul octet 0 comme valeur de la cellule. Les membres de l'ensemble sont triés par ordre lexicographique au sein de leur famille de colonnes.
Map : ensemble non trié de paires clé-valeur avec des clés uniques.	Famille de colonnes Utilisez le qualificatif de colonne comme clé de mappage et la valeur de la cellule comme valeur. Les clés de carte sont triées de manière lexicographique.
Liste : ensemble d'éléments triés.	Qualificateur de colonne Utilisez l'horodatage d'insertion pour obtenir l'équivalent du comportement de list_append, à l'inverse de l'horodatage d'insertion pour l'ajout.

Conception de schémas

La manière dont les données sont stockées est un point important à prendre en compte lors de la conception du schéma. Parmi les principales différences entre Bigtable et DynamoDB, citons 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 valeurs importantes

Mises à jour de valeurs uniques

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

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

Tri des données

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

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

La gestion de ce type de modèle d'accès (analyses qui traversent les limites de partition) nécessite un indice secondaire dans DynamoDB, mais Bigtable gère cela sans indice 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 limite de ce type.

Malgré ses clés de partition distribuées de manière aléatoire, DynamoDB peut toujours présenter des partitions actives si une clé de partition choisie ne distribue pas uniformément le trafic qui affecte négativement le débit. Pour résoudre ce problème, DynamoDB recommande le fractionnement des écritures, qui consiste à répartir de manière aléatoire les écritures 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 vous randomisez la clé de partition, les écritures dans la table sont réparties uniformément sur toutes les valeurs de la clé de partition.

Bigtable appelle cette procédure salage de clé. Elle peut être un moyen efficace d'éviter les tablets actives.

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 pour une colonne donnée. Un cas d'utilisation courant des codes temporels est le gestion des versions : écrire une nouvelle cellule dans une colonne qui se distingue des versions précédentes des données pour cette ligne et cette colonne par son code temporel.

DynamoDB ne propose pas ce concept et nécessite des conceptions de schéma complexes pour prendre en charge la gestion des versions. Cette approche implique de créer deux copies de chaque élément : une copie avec un 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 un préfixe de numéro de version de un, tel que v1_. Chaque fois que l'élément est mis à jour, vous utilisez le préfixe de version le plus élevé dans la clé de tri de la version mise à jour, puis vous copiez le contenu mis à jour dans l'élément avec le préfixe de version 0. 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 une logique côté application pour la maintenance, mais 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, plus deux écritures.

Transactions multilignes par rapport à la grande capacité de ligne

Bigtable n'est pas compatible avec les transactions multilignes. Toutefois, comme il vous permet de stocker des lignes beaucoup plus volumineuses que les éléments dans DynamoDB, vous pouvez souvent obtenir la transactionalité souhaitée 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 des valeurs importantes

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

Exemples de traduction de schémas

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

Migrer des schémas de base

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

Clé primaire		Attributs
Clé de partition	Clé de tri	Description	Prix	Thumbnail
chapeaux	fedoras#brandA	Fabriqué en laine de qualité supérieure…	30	https://storage…
chapeaux	fedoras#brandB	Tissu en toile résistant et étanche conçu pour..	28	https://storage…
chapeaux	newsboy#brandB	Ajoutez une touche de charme vintage à votre look quotidien.	25	https://storage…
chaussures	sneakers#brandA	Sortez avec style et confort grâce à…	40	https://storage…
chaussures	baskets#marqueB	Caractéristiques classiques avec des matériaux contemporains…	50	https://storage…

Pour cette table, la mise en correspondance de DynamoDB vers 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.

Remarque :Chaque valeur dans Bigtable comporte également un code temporel , qui n'est pas affiché dans le tableau par souci de concision.

	SKU
Clé de ligne	Description	Prix	Thumbnail
chapeaux#fedoras#marqueA	Fabriqué en laine de qualité supérieure…	30	https://storage…
chapeaux#fedoras#brandB	Tissu en toile résistant et étanche conçu pour..	28	https://storage…
chapeaux#gavroche#marqueB	Ajoutez une touche de charme vintage à votre look quotidien.	25	https://storage…
chaussures#baskets#marqueA	Sortez avec style et confort grâce à…	40	https://storage…
chaussures#baskets#marqueB	Caractéristiques classiques avec des matériaux contemporains…	50	https://storage…

Modèle de conception de table unique

Un modèle de conception de table unique rassemble ce qui serait plusieurs tables dans 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 partition contient l'ID unique d'une vidéo, ce qui permet de placer tous les attributs associés à cette vidéo pour un accès plus rapide. Étant donné les limites de taille des éléments de DynamoDB, vous ne pouvez pas ajouter un nombre illimité de commentaires de texte libre dans une seule ligne. Par conséquent, une clé de tri avec le format 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 les attributs de la vidéo doivent également être supprimés. Pour ce faire dans DynamoDB, vous devez analyser toutes les clés de cette partition, puis émettre plusieurs requêtes de suppression, en itérant sur chacune d'elles. DynamoDB prend en charge 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 partition	Clé de tri	UploadDate	Formats
0123	Vidéo	2023-09-10T15:21:48	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
	VideoComment#98765481	Contenu
		J'aime beaucoup cette idée. Les effets spéciaux sont incroyables.
	VideoComment#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…"}
	VideoComment#97531849	Contenu
		Je l'ai partagé avec tous mes amis.
	VideoComment#87616471	Contenu
		Le style me rappelle un réalisateur, mais je ne sais pas lequel.
	VideoStats	ViewCount
		45

Modifiez ce schéma au fur et à mesure de la migration afin de simplifier votre code et de rendre les requêtes de données plus rapides et moins coûteuses. 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 le cas où une vidéo reçoit des millions de commentaires, vous pouvez définir une règle de collecte des déchets 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'ensemble de la ligne, vous n'avez pas non plus à les diviser. Vous n'avez pas besoin d'utiliser une colonne "UploadDate" ni de calculer un code temporel inversé et de l'utiliser comme clé de tri, car les codes temporels Bigtable vous fournissent automatiquement les commentaires triés par ordre chronologique inverse. Cela simplifie considérablement le schéma. Si une vidéo est supprimée, vous pouvez supprimer la ligne de la vidéo, y compris tous les commentaires, en une seule requête.

Enfin, comme les colonnes de Bigtable sont ordonnées de manière lexicographique, vous pouvez les renommer de manière à effectuer une analyse de plage rapide (des propriétés vidéo aux N commentaires les plus récents) en une seule requête de lecture, ce que vous souhaitez faire lorsque la vidéo est chargée. Vous pourrez ensuite faire défiler le reste des commentaires à mesure que le lecteur fera défiler la page.

	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 cette idée. 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, mais je ne sais pas lequel. @2023-10-12T07:08:51

Modèle de conception de liste d'adjacence

Considérons une version légèrement différente de cette conception, que DynamoDB appelle souvent le modèle de conception de liste d'adjacence.

Clé primaire		Attributs
Clé de partition	Clé 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":"John…", "address":"123 Abc St…"}
	Payment-0789	2023-09-10T15:21:31	{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"}
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":"Bob…", "address":"321 Cba St…"}
	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 sur les ID de paiement. Vous pouvez donc utiliser un autre modèle de colonne large et faire de ces ID des colonnes distinctes dans Bigtable, avec des avantages similaires à 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 constater dans les exemples précédents, avec une conception de schéma appropriée, le modèle à colonnes larges de Bigtable peut être très puissant et offrir de nombreux cas d'utilisation qui nécessiteraient des transactions multilignes coûteuses, un index secondaire ou un comportement en cascade en cas de suppression dans d'autres bases de données.

Étape suivante

• Découvrez la conception de schémas Bigtable.
• Découvrez l'émulateur Bigtable.
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.