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

Cette page contient des informations sur la conception d'un schéma Bigtable. Avant de lire cette page, vous devez avoir pris connaissance de 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 la conception d'un schéma pour une base de données relationnelle. Un schéma Bigtable est défini par la logique d'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 de table comprenant 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 régie par les requêtes, ou requêtes de lecture, que vous prévoyez d'envoyer à la table. Étant donné que la lecture d'une plage de lignes est 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 les préfixes de clé de ligne.

Autre considération à prendre en compte : éviter les hotspots. Pour éviter cela, vous devez prendre en compte des modèles d'écriture et savoir comment é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. Il n'y a pas d'index secondaires. 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 des 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 Priorité ProcessName User
  • L'intersection d'une ligne et d'une colonne peut contenir plusieurs cellules horodatées. Chaque cellule contient une version horodatée unique des données pour cette ligne et cette colonne.
  • Les familles de colonnes d'agrégation contiennent des cellules agrégées. Vous pouvez créer des familles de colonnes ne contenant que des cellules agrégées. Un agrégat vous permet de fusionner de nouvelles données avec des données 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 ligne.
  • Dans l'idéal, les lectures et les écritures doivent être réparties uniformément sur l'espace de 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 dus au fait d'accéder fréquemment à une partie de la table dans un court laps de temps.

Tables

Stockez les ensembles de données avec des schémas similaires dans la 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 à chaque ensemble de données, afin que Bigtable stocke les données associées dans une plage contiguë de lignes que vous pouvez ensuite interroger par préfixe de clé de ligne.

Bigtable est limité à 1 000 tables par instance, mais il est généralement préférable d'avoir beaucoup moins de tables. Évitez 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.
  • 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.

Vous pouvez à juste titre avoir besoin d'une table distincte pour un cas d'utilisation différent nécessitant un schéma différent, mais vous ne devez pas utiliser de tables distinctes pour des données similaires. Par exemple, vous ne devez pas créer de table parce que c'est une nouvelle année ou parce que vous avez 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. Les 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'une donnée particulière, ne la stockez pas dans une famille de colonnes configurée pour stocker 1 000 versions d'une autre donnée. Sinon, vous payez pour stocker 999 cellules de données dont vous n'avez pas besoin.

Colonnes

(Facultatif) 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 lui attribuant une valeur. Prenons l'exemple d'une table qui stocke des données sur les amitiés dans une famille de colonnes Friends. Chaque ligne représente une personne et toutes ses amitiés. Chaque qualificatif de colonne peut correspondre à l'ID d'un ami. Ensuite, la valeur de chaque colonne de cette ligne peut être le cercle social dans lequel se trouve l'ami. Dans cet exemple, les lignes peuvent se présenter comme suit:

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

Comparez ce schéma à un schéma pour les mêmes données qui ne traite pas les qualificatifs de colonne comme des données, et qui comporte les mêmes colonnes sur chaque ligne:

Clé de ligne Qualificatif de colonne:valeur Qualificatif de colonne:valeur
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 n° 3 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 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.

Créez autant de colonnes que nécessaire dans la table. Les tables Bigtable sont creuses, et il n'y a pas de pénalité d'espace pour une colonne qui n'est pas utilisée dans 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. Une table peut comporter des millions de colonnes, mais pas une ligne. Plusieurs facteurs contribuent à cette bonne pratique:

  • Bigtable prend du temps pour traiter chaque cellule d'une ligne.
  • Chaque cellule augmente la quantité de données stockées dans votre table et envoyées sur 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 les répartir sur 1 024 cellules contenant chacune un 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.

Lignes

La taille de toutes les valeurs d'une seule ligne doit être inférieure à 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 réduire les performances de lecture.

Conservez toutes les informations relatives à une entité sur une seule et même ligne. Dans la plupart des cas d'utilisation, évitez de stocker des données que vous devez lire de manière atomique ou globale sur plusieurs lignes pour éviter les incohérences. 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. Cette pratique garantit que si une partie d'une requête d'écriture échoue ou doit être envoyée à nouveau, cette donnée n'est pas temporairement incomplète.

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 seule cellule. Rappelez-vous qu'une cellule est les données stockées pour une ligne et une colonne données avec un horodatage unique, 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.

Stocker et mettre à jour les données globales à l'aide de cellules agrégées. Si vous ne vous souciez que de la valeur agrégée des événements d'une entité, telle que la somme mensuelle des ventes par employé dans un magasin de détail, vous pouvez utiliser des agrégations. Pour en savoir plus, consultez la section Valeurs agrégées au moment de l'écriture (Aperçu).

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

Souvent, vous devez concevoir des clés de ligne qui commencent par une valeur commune et se terminent par une valeur 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 ressemblant à ce qui suit afin qu'elles soient automatiquement triées en premier selon les valeurs à cardinalité inférieure:

        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 ajoutez un code temporel dans une clé de ligne, faites-le précéder d'une valeur à cardinalité élevée, comme un ID utilisateur, pour éviter les hotspots.

Clés de ligne empêchant le regroupement des données connexes. Évitez les clés de ligne qui entraînent le stockage de données associées dans des plages de lignes non contiguës, qui ne peuvent pas ê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 une seule clé de ligne pour chaque appareil composé de l'ID de l'appareil et de la métrique stockée, telle que 4c410523#memusage, et ne mettez pas à jour la ligne à plusieurs reprises. Ce type d'opération surcharge la tablette qui stocke 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'à 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 dans Bigtable, la création d'une ligne ne prend pas plus de temps que la création d'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 changent 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 résoudre les 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 récupérez souvent des données en fonction de l'heure à laquelle elles ont été enregistrées.

Par exemple, votre application peut enregistrer des données liées aux performances, telles que l'utilisation du processeur et de la mémoire, une fois par seconde pour de nombreuses machines. La clé de ligne de ces données peut combiner un identifiant de la machine et un horodatage des données (par exemple, machine_4223421#1425330757685). N'oubliez pas que les clés de ligne sont triées par ordre lexicographique.

N'utilisez pas d'horodatage seul ou au début d'une clé de ligne, car cela entraînerait le transfert d'écritures séquentielles sur un seul nœud, ce qui créerait un hotspot. Dans ce cas, vous devez tenir compte des modèles d'écriture et de lecture.

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émas 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 le moyen le plus efficace de stocker et d'accéder aux données mutualisées.

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. Ensuite, lorsqu'une entreprise n'est plus votre client et que vous devez supprimer les données de l'historique des achats que vous stockiez pour elle, vous pouvez supprimer la plage de lignes qui utilisent le préfixe de clé de ligne de 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é

Sauf si votre cas d'utilisation l'exige, évitez d'utiliser des informations permettant d'identifier personnellement l'utilisateur ou des données utilisateur dans les clés de ligne ou les 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, telles que 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

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. Sinon, vous risquez de transférer les écritures sur un seul nœud de votre cluster, ce qui générerait des hotspots, ou vos lignes pourraient devenir trop volumineuses.

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 savoir quelles seront vos requêtes, une option consiste à 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, tel que le format binaire de 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.

Étapes suivantes