Bigtable pour les utilisateurs de DynamoDB
Ce document est destiné aux développeurs et aux bases de données DynamoDB les administrateurs qui souhaitent migrer à utiliser avec Bigtable en tant que datastore. Avant de lire ce document, consultez la présentation de Bigtable.
Bigtable et DynamoDB sont des magasins clé-valeur distribués pouvant prendre en charge des millions de requêtes par seconde (RPS), offrent un stockage de données et tolérer les défaillances de nœuds.
Bien que les jeux 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 avant de commencer une migration. Ce document met en avant 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 et de configurer et gérer les ressources. DynamoDB est un produit sans serveur, et le niveau le plus élevé d’interaction avec DynamoDB est au niveau de la table. Dans avec capacité provisionnée, qui vous permet de provisionner vos ressources de lecture et d'écriture des unités de requête, sélectionner les régions et la réplication, et gérer 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 elles disposent. Pour en savoir plus sur ces ressources, consultez Instances, clusters et nœuds.
Le tableau suivant compare les ressources de plan de contrôle pour DynamoDB et Bigtable.
| DynamoDB | Bigtable |
|---|---|
| Tableau : collection d'éléments avec un élément principal défini. . Les tables comportent des paramètres pour les sauvegardes, la réplication et la capacité. | Instance:un groupe de clusters Bigtable
dans différentes zones ou régions Google Cloud, entre quelles réplications
et le routage de la connexion. Les règles de réplication sont définies au niveau
au niveau de l'instance. Cluster:groupe de nœuds dans la même zone géographique Zone Google Cloud, idéalement en colocation avec votre application pour des raisons de latence et de réplication. La capacité est gérée par ajuster le nombre de nœuds dans chaque cluster. Table: une organisation logique de 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
la taille de la charge utile. Les unités de lecture ou d'écriture vous sont facturées pour chaque
avec des charges utiles de plus grande taille. Les opérations UpdateItem consomment la capacité d'écriture utilisée pour le
la taille maximale 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'article. |
Nœud:ressource de calcul virtuelle chargée de
la lecture et l'écriture de 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
les objectifs de latence, le nombre de requêtes et la taille de la charge utile. Les nœuds SSD offrent le même débit en lecture et en écriture, la différence significative entre les RCU et les WCU. Pour plus d'informations, 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é par le
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 tablettes sont et non sur des nœuds Bigtable, qui permet une redistribution rapide des données lors du scaling, et améliore la durabilité en maintenant plusieurs copies. |
| Tables globales : un moyen d'augmenter la disponibilité et durabilité de vos données grâce à la propagation automatique des modifications dans plusieurs régions. | Réplication : moyen d'augmenter la disponibilité et durabilité de vos données grâce à la propagation automatique des modifications dans plusieurs régions ou dans plusieurs zones d'une même dans la même région. |
| Non applicable (N/A) | Profil d'application : paramètres qui indiquent comment acheminer 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 à des fins d'attribution. |
Réplication géographique
La réplication permet de répondre aux exigences des clients dans les cas suivants:
- une haute disponibilité pour la continuité des activités en cas d'incident en cas de défaillance régionale.
- Placer les données de vos services à proximité des utilisateurs finaux pour et à 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 une et de compter sur la réplication vers les clusters de diffusion.
Bigtable accepte les clusters répliqués dans autant de zones disponibles dans jusqu'à huit régions Google Cloud Bigtable est disponible. La plupart des régions comportent trois zones. Bigtable réplique automatiquement les données sur plusieurs clusters dans une multi-principal, 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 Présentation de la réplication
DynamoDB fournit Tables globales pour permettre la réplication des tables dans plusieurs régions. Les tables globales sont et se répliquer automatiquement dans toutes les régions. La réplication est cohérentes à 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 écriture-lecture au niveau régional pour une gestion tableaux. |
Cohérence à terme. Une cohérence "lecture/écriture" au niveau du cluster à condition que vous envoyiez à 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. |
| Mise en œuvre | Créer une table globale avec une instance répliquée de table dans chaque table sélectionnée
dans la même région. Au niveau régional. Réplication automatique sur plusieurs instances répliquées en convertissant une table en globale. Les flux DynamoDB doivent être activés sur les tables, et le flux contenant à la fois les nouvelles et les anciennes images de l'article. 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. Ajouter et supprimer des clusters d'une table Bigtable Compute Engine. |
| 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. |
Utiliser 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 est compatible avec 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
sont synchronisées entre les instances répliquées. La capacité en lecture dans les unités de capacité de lecture répliquées (R-RCU) est par instance répliquée. |
Vous pouvez effectuer le scaling des clusters indépendamment en ajoutant ou en supprimant des nœuds chaque cluster répliqué selon les 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 entre les 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 uniques identifiable parmi tous les autres éléments grâce à sa clé primaire. Maximum la taille 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. |
| 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. Une La valeur de l'attribut peut être une valeur scalaire, un ensemble ou un type de document. Il n'y a aucun limite explicite sur la taille de l'attribut lui-même. Toutefois, chaque élément est limitée à 400 Ko. Pour un élément qui ne comporte qu'un seul attribut, peut atteindre 400 Ko, moins la taille occupée par le nom d'attribut. | Qualificatif de colonne : identifiant unique au sein d'une
famille de colonnes d'une colonne. L'identifiant complet d'une colonne est
exprimé sous la forme
famille-colonne:qualificatif-colonne. Les qualificatifs de colonne sont
triées 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 l'horodatage. Une cellule contient une valeur allant jusqu'à 100 Mo. |
| Clé primaire : identifiant unique d'un élément dans une
tableau. Il peut s'agir d'une clé de partition ou d'une clé composite. Clé de partitionnement: clé primaire simple composée d'une . Cela détermine la partition physique dans laquelle se trouve l'élément localisés. 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 la clé de partitionnement 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 déterminer le comportement équivalente à celle de la clé de tri de DynamoDB. Les clés composites peuvent être créées à l'aide de lignes concaténées. des clés et des qualificatifs de colonne. Pour en savoir plus, consultez l'exemple de traduction de schéma dans "Schéma" sur la conception de ce document. |
| Valeur TTL : les codes temporels par élément déterminent si une valeur n'est plus nécessaire. Après la date et l'heure de l'événement code temporel, l'élément est supprimé de votre table sans consommer débit en écriture. | Récupération de mémoire : les codes temporels par cellule déterminent lorsqu'un élément n'est plus nécessaire. Les opérations de suppression de la récupération de mémoire ont expiré des éléments au cours d'un processus en arrière-plan appelé compactage. Déchets les stratégies de collection sont définies au niveau de la famille de colonnes et peuvent supprimer non seulement en fonction de leur âge, mais aussi du nombre versions que l'utilisateur souhaite gérer. Vous n'avez pas besoin d'adapter de compactage lors du dimensionnement de vos clusters. |
Opérations
Les opérations du plan de données vous permettent d'effectuer des opérations de création, de lecture, de mise à jour et de suppression (CRUD) sur les données d'un tableau. Le tableau suivant compare les plans de données similaires pour DynamoDB et Bigtable.
| DynamoDB | Bigtable |
|---|---|
CreateTable |
CreateTable |
PutItemBatchWriteItem |
MutateRow MutateRowsBigtable traite les opérations d'écriture comme des opérations upserts. |
UpdateItem
|
Bigtable traite les opérations d'écriture comme des opérations upserts. |
GetItemBatchGetItem, Query et Scan |
`ReadRow`` ReadRows` (plage, préfixe, analyse inverse)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 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 application forcée au niveau de la table pour l'existence de colonnes ou les données de données. De même, une colonne ou un type de données d'attribut donnés peut différer d'une ligne. ou d'un élément à un autre. Toutefois, les API DynamoDB et Bigtable traitent avec les types de données de différentes manières.
Chaque requête d'écriture DynamoDB comprend une définition de type pour chaque attribut, qui est renvoyé avec la réponse aux requêtes de lecture.
Bigtable traite tout comme des octets et attend le code client de connaître le type et l'encodage afin que le client puisse analyser correctement les réponses. Il existe une exception : incrémenter qui interprètent les valeurs comme des entiers signés en mode big-endian de 64 bits.
Le tableau suivant compare les différences de types de données entre DynamoDB et Bigtable.
| DynamoDB | Bigtable |
|---|---|
| Types scalaires : renvoyés en tant que type de données de descripteur dans la réponse du serveur. | Octets : les octets sont convertis selon les types souhaités dans le client.
application. Increment interprète la valeur comme suit : Entier signé en mode big-endian de 64 bits |
| Ensemble : collection non triée d'images éléments. | Famille de colonnes : vous pouvez utiliser les qualificatifs de colonne tels qu'ils ont été définis. membres et pour chacun d’eux, fournissez un seul octet 0 comme la cellule . Les membres de l'ensemble sont triés de manière lexicographique dans leur colonne famille. |
| Mappage : collection non triée de paires clé-valeur avec clés uniques. | Famille de colonnes Utilisez le qualificatif de colonne comme clé de mappage et la valeur de la cellule. Mapper les clés sont triés de manière lexicographique. |
| Liste : collection triée d'éléments. | Qualificatif de colonne Utiliser l'horodatage d'insertion pour obtenir l'équivalent de la méthode "list_append" inverse du code temporel 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. Parmi les les principales différences entre Bigtable et DynamoDB sont 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 plus grande des
le "avant" et "après" même si la mise à jour concerne un sous-ensemble
les attributs de cet article. Cela signifie que dans DynamoDB, vous pouvez placer des mises à jour
colonnes dans des lignes séparées, même si elles appartiennent logiquement à la même ligne avec
d'autres colonnes.
Bigtable peut mettre à jour une cellule de manière aussi efficace, qu'il s'agisse de la une seule colonne dans une ligne donnée ou une seule colonne parmi plusieurs milliers. Pour en savoir plus, consultez Écritures simples.
Tri des données
DynamoDB hache et distribue les clés de partitionnement de façon aléatoire, alors que Bigtable stocke les lignes dans l'ordre lexicographique par clé de ligne le hachage reste à 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 de plages de lignes réactives, mais il crée des modèles d'accès qui impliquent des analyses traverser les limites de partition est coûteuse et inefficace. Ces analyses illimitées ce qui est fréquent, surtout pour les cas d'utilisation associés à une dimension temporelle.
Gestion de ce type de modèle d'accès : analyse cette partition limites — 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. ce qui nécessite une pagination au-delà de cette limite. Bigtable ne comporte aucun une telle limite.
Malgré ses clés de partitionnement distribuées de façon aléatoire, DynamoDB peut toujours avoir des partitions si une clé de partitionnement choisie ne répartit pas uniformément le trafic affecte négativement le débit. Pour résoudre ce problème, DynamoDB conseille write-sharding (segmentation logique) : répartit les écritures de manière aléatoire sur plusieurs partitions logiques clés-valeurs.
Pour appliquer ce modèle de conception, vous devez créer un nombre aléatoire à partir d'un nombre (par exemple, de 1 à 10), puis d'utiliser ce nombre comme partition logique . Comme la clé de partition est aléatoire, les écritures dans la table sont répartis uniformément sur toutes les valeurs de clé de partition.
Bigtable se réfère à cette procédure en tant que salage des clés et cela peut être un moyen efficace d'éviter les tablettes chaudes.
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 d'une colonne donnée. Un cas d'utilisation courant l'horodatage est la gestion des versions, c'est-à-dire l'écriture d'une nouvelle cellule dans une colonne se différencie des versions précédentes des données pour cette ligne et cette colonne par son du code temporel.
DynamoDB n’a pas ce
concept et nécessite
des conceptions de schémas complexes
pour la gestion des versions. Cette approche implique de créer deux copies de chaque élément:
Une copie commençant par zéro avec le préfixe du numéro de version (par exemple, v0_)
de la clé de tri, et une autre copie portant le préfixe de numéro de version 1, comme
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, puis copiez le contenu mis à jour dans l'élément
avec le préfixe de version zéro. Cela permet de s'assurer que la dernière version d'un élément
être localisé en utilisant
le préfixe zéro. Cette stratégie nécessite non seulement
la logique côté application à gérer, mais elle rend également les écritures de données très coûteuses et
Lenteur, car chaque écriture nécessite la lecture de la valeur précédente plus deux
les opérations d'écriture.
Transactions sur plusieurs lignes et grande capacité de lignes
Bigtable n'est pas compatible avec les transactions multilignes. Cependant, comme permet de stocker des lignes beaucoup plus volumineuses que les éléments DynamoDB, vous pouvez souvent obtenir la transactionnalité prévue en concevoir vos schémas pour regrouper les éléments pertinents sous une clé de ligne partagée. Pour une pour illustrer cette approche, reportez-vous à la section Conception d'une table unique schéma.
Stocker de grandes valeurs
Étant donné qu'un élément DynamoDB, qui est analogue à une ligne Bigtable, est limitée à 400 Ko, le stockage de grandes valeurs nécessite de diviser la valeur entre les articles ou le stockage dans d'autres supports comme S3 Les deux de ces approches ajoutent de la complexité à votre application. En revanche, Une cellule Bigtable peut stocker jusqu'à 100 Mo, et une instance Bigtable peut prendre en charge jusqu'à 256 Mo.
Exemples de traduction de schéma
Les exemples de cette section traduisent des schémas de DynamoDB en Bigtable en gardant à l'esprit les 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 | newsboy#brandB | Ajoutez une touche de charme vintage à votre look de tous les jours. | 25 | https://storage… |
| chaussures | sneakers#brandA | Sortez avec style et confort avec... | 40 | https://storage… |
| chaussures | sneakers#brandB | 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é composite Clé de ligne Bigtable. Vous créez une famille de colonnes (SKU) contenant le même ensemble de colonnes.
| SKU | |||
|---|---|---|---|
| Clé de ligne | Description | Prix | Thumbnail |
| hats#fedoras#brandA | Fabriqué à partir de laine de première qualité... | 30 | https://storage… |
| hats#fedoras#brandB | Toile résistante à l'eau et durable | 28 | https://storage… |
| hats#newsboy#brandB | 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 qui serait plusieurs tables dans une base de données relationnelle en une seule table dans DynamoDB. Vous pouvez adopter l'approche dans l'exemple précédent et dupliquer ce schéma tel quel Bigtable. Toutefois, il est préférable de résoudre les problèmes de schéma tout au long du processus.
Dans ce schéma, la clé de partitionnement contient l'ID unique d'une vidéo,
permet de colocaliser tous les attributs associés à la vidéo pour y accéder plus rapidement. Donnée
DynamoDB en raison des limites de taille des éléments, vous ne pouvez pas placer un nombre illimité de texte libre
commentaires sur une seule ligne. Par conséquent, une clé de tri avec le modèle
VideoComment#reverse-timestamp permet de définir chaque commentaire sur une ligne distincte.
dans la partition, triées 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 ce faire dans DynamoDB, vous devez analyser toutes les clés de cette partition et puis envoyez plusieurs demandes de suppression, en répétant chacune d'elles. DynamoDB prend en charge transactions multilignes, mais cette demande de suppression est trop volumineuse pour être effectuée en une seule fois 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'effectuer plus rapidement et à moindre coût. Les lignes Bigtable ont une taille supérieure à celle des éléments DynamoDB et peut gérer un grand nombre de commentaires. À gérer un cas où une vidéo reçoit des millions de commentaires, vous pouvez définir un message une règle de collecte pour ne conserver qu'une le nombre de commentaires les plus récents.
Comme les compteurs peuvent être mis à jour sans les frais généraux liés à la mise à jour de l'intégralité vous n'avez pas non plus besoin de les diviser. Il n'est pas nécessaire d'utiliser la propriété UploadDate. ou calculer un horodatage inversé et faire de cette clé de tri car les horodatages Bigtable donnent l'inverse chronologique les commentaires classés automatiquement. Cela simplifie considérablement le schéma, et si une vidéo est supprimée, vous pouvez supprimer la ligne correspondante de manière transactionnelle, y compris en une seule requête.
Enfin, comme les colonnes de Bigtable sont ordonnées lexicographique, en tant qu'optimisation, vous pouvez renommer les colonnes permet une analyse rapide, depuis les propriétés vidéo jusqu'aux N premiers éléments les plus récents commentaires : dans une seule requête de lecture, c'est ce que vous devez faire vidéo est chargée. Vous pourrez ensuite parcourir les autres commentaires comme que l'utilisateur fait 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 a souvent fait référence au modèle de conception de la 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":"12 rue des Champs-Élysées..."} |
||
| Payment-0789 | 2023-09-10T15:21:31 | {"amount_usd": 120, "bill_to":"Jane...", "address":"13 rue de la Libération..."} |
||
| 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 de la Libération..."} |
||
| Payment-0275 | 2023-09-09T10:11:03 | {"amount_usd": 70, "bill_to":"Kate...", "address":"21 rue des Champs-Élysées..."} |
||
Dans ce tableau, 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 colonnes dans Bigtable, avec des avantages semblables à titre d'exemple.
| 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":"Jean...", "address":"123 Abc St..."} @ 2023-09-10T15:21:40 |
{"amount_usd": 120, "bill_to":"Jane...", "address":"13 rue de la Libération..."} @ 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 rue des Champs-Élysées..."} @ 2023-09-09T10:11:03 |
{"amount_usd": 180, "bill_to":"Pierre...", "address":"321 rue Cba..."} @ 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 très performant de nombreux cas d'utilisation nécessitant des transactions sur plusieurs lignes coûteuses, l'indexation ou le comportement en cascade lors de la 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.