Bonnes pratiques liées à la conception de schémas

Cette page contient des informations sur la conception de schémas 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. Un schéma Bigtable est défini par la logique de l'application plutôt que par un objet ou un fichier de définition de schéma. Vous pouvez ajouter des familles de colonnes à une table lorsque vous la créez ou la mettez à jour, mais les colonnes et les modèles de clés de ligne sont définis par les données que vous écrivez dans la table.

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

Dans Bigtable, la conception du schéma est principalement déterminée par les requêtes, ou demandes de lecture, que vous prévoyez d'envoyer à la table. La lecture d'une plage de lignes étant le moyen le plus rapide de lire vos données Bigtable, les recommandations de cette page sont conçues pour vous aider à optimiser les lectures de plages de lignes. Dans la plupart des cas, cela signifie envoyer une requête basée sur des préfixes de clé de ligne.

Un autre point à prendre en compte est l'évitement des hotspots. Pour éviter les hotspots, vous devez tenir compte des schémas d'écriture et de la façon dont vous pouvez éviter d'accéder à un petit espace de clés en peu de temps.

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.
  • Les familles de colonnes agrégées contiennent des cellules agrégées. Vous pouvez créer des familles de colonnes qui ne contiennent que des cellules agrégées. Une agrégation vous permet de fusionner de nouvelles données avec celles déjà présentes dans la cellule.
  • Toutes les opérations sont atomiques au niveau des lignes. Une opération affecte soit une ligne entière, soit aucune des lignes.
  • 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.

Étant donné que toutes les tables d'une instance sont stockées sur les mêmes tablets, la conception de schéma générant des hotspots dans une table peut affecter la latence des autres tables de la même instance. Les hotspots sont causés par l'accès fréquent à une partie de la table sur une courte période.

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. 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 impose une limite de 1 000 tables par instance, mais nous vous recommandons d'éviter de créer un grand nombre de tables pour les raisons suivantes:

  • 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.
  • Créer davantage de tables n'améliore pas l'équilibrage de charge et peut augmenter les coûts de gestion.

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

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.

Vous pouvez également traiter 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 une famille de colonnes Friends. Chaque ligne représente une personne et toutes ses amitiés. Chaque qualificatif de colonne peut être l'ID d'un ami. La valeur de chaque colonne de cette ligne peut correspondre au cercle social auquel l'ami appartient. Dans cet exemple, les lignes peuvent se présenter comme suit:

Clé de ligne Fred Gabriel Hiroshi Seo Yoon Jakob
Jose club-de-lecture travail tennis
Sofia travail école club-échecs

Par opposition, un schéma pour les mêmes données n'utilisant pas de qualificatifs de colonne comme données et qui comporte les mêmes colonnes dans chaque ligne ressemble à ceci:

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

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

Si vous utilisez des qualificatifs de colonnes pour stocker des données, attribuez des qualificatifs courts, mais significatifs. Cette approche vous permet de réduire la quantité de données transférées pour chaque requête. La taille maximale est de 16 Ko.

Lignes

Limitez la taille de toutes les valeurs d'une seule ligne à 100 Mo. Assurez-vous que les données d'une seule ligne ne dépassent pas 256 Mo. 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 avez définie pour la famille de colonnes de cette colonne.

Utilisez des cellules agrégées pour stocker et mettre à jour des données agrégées. Si vous ne vous intéressez qu'à la valeur agrégée des événements pour une entité, comme la somme mensuelle des ventes par employé dans un magasin, vous pouvez utiliser des agrégats. Pour en savoir plus, consultez la section Agréger des valeurs au moment de l'écriture.

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 trier automatiquement les données selon les valeurs dont la cardinalité est la plus faible:

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        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. Ce modèle entraîne l'envoi des écritures séquentielles sur un seul nœud, ce qui crée un hotspot. Si vous spécifiez un horodatage dans une clé de ligne, faites-le précéder d'une valeur à cardinalité élevée telle qu'un ID utilisateur pour éviter la création de hotspots.

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. Une ligne peut également dépasser sa taille limite, car les valeurs précédentes d'une colonne occupent de l'espace jusqu'à ce que les cellules soient supprimées lors de 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 fréquemment, comme un compteur mis à jour des centaines de fois par minute, il est préférable de conserver les données en mémoire au niveau de la couche d'application et d'é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

Si vous récupérez souvent des données en fonction de l'heure à laquelle elles ont été enregistrées, vous pouvez inclure un code temporel dans votre clé de ligne.

Par exemple, vous pouvez avoir besoin d'enregistrer des données liées aux performances sur votre application, telles que les données d'utilisation de la mémoire ou du 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.

Si vous incluez des codes temporels dans la clé de ligne, n'utilisez pas un code temporel seul ou au début d'une clé de ligne. Ce modèle entraîne l'envoi des écritures séquentielles sur un seul nœud, ce qui crée un hotspot.

Si vous récupérez généralement les enregistrements les plus récents en premier dans vos requêtes, vous pouvez envisager d'utiliser des horodatages inversés dans la clé de ligne. Ce modèle permet de classer les lignes du plus récent au plus ancien, de sorte que les données les plus récentes soient placées plus haut dans le tableau. Comme pour tout code temporel, évitez de commencer une clé de ligne avec un code temporel inversé afin de ne pas créer de hotspots.

Vous pouvez obtenir un code temporel inversé en le soustrayant de la valeur maximale de votre langage de programmation pour les entiers longs (java.lang.Long.MAX_VALUE en Java).

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.

Confidentialité

À 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 valeurs des clés de ligne et des familles de colonnes sont à la fois des données client et des données de service. Les applications qui les utilisent, comme le chiffrement ou la journalisation, peuvent les exposer par inadvertance à des utilisateurs qui ne devraient pas avoir accès à des données privées.

Pour en savoir plus sur le traitement des données de service, consultez l'Avis de confidentialité de Google Cloud.

Noms de domaine

Vous pouvez stocker des noms de domaine en tant que données Bigtable.

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 un fichier 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