Cette page a été traduite par l'API Cloud Translation.

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. Les sujets suivants sont abordés dans ce :

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 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 à un tableau lorsque vous le créez ou le mettez à jour, mais les colonnes et les modèles de clé de ligne sont définis par les données que vous écrivez dans la table.

Dans Bigtable, un schéma est un plan modèle de table, y compris la structure des composants 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 implique d'envoyer une requête en fonction des préfixes de clé de ligne.

Autre considération à prendre en compte : éviter les hotspots : pour éviter les hotspots, vous devez réfléchir aux modèles d'écriture et à la manière dont vous pouvez éviter d'accéder à une petite clé 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'accès secondaire index. 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	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. Un agrégat vous permet fusionner les 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 d’un espace de lignes d’un tableau.
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 :

Tables
Familles de colonnes
Colonnes
Lignes
Cellules
Clés de ligne

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 à un accès fréquent à une partie de la table dans une sur une courte période.

Tables

Stockez les ensembles de données ayant des schémas similaires dans la même table, plutôt que dans des tableaux distincts.

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.

Vous pourriez justement vouloir une table distincte pour un autre cas d'utilisation nécessite un schéma différent, mais vous ne devez pas utiliser de tables distinctes pour des données. 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 n'avez besoin de conserver que la version la plus récente une donnée particulière, ne la stockez pas dans une famille de colonnes définie pour stocker 1 000 versions d'autre chose. 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 contenant des millions de colonnes, alors qu'une ligne ne devrait pas l'être. Plusieurs raisons justifient la mise en œuvre de cette bonne pratique :

Bigtable prend du temps pour traiter chaque cellule d'une ligne.
Chaque cellule ajoute une surcharge à la quantité de données stockées dans votre et envoyées sur le réseau. Par exemple, si vous stockez 1 Ko (1 024 octets) de données, il est beaucoup plus efficace de stocker ces données dans un une seule cellule, au lieu de répartir les données sur 1 024 cellules qui chacune contient 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 des amitiés. Chaque qualificatif de colonne peut être l'ID d'un ami. La valeur de chaque colonne de cette ligne peut être le cercle de contacts dans lequel se trouve l’ami. 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 ne considérant pas les qualificatifs de colonne comme des 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 d'é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. Si les lignes dépassent cette limite, des performances de lecture réduites.

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 atomiquement, ou toutes en même temps, dans plus de une ligne 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. 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 correspond aux données stockées pour une ligne et une colonne données avec une un horodatage unique, et que plusieurs cellules peuvent être stockées à l'intersection de cette ligne et 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 des données globales à l'aide de cellules 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 plus pour plus d'informations, consultez la section Valeurs agrégées 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 la clé de ligne préfixe, et le dernier segment ou ensemble de segments contigus est la 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 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 placez un code temporel dans une clé de ligne, faites-la 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 les données connexes sont stockées dans des plages de lignes non contiguës, inefficaces à lire 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 aussi entraîner ligne dépasse sa limite de taille, 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 changent fréquemment, comme un compteur qui est mis à jour des centaines de fois par minute, il est préférable de garder les données en mémoire, au couche application et écriture de lignes dans Bigtable régulièrement.

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 rend difficile 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 code temporel dans votre clé de ligne si vous récupérez souvent des données en fonction au moment de l'enregistrement.

Par exemple, votre application peut enregistrer des données liées aux performances, telles que et l'utilisation de la mémoire, une fois par seconde pour de nombreuses machines. Votre clé de ligne pour ces données pourrait combiner un identifiant pour la machine et un horodatage pour les données (par exemple, Exemple : machine_4223421#1425330757685). Gardez à l'esprit que les clés de ligne 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. Dans ce cas, vous devez tenir compte des modèles d'écriture et de lecture des modèles de ML.

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. Utiliser une table unique pour tous les locataires est le moyen le plus efficace pour stocker des données mutualisées 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 la documentation Google Cloud Confidentialité Remarque.

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 le deuxième exemple, les lignes associées sont automatiquement triées d'une manière permet de les récupérer plus facilement sous forme de 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 pouvez envoyer des requêtes d'écriture à un seul nœud de votre cluster, ce qui peut créer des hotspots ou augmenter la taille de vos lignes trop volumineux.

Requêtes changeantes ou incertaines

Si vous n'exécutez pas toujours les mêmes requêtes sur vos données ou si vous ne savez pas vos requêtes, l'une des options consiste à stocker toutes les données d'une ligne dans colonne au lieu de 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.