Bigtable pour les utilisateurs de DynamoDB

Ce document est destiné aux développeurs et 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 clés-valeurs distribués pouvant accepter des millions de requêtes par seconde (RPS), offrant un espace de 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 présentent des différences 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 la capacité, ainsi que de configurer et de gérer les ressources. DynamoDB est un produit sans serveur. Le niveau d'interaction le plus élevé avec DynamoDB est au niveau de la table. En mode capacité provisionnée, c'est ici que vous provisionnez vos unités de requête de lecture et d'écriture, que vous sélectionnez les régions et la réplication, et que vous 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 du plan de contrôle pour DynamoDB et Bigtable.

DynamoDB	Bigtable
Table : collection 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 lesquelles la réplication et le routage de connexion 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 en colocation 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. Les unités de lecture ou d'écriture vous sont facturées pour chaque opération avec des charges utiles de plus grande taille. Les opérations 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 d'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 est converti en limites de débit pour les lectures, les écritures et les analyses. Vous pouvez ajuster le nombre de nœuds en fonction 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 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 reposant sur le support de stockage de votre choix (SSD ou HDD). Les tables sont segmentées en tablettes pour équilibrer la charge de travail. Elles ne sont pas stockées sur les nœuds dans Bigtable, mais sur le système de fichiers distribué de Google, ce 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 apportées aux 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é de l'instance. Vous pouvez aussi utiliser un profil d'application comme balise pour segmenter les métriques à attribuer.

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 d'une zone ou d'une région
• Placez les données de votre service à proximité des utilisateurs finaux pour un service à faible latence, où qu'ils se trouvent dans le monde.
• L'isolation de la charge de travail lorsque vous devez mettre en œuvre une charge de travail par lot sur un cluster et dépendre de la réplication sur les clusters de diffusion.

Bigtable accepte les clusters répliqués dans un maximum de zones dans un maximum de huit régions Google Cloud où Bigtable est disponible. La plupart des régions comptent trois zones. Bigtable réplique automatiquement les données sur les clusters dans une topologie multi-principale, ce qui signifie que vous pouvez lire et écrire des données dans 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 répliquées automatiquement dans toutes 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 multi-principale	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érence à terme. Cohérence des opérations de lecture/écriture au niveau régional pour les tables globales.	Cohérence à terme. Cohérence de type "lecture/écriture" au niveau régional pour toutes les tables.
Latence de réplication	Aucun contrat de niveau de service. 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 répliquée de table dans chaque région sélectionnée. Au niveau régional. Réplication automatique sur des instances répliquées en convertissant une table en table globale. Les flux DynamoDB doivent être activés sur les tables, et ce flux doit contenir à la fois les nouvelles et les anciennes images de l'élément. Supprimez une région pour supprimer la table globale de cette région.	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.
Routage et disponibilité 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 les règles de routage du trafic du 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êtes 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ée (R-RCU) est calculée par instance répliquée.	Vous pouvez procéder au scaling des clusters indépendamment, en ajoutant ou en supprimant des nœuds de chaque cluster répliqué, selon les besoins.
Coût	Elles coûtent 50% de plus que les WRU standards.	Les nœuds et l'espace de stockage de chaque cluster vous sont facturés. Aucun coût de réplication réseau n'est appliqué pour la réplication régionale entre les zones. Des frais sont facturés lorsque la réplication s'effectue sur 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èle 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 les colonnes.
Attribut : regroupement d'un nom et d'une valeur. La valeur d'un attribut peut être de type scalaire, défini ou de type document. Il n'y a pas de limite explicite à la taille des attributs eux-mêmes. Toutefois, étant donné que chaque élément est limité à 400 Ko, pour un élément ne comportant qu'un seul attribut, la taille de 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 est exprimé sous la forme "famille de colonnes:qualificatif de colonne". Les qualificatifs de colonne sont triés de manière 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 horodatage donnés. Une cellule contient une valeur qui peut atteindre 100 Mo.
Clé primaire : identifiant unique d'un élément d'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é 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 d'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 permettent d'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ées. Pour en savoir plus, consultez l'exemple de traduction de schéma dans la section "Conception de schémas" 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 la table sans consommer de débit en écriture.	Récupération de mémoire : l'horodatage par cellule détermine à quel moment un élément n'est plus nécessaire. La récupération de mémoire supprime les éléments arrivés à expiration au cours 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 CRUD (création, lecture, mise à jour et suppression) sur les données d'une table. Le tableau suivant compare des 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 diminuer	CheckAndMutateRow ReadModifyWriteRow Bigtable traite les opérations d'écriture comme des insertions.
GetItem BatchGetItem, Query et Scan	`ReadRow` `ReadRows` (plage, préfixe, analyse inversée) Bigtable permet une analyse efficace par préfixe de clé de ligne, modèle d'expression régulière ou plage de clés de ligne en avant ou en 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 d'application au niveau de la table pour l'existence de colonnes ou les types de données. De même, un type de données de colonne ou d'attribut donné peut différer d'une ligne ou d'un élément à un 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 sous forme d'octets et s'attend à ce que le code client connaisse le type et l'encodage afin que le client puisse analyser les réponses correctement. Les opérations d'incrémentation constituent une exception à cette règle, car elles interprètent les valeurs comme des entiers signés 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 sous forme de jetons de descripteur de type de données dans la réponse du serveur.	Octets : les octets sont convertis en types prévus dans l'application cliente. Increment 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 définis et, pour chacun, fournir un octet 0 comme valeur de cellule. Les membres de l'ensemble sont triés de façon lexicographique dans leur famille de colonnes.
Mappage : collection non triée de paires clé/valeur dotées de clés uniques.	Famille de colonnes Utilisez le qualificatif de colonne comme clé de mappage et valeur de cellule pour la 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 de list_append, inverse de l'horodatage d'insertion pour le préfixe.

