Concevoir un schéma

Cette page contient des informations sur la conception de schémas Cloud Bigtable. Avant de lire cette page, vous devez avoir lu la présentation de Bigtable. Cette page traite des sujets suivants :

  • Concepts généraux : concepts de base à prendre en compte lorsque vous concevez votre schéma.
  • Bonnes pratiques : consignes de conception qui s'appliquent à la plupart des cas d'utilisation, réparties par composant de table.
  • Cas d'utilisation spéciaux : recommandations pour certains cas d'utilisation et modèles de données spécifiques.

Concepts généraux

La conception d'un schéma Bigtable est différente de celle d'un schéma pour une base de données relationnelle. Dans Bigtable, un schéma est un plan ou un modèle d'une table, qui comprend la structure des composants de table suivants:

  • Clés de ligne
  • Familles de colonnes, y compris leurs stratégies de récupération de mémoire
  • Colonnes

Les concepts généraux suivants s'appliquent à la conception de schéma Bigtable :

  • Bigtable est un espace de stockage de paires clé/valeur, et non un espace de stockage relationnel. Il n'accepte pas les jointures, et les transactions ne sont possibles qu'au sein d'une même ligne.
  • Chaque table ne contient qu'un seul index, la clé de ligne. Aucun index secondaire n'est disponible. Chaque clé de ligne doit être unique.
  • Les lignes sont triées de façon lexicographique par clé de ligne, de la chaîne d'octets la plus basse à la plus élevée. Les clés de ligne sont triées par ordre d'octets en mode big-endian (parfois appelé ordre d'octets du réseau), l'équivalent binaire de l'ordre alphabétique.
  • Les familles de colonnes ne sont pas stockées dans un ordre spécifique.
  • Les colonnes sont regroupées par famille de colonnes et triées par ordre lexicographique au sein de la famille de colonnes. Par exemple, dans une famille de colonnes appelée SysMonitor et utilisant les qualificatifs de colonne ProcessName, User, %CPU, ID, Memory, DiskRead etPriority, Bigtable stocke les colonnes dans l'ordre suivant :
SysMonitor
%CPU DiskRead ID Memory Priority ProcessName User
  • L'intersection d'une ligne et d'une colonne peut contenir plusieurs cellules horodatées. Chaque cellule contient une version unique et horodatée des données pour cette ligne et cette colonne.
  • Toutes les opérations sont atomiques au niveau des lignes. Cela signifie qu'une opération affecte soit une ligne entière, soit aucune ligne.
  • Dans l'idéal, les lectures et les écritures doivent être réparties uniformément sur les lignes d'une table.

  • Les tables Bigtable sont creuses. Une colonne n'occupe pas d'espace dans une ligne qui n'utilise pas la colonne.

Bonnes pratiques

Un schéma efficace entraîne des performances et une évolutivité excellentes, tandis qu'un mauvais schéma peut conduire à un système peu performant. Chaque cas d'utilisation est différent et nécessite sa propre conception, mais les bonnes pratiques suivantes s'appliquent à la plupart des cas d'utilisation. Les exceptions sont indiquées.

Les sections suivantes, qui commencent par le niveau de la table pour finir au niveau de la clé de ligne, décrivent les bonnes pratiques de conception de schéma :

Tous les éléments de table, en particulier les clés de ligne, doivent être conçus dans l'optique les requêtes de lecture planifiées. Consultez les quotas et limites pour connaître les limites de taille recommandée et maximale pour tous les éléments de base de données.

Tables

Stockez des ensembles de données reposant sur des schémas similaires dans une même table plutôt que dans des tables distinctes.

Avec d'autres systèmes de base de données, vous pouvez choisir de stocker les données dans plusieurs tables, suivant le sujet et le nombre de colonnes. En revanche, dans Bigtable, il est généralement préférable de stocker toutes vos données dans une seule et même table de grande taille. Vous pouvez attribuer un préfixe de clé de ligne unique à utiliser pour chaque ensemble de données, afin que Bigtable stocke les données associées dans une plage de lignes contiguës que vous pouvez ensuite interroger par préfixe de clé de ligne.

Bigtable a une limite de 1 000 tables par instance, mais dans la plupart des cas, vous devriez avoir un nombre de tables beaucoup moins élevé. Créer de nombreuses petites tables est un anti-modèle pour Bigtable, et ce pour plusieurs raisons :

  • L'envoi de requêtes à plusieurs tables distinctes peut augmenter la charge de connexion au niveau du backend et accroître la latence de queue.
  • Un grand nombre de tables de différentes tailles peut perturber l'équilibrage de charge, lequel intervient en arrière-plan pour optimiser les performances de Bigtable.

Il peut être justifié de vouloir une table distincte pour un cas d'utilisation spécifique nécessitant un schéma complètement différent, mais vous devez généralement éviter d'utiliser des tables distinctes pour des données similaires. Par exemple, ne créez pas de table parce qu'une nouvelle année vient de commencer ou que vous avez décroché un nouveau client.

Familles de colonnes

Placez les colonnes associées dans la même famille de colonnes. Lorsqu'une ligne contient plusieurs valeurs liées les unes aux autres, il est recommandé de regrouper les colonnes contenant ces valeurs dans la même famille de colonnes. Regroupez les données le plus près possible pour éviter de concevoir des filtres complexes. Vous obtenez ainsi les informations dont vous avez besoin, mais pas plus, dans vos requêtes de lecture les plus fréquentes.

Créez au maximum 100 familles de colonnes par table. Créer plus de 100 familles de colonnes peut entraîner une dégradation des performances.

Choisissez des noms courts, mais explicites, pour vos familles de colonnes. Ces noms sont inclus dans les données transférées pour chaque requête.

Placez les colonnes qui ont des contraintes de conservation de données différentes dans des familles de colonnes différentes. Cela permet de limiter les coûts de stockage. Les stratégies de récupération de mémoire sont définies au niveau de la famille de colonnes, et non au niveau de la colonne. Par exemple, si vous ne devez conserver que la version la plus récente d'un élément de données particulier, ne stockez pas cet élément dans une famille de colonnes définie pour stocker 1 000 versions d'un autre élément. Sinon, vous payez pour stocker 999 cellules de données dont vous n'avez pas besoin.

Colonnes

Traitez les qualificatifs de colonne comme des données. Étant donné que vous devez stocker un qualificatif de colonne pour chaque colonne, vous pouvez économiser de l'espace en renommant la colonne avec une valeur. Prenons l'exemple d'une table qui stocke des données sur l'amitié, dans laquelle chaque ligne représente une personne et toutes ses amitiés. Chaque qualificatif de colonne peut correspondre à l'ID d'un ami. La valeur de cette colonne dans cette ligne peut correspondre au cercle social auquel l'ami appartient. Dans cet exemple, les lignes peuvent ressembler à ceci:

José Fred:club-de-lecture Gabriel:travail Hiroshi:tennis
Sofia Hiroshi:travail Seo Yoon:école Jakob:club-échecs

Par opposition, un schéma pour les mêmes données n'utilisant pas de qualificatifs de colonne comme données ressemble à ceci :

José#1 Ami:Fred Cercle:club-de-lecture
José#2 Ami:Gabriel Cercle:travail
José#3 Ami:Hiroshi Cercle:tennis
Sofia#1 Ami:Hiroshi Cercle:travail
Sofia#2 Ami:Seo Yoon Cercle:école
Sofia# Ami:Jakob Cercle:club-échecs

La deuxième conception de schéma entraîne une augmentation beaucoup plus rapide de la taille de la table.

Si vous n'utilisez pas les qualificatifs de colonnes pour stocker des données et que vous souhaitez réduire la quantité de données transférées pour chaque requête, utilisez des qualificatifs de colonnes courts, mais significatifs. La taille maximale est de 16 Ko.

Créez autant de colonnes que nécessaire dans la table. Les tables Bigtable ne sont que partiellement remplies (données éparses) et aucune pénalité d'espace n'est appliquée pour une colonne qui n'est pas utilisée sur une ligne. Une table peut contenir des millions de colonnes, à condition qu'aucune ligne ne dépasse la limite maximale de 256 Mo.

Évitez d'utiliser trop de colonnes sur une même ligne. Même si une table peut contenir des millions de colonnes, cela est déconseillé au niveau d'une ligne. Plusieurs raisons justifient la mise en œuvre de cette bonne pratique :

  • Bigtable prend du temps pour traiter chaque cellule d'une ligne.
  • Chaque cellule ajoutée augmente le volume de données stocké dans la table et envoyé via le réseau. Par exemple, si vous stockez 1 Ko (1 024 octets) de données, il est beaucoup plus économe en espace de stocker ces données dans une seule cellule plutôt que de répartir les données sur 1 024 cellules contenant chacune 1 octet.

Si votre ensemble de données nécessite logiquement plus de colonnes par ligne que ce que Bigtable peut traiter efficacement, envisagez de stocker les données sous forme de tampon de protocole (protobuf) dans une seule colonne.

Rows (Lignes)

Ne stockez pas plus de 100 Mo de données sur une seule ligne. Les lignes qui dépassent cette limite peuvent avoir une incidence sur les performances de lecture.

Conservez toutes les informations relatives à une entité sur une seule et même ligne. Dans la plupart des cas, évitez de stocker des données que vous devez lire de manière atomique (ou toutes en une seule fois) sur plus d'une ligne afin d'éviter toute incohérence. Par exemple, si vous mettez à jour deux lignes d'une table, il se peut que l'une d'elles soit bien mise à jour et que la mise à jour de l'autre ligne échoue. Assurez-vous que votre schéma ne nécessite pas la mise à jour simultanée de plusieurs lignes pour garantir l'exactitude des données liées. Vous avez ainsi l'assurance que si une partie d'une requête d'écriture échoue ou doit être à nouveau envoyée, les données concernées ne sont pas temporairement incomplètes.

Exception : Si le fait de conserver une entité dans une seule ligne génère une ligne de plusieurs centaines de Mo, vous devez répartir les données sur plusieurs lignes.

Stockez les entités liées dans des lignes adjacentes pour améliorer l'efficacité des lectures.

Cellules

Ne stockez pas plus de 10 Mo de données dans une même cellule. Rappelez-vous qu'une cellule contient les données stockées avec un horodatage unique pour une ligne et une colonne données, et que plusieurs cellules peuvent être stockées à l'intersection de cette ligne et de cette colonne. Le nombre de cellules conservées dans une colonne est régi par la stratégie de récupération de mémoire que vous définissez pour la famille de colonnes de cette colonne.

Clés de ligne

Concevez votre clé de ligne en fonction des requêtes que vous prévoyez d'utiliser pour récupérer les données. Des clés de ligne bien conçues permettent d'exploiter pleinement les capacités de Bigtable. Les requêtes Bigtable les plus efficaces récupèrent des données à l'aide de l'une des méthodes suivantes:

  • Clé de ligne
  • Préfixe de clé de ligne
  • Plage de lignes définie par les clés de ligne de début et de fin

D'autres types de requêtes déclenchent une analyse complète de la table, mais cette pratique est beaucoup moins efficace. Choisissez dès maintenant la clé de ligne appropriée pour éviter d'avoir à effectuer un processus de migration de données laborieux ultérieurement.

Veillez à utiliser des clés de ligne de petite taille. Une clé de ligne ne doit pas dépasser 4 Ko. Les longues clés de ligne occupent davantage de mémoire et de stockage, et augmentent le temps nécessaire pour obtenir des réponses du serveur Bigtable.

Stockez plusieurs valeurs délimitées dans chaque clé de ligne. Étant donné que le meilleur moyen d'interroger efficacement Bigtable est d'utiliser la clé de ligne, il est souvent utile d'inclure plusieurs identifiants dans une clé de ligne. Lorsque votre clé de ligne inclut plusieurs valeurs, il est particulièrement important de bien comprendre comment vous allez utiliser vos données.

Les segments de clé de ligne sont généralement séparés par un délimiteur (deux-points, barre oblique ou symbole de hachage, par exemple). Le premier segment ou ensemble de segments contigus est le préfixe de clé de ligne, et le dernier segment ou ensemble de segments contigus correspond au suffixe de clé de ligne.

Exemple de clé de ligne

Des préfixes de clé de ligne bien planifiés vous permettent de profiter de l'ordre de tri intégré à Bigtable pour stocker des données connexes dans des lignes contiguës. Le stockage de données connexes dans des lignes contiguës vous permet d'accéder aux plages de lignes regroupant ces données, plutôt que d'exécuter des analyses inefficaces à l'échelle de la table.

Si vos données incluent des entiers que vous souhaitez stocker ou trier numériquement, ajoutez des zéros avant ces entiers. Bigtable stocke les données de manière lexicographique. À titre d'exemple, d'un point de vue lexicographique, 3 > 20, mais 20 > 03. Si vous ajoutez un zéro devant le chiffre 3, les nombres sont triés par ordre numérique. Cette approche est importante en ce qui concerne les horodatages pour lesquels vous souhaitez effectuer des requêtes basées sur une plage.

Il est important de créer une clé de ligne permettant de récupérer une plage de lignes bien définie. Sinon, votre requête requiert une analyse de table, qui est beaucoup plus lente que la récupération de lignes spécifiques.

Par exemple, si votre application effectue le suivi de données d'appareils mobiles, vous pouvez créer une clé de ligne composée du type d'appareil, de l'ID d'appareil et du jour où les données sont enregistrées. Les clés de ligne pour ces données peuvent se présenter comme suit :

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

Cette conception de clé de ligne vous permet de récupérer, via une requête unique, des données pour :

  • Un type d'appareil
  • La combinaison d'un type d'appareil et d'un ID d'appareil

Cette conception de clé de ligne n'est pas optimale si vous souhaitez récupérer toutes les données pour un jour spécifique. Étant donné que le jour est stocké dans le troisième segment (ou dans le suffixe de clé de ligne), il ne suffit pas d'effectuer une requête sur une plage de lignes en fonction du suffixe ou d'un segment médian de la clé de ligne. Au lieu de cela, vous devez envoyer une requête de lecture avec un filtre qui analyse l'ensemble de la table à la recherche de la valeur "jour".

Dans la mesure du possible, utilisez des valeurs de chaîne lisibles dans vos clés de ligne. Cette pratique vous permet d'utiliser plus facilement l'outil Key Visualizer par la suite pour résoudre les problèmes liés à Bigtable.

Dans de nombreux cas, vous devez concevoir des clés de ligne qui commencent par une valeur courante et se terminent par une valeur plus précise. Par exemple, si votre clé de ligne inclut un continent, un pays et une ville, vous pouvez créer des clés de ligne semblables à celles présentées ci-après afin de pouvoir, en premier lieu, trier automatiquement les données selon les valeurs dont la cardinalité est la plus faible :

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#okinawa
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

Clés de ligne à éviter

Certains types de clés de ligne peuvent entraver l'interrogation de vos données, ou encore entraîner de mauvaises performances. Cette section décrit certains types de clés de ligne que vous devez éviter d'utiliser dans Bigtable.

Clés de ligne qui commencent par un horodatage. Les écritures séquentielles seront envoyées sur un seul nœud, créant un hotspot. Si vous spécifiez un horodatage dans une clé de ligne, vous devez le faire précéder par une valeur à cardinalité élevée (un ID utilisateur, par exemple) afin d'éviter le hotspotting.

Clés de ligne empêchant le regroupement des données connexes. Évitez les clés de ligne qui stockent les données connexes dans des plages de lignes non contiguës, qui ne peuvent pas facilement être lues ensemble.

ID numériques séquentiels. Supposons que votre système attribue un ID numérique à chacun des utilisateurs de votre application. Vous pourriez être tenté de définir l'ID numérique de l'utilisateur comme clé de ligne pour votre table. Cependant, étant donné que les nouveaux utilisateurs sont plus susceptibles d'être des utilisateurs actifs, cette approche pourrait transférer la majeure partie de votre trafic vers un petit nombre de nœuds.

Une approche plus sûre consiste à utiliser une version inversée de l'ID numérique de l'utilisateur, qui répartit le trafic de manière plus uniforme sur tous les nœuds de la table Bigtable.

Identifiants fréquemment mis à jour. Évitez d'utiliser une seule clé de ligne pour identifier une valeur qui doit être mise à jour très fréquemment. Par exemple, si vous stockez des données d'utilisation de la mémoire pour un certain nombre d'appareils une fois par seconde, n'utilisez pas pour chaque appareil une clé de ligne unique composée de l'ID d'appareil et de la métrique que vous consignez (4c410523#memusage, par exemple) et ne mettez pas à jour la ligne de façon répétée. Ce type d'opération surcharge le tablet où est stockée la ligne fréquemment utilisée. Cela peut également entraîner le dépassement de la limite de taille d'une ligne, car les valeurs précédentes d'une colonne occupent de l'espace jusqu'à la récupération de mémoire.

Stockez plutôt chaque nouvelle lecture sur une nouvelle ligne. Dans l'exemple d'utilisation de mémoire, chaque clé de ligne peut contenir l'ID de l'appareil, le type de métrique et un horodatage. Les clés de ligne sont donc semblables à 4c410523#memusage#1423523569918. Cette stratégie est efficace, car la création d'une ligne dans Bigtable ne prend pas plus de temps que de créer une cellule. En outre, cette stratégie vous permet de lire rapidement les données d'une plage de dates spécifique en calculant les clés de début et de fin appropriées.

Pour les valeurs qui varient très fréquemment, comme un compteur mis à jour des centaines de fois par minute, il vaut mieux conserver les données en mémoire au niveau de la couche d'application et écrire régulièrement de nouvelles lignes dans Bigtable.

Valeurs hachées. Le hachage d'une clé de ligne ne permet pas d'exploiter l'ordre de tri naturel de Bigtable, ce qui vous empêche de stocker des lignes de manière optimale pour l'interrogation. Pour la même raison, le hachage des valeurs complique l'utilisation de l'outil Key Visualizer pour la résolution des problèmes liés à Bigtable. Utilisez des valeurs dans un format lisible plutôt que des valeurs hachées.

Valeurs exprimées sous forme d'octets bruts plutôt que de chaînes lisibles. Les octets bruts conviennent pour les valeurs des colonnes, mais pour des raisons de lisibilité et de dépannage, utilisez des valeurs de chaîne dans les clés de ligne.

Cas d'utilisation spéciaux

Vous pouvez disposer d'un ensemble de données unique, nécessitant une attention toute particulière lorsque vous concevez un schéma pour le stocker dans Bigtable. Cette section décrit certains types de données Bigtable, ainsi que certaines tactiques recommandées pour les stocker de manière optimale.

Données temporelles

Incluez un horodatage dans votre clé de ligne si vous devez souvent récupérer des données en fonction de l'heure à laquelle elles ont été enregistrées.

Par exemple, vous pouvez avoir besoin d'enregistrer des données relatives aux performances sur votre application, telles que les données d'utilisation de mémoire ou de processeur, une fois par seconde pour un grand nombre de machines. Votre clé de ligne pour ces données peut associer un identifiant de machine à un horodatage des données (par exemple, machine_4223421#1425330757685). N'oubliez pas que les clés de ligne sont triées de manière lexicographique.

N'utilisez pas un horodatage seul ou au début d'une clé de ligne, car cela entraîne l'envoi des écritures séquentielles sur un nœud unique et la création d'un hotspot.

Si vous récupérez généralement les enregistrements les plus récents en premier, vous pouvez utiliser un horodatage inversé dans la clé de ligne en le soustrayant de la valeur maximale des entiers longs dans votre langage de programmation (en Java, java.lang.Long.MAX_VALUE). Grâce à l'horodatage inversé, les enregistrements sont classés du plus récent au plus ancien.

Pour en savoir plus sur l'utilisation des données de séries temporelles, consultez la section Conception de schéma pour les données de séries temporelles.

Architecture mutualisée

Les préfixes de clé de ligne constituent une solution évolutive pour un cas d'utilisation en "architecture mutualisée", un scénario dans lequel vous stockez des données similaires, à l'aide du même modèle de données, pour le compte de plusieurs clients. L'utilisation d'une table unique pour tous les locataires est généralement le moyen le plus efficace pour stocker des données d'architecture mutualisée et y accéder.

Par exemple, supposons que vous stockiez et suiviez des historiques d'achats pour le compte de nombreuses entreprises. Vous pouvez utiliser l'identifiant unique que vous attribuez à chaque entreprise en tant que préfixe de clé de ligne. Toutes les données d'un locataire sont stockées dans des lignes contiguës de la même table, et vous pouvez interroger ou filtrer ces données à l'aide du préfixe de clé de ligne. Ainsi, lorsqu'une entreprise n'est plus votre client et que vous devez supprimer les données d'historique d'achats qui lui sont associées, vous pouvez supprimer la plage de lignes utilisant le préfixe de clé de ligne associé à ce client.

Par exemple, si vous stockez des données relatives aux téléphones mobiles pour les clients altostrat et examplepetstore, vous pouvez créer des clés de ligne comme celles présentées ci-dessous. Ensuite, une fois que altostrat ne fait plus partie de vos clients, vous pouvez supprimer toutes les lignes avec le préfixe de clé de ligne altostrat.

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

En revanche, si vous stockez les données de chaque entreprise dans une table dédiée, vous rencontrerez davantage de problèmes de performances et d'évolutivité. Vous risquez également de dépasser par inadvertance la limite de 1 000 tables par instance imposée par Bigtable. Lorsqu'une instance atteint cette limite, Bigtable ne vous autorise pas à créer d'autres tables au sein de l'instance.

Vie privée

À moins que votre cas d'utilisation ne le nécessite, évitez d'utiliser des informations personnelles ou des données utilisateur dans des clés de ligne ou des ID de famille de colonnes. Les clés de ligne et les familles de colonnes sont à la fois des données et des métadonnées. Les applications qui les utilisent comme métadonnées, telles que les outils de chiffrement et de journalisation, peuvent les exposer par inadvertance à des utilisateurs qui ne devraient pas avoir accès à des données privées.

Noms de domaine

Large éventail de noms de domaine

Si vous stockez des données sur des entités qui peuvent être représentées sous la forme de noms de domaine, vous pouvez définir un nom de domaine inversé (par exemple, com.company.product) comme clé de ligne. Cette pratique est spécialement recommandée si les données de chaque ligne ont tendance à chevaucher celles des lignes adjacentes. Dans ce cas, Bigtable peut compresser vos données plus efficacement.

Notez qu'à l'inverse, si vous utilisez des noms de domaine standards non inversés, les lignes sont triées de telle manière que les données associées ne sont pas regroupées au même endroit, ce qui peut altérer la compression et rendre les lectures moins efficaces.

Cette approche fonctionne mieux lorsque vos données sont réparties sur plusieurs noms de domaine inversés.

Pour illustrer ce point, considérons les noms de domaine suivants, triés automatiquement par ordre lexicographique par Bigtable :

      drive.google.com
      en.wikipedia.org
      maps.google.com

Cela n'est pas souhaitable pour le cas d'utilisation dans lequel vous souhaitez interroger toutes les lignes pour le domaine google.com. Par comparaison, considérons maintenant les mêmes lignes, mais avec des noms de domaine inversés :

      com.google.drive
      com.google.maps
      org.wikipedia.en

Dans ce deuxième exemple, les lignes associées sont automatiquement triées de manière à ce que l'on puisse les récupérer facilement sous la forme d'une plage de lignes.

Nombre limité de noms de domaine

Si vous prévoyez de stocker une grande quantité de données pour un seul nom de domaine ou un nombre limité de noms de domaine, envisagez d'autres valeurs pour votre clé de ligne. Vous avez également la possibilité de transférer des écritures sur un seul nœud de votre cluster, ce qui peut entraîner un phénomène de hotspotting ou allonger considérablement la taille des lignes.

Requêtes changeantes ou incertaines

Si vous n'exécutez pas toujours les mêmes requêtes sur vos données, ou si vous n'êtes pas sûr de la nature de vos futures requêtes, vous pouvez stocker toutes les données d'une ligne dans une colonne plutôt que dans plusieurs colonnes. Avec cette approche, vous utilisez un format qui facilite l'extraction ultérieure des valeurs individuelles, comme le format binaire du tampon de protocole ou JSON.

La clé de ligne est toujours conçue pour vous permettre de récupérer les données dont vous avez besoin, mais chaque ligne ne contient généralement qu'une colonne, laquelle réunit toutes les données de la ligne dans un même protobuf.

Le fait de stocker des données sous la forme d'un message protobuf dans une colonne au lieu de les répartir dans plusieurs colonnes présente des avantages et des inconvénients. Les avantages sont les suivants :

  • Les données occupent moins d'espace, leur stockage vous coûte donc moins cher.
  • Vous conservez une certaine flexibilité car vous n'avez pas à vous conformer à des familles de colonnes et des qualificatifs de colonnes prédéterminés.
  • Votre application de lecture n'a pas besoin de "comprendre" le schéma de votre table.

Cette approche a toutefois des inconvénients :

  • Vous devez désérialiser les messages protobuf après leur lecture depuis Bigtable.
  • Vous perdez la possibilité d'interroger les données dans les messages protobuf à l'aide de filtres.
  • Vous ne pouvez pas utiliser BigQuery pour exécuter des requêtes fédérées sur des champs au sein des messages protobuf après avoir lu ces derniers depuis Bigtable.

Étape suivante