Conception de schémas

La façon dont les données sont stockées est un élément important à prendre en compte lors de la conception d'un schéma. Parmi les principales différences entre Bigtable et DynamoDB, citons la manière 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 de la taille d'élément "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 elles appartiennent logiquement à la même ligne que d'autres colonnes.

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

Tri des données

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

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 sollicitées, mais rend les modèles d'accès qui impliquent des analyses qui dépassent les limites de la partition, mais qui sont coûteux et inefficaces. 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 inter-partitions) nécessite un index secondaire dans DynamoDB, tandis que Bigtable s'en charge sans 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'impose pas de telles limites.

Malgré ses clés de partition distribuées de manière aléatoire, DynamoDB peut toujours utiliser des partitions à chaud si la clé de partition sélectionnée ne répartit pas de manière uniforme le trafic qui affecte le débit. Pour résoudre ce problème, DynamoDB conseille la segmentation en écriture, 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 la clé de partition est aléatoire, les écritures dans la table sont réparties uniformément entre toutes les valeurs de clé de partition.

Bigtable fait référence à cette procédure en tant que salage de clés et peut être un moyen efficace d'éviter les comprimés chauds.

Gestion des versions des données

Chaque cellule Bigtable comporte un horodatage, et l'horodatage le plus récent est toujours la valeur par défaut d'une colonne donnée. Un cas d'utilisation courant des horodatages est la gestion des versions, c'est-à-dire l'écriture d'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 horodatage.

DynamoDB ne dispose pas d'un tel concept et nécessite des conceptions de schémas complexes pour permettre la gestion des versions. Cette approche implique la création de 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 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 supérieur suivant dans la clé de tri de la version mise à jour et vous copiez le contenu mis à jour dans l'élément dont le préfixe de version est "zéro". Cela garantit que la dernière version de tout élément peut être localisée à l'aide du préfixe zéro. Cette stratégie nécessite non seulement la gestion 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 multilignes et grande capacité de lignes

Bigtable n'est pas compatible avec les transactions à plusieurs lignes. Toutefois, comme il vous permet de stocker des lignes beaucoup plus volumineuses que les éléments disponibles 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 ressemble à une ligne Bigtable, est limité à 400 Ko, le stockage de valeurs volumineuses nécessite de diviser la valeur entre les éléments ou de le 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, tandis qu'une ligne Bigtable peut stocker jusqu'à 256 Mo.

Exemples de traduction de schéma

Les exemples de cette section traduisent les 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 d'illustration du modèle de clé-valeur de base. Voici à quoi peut ressembler un tel schéma dans DynamoDB.

Clé primaire		Attributs
Clé de partition	Clé de tri	Description	Prix	Thumbnail
chapeaux	fédoras#marqueA	Fabriqué à partir de laine de haute qualité...	30	https://storage…
chapeaux	fédoras#marqueB	Toile résistante à l'eau et conçue pour...	28	https://storage…
chapeaux	gavroche#marqueB	Ajoutez une touche de charme vintage à votre look de tous les jours.	25	https://storage…
chaussures	baskets#marqueA	Trouvez votre style et votre confort avec...	40	https://storage…
chaussures	baskets#marqueB	Éléments classiques et matériaux contemporains...	50	https://storage…

Pour cette table, le mappage 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 possède également un horodatage , qui n'est pas indiqué dans le tableau par souci de concision.

	SKU
Clé de ligne	Description	Prix	Thumbnail
chapeaux#fédoras#marqueA	Fabriqué à partir de laine de haute qualité...	30	https://storage…
chapeaux#fédoras#marqueB	Toile résistante à l'eau et conçue pour...	28	https://storage…
chapeaux#jeu d'actualités#marqueB	Ajoutez une touche de charme vintage à votre look de tous les jours.	25	https://storage…
chaussures#baskets#marqueA	Trouvez votre style et votre confort avec...	40	https://storage…
chaussures#baskets#marqueB	Éléments classiques et matériaux contemporains...	50	https://storage…

Modèle de conception de table unique

Un modèle de conception de table unique rassemble plusieurs tables d'une base de données relationnelle en une seule table dans DynamoDB. Vous pouvez adopter 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 liés au schéma dans le processus.

Dans ce schéma, la clé de partition contient l'ID unique d'une vidéo, ce qui permet de cohéberger 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 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 permet de faire de chaque commentaire une ligne distincte dans la partition, triée dans l'ordre chronologique inverse.

Supposons que cette vidéo ait reçu 500 commentaires et que son propriétaire veuille la supprimer. Cela signifie que tous les commentaires et attributs des vidéos doivent également être supprimés. Pour ce faire, vous devez analyser toutes les clés de cette partition dans DynamoDB, puis émettre plusieurs requêtes de suppression en effectuant une itération pour chacune d'elles. DynamoDB accepte les transactions à plusieurs lignes, 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..."}
	VidéoCommentaire#98765481	Contenu
		J'aime beaucoup. 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…"}
	VidéoCommentaire#97531849	Contenu
		J'ai partagé ce contenu avec tous mes amis.
	Commentaire vidéo#87616471	Contenu
		Le style me fait penser à un réalisateur de cinéma, mais je n'arrive pas à y mettre le doigt.
	VideoStats	ViewCount
		45

Modifiez ce schéma lors 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 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'ensemble de la ligne, vous n'avez pas non plus besoin de les diviser. Vous n'avez pas non plus besoin d'utiliser une colonne UploadDate ni de calculer un horodatage inversé et de définir cette clé de tri comme clé de tri, car les horodatages Bigtable vous donnent automatiquement les commentaires dans l'ordre chronologique inverse. Cela simplifie considérablement le schéma, et 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, via une seule requête.

Enfin, dans Bigtable, les colonnes étant organisées de façon lexicographique, à des fins d'optimisation, vous pouvez renommer les colonnes 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, ce que vous devez faire une fois la vidéo chargée. Ensuite, vous pouvez parcourir les autres commentaires à mesure que l'utilisateur fait 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. 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 fait penser à un réalisateur de cinéma, mais je n'arrive pas à y mettre le doigt. @2023-10-12T07:08:51

Modèle de conception d'une liste d'annonces

Prenons l'exemple d'une version légèrement différente de cette conception, que DynamoDB appelle souvent le modèle de conception de liste d'continuité.

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":"03/10/2023.."}
	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":"03/10/2023.."}
	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 cette table, les clés de tri ne sont pas basées sur l'heure, mais plutôt sur les ID de paiement. Vous pouvez donc utiliser un modèle de colonne large différent et séparer ces ID de colonnes 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":"03/10/2023.."} @ 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":"03/10/2023.."} @ 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é colonne de Bigtable peut être assez puissant et offrir 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

• 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.