Bonnes pratiques pour 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 consulté la présentation de Bigtable. Cette page aborde les thèmes 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 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, 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 les demandes 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 des préfixes de clés de ligne.

Un autre point à prendre en compte est d'éviter les hotspots. Pour ce faire, vous devez tenir compte des modèles 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 comporte un index : la clé de ligne. Chaque clé de ligne doit être unique. Pour créer un index secondaire, utilisez une vue matérialisée continue. Pour en savoir plus, consultez Créer un index secondaire asynchrone.
  • Les clés de ligne trient les lignes de façon lexicographique, de la chaîne d'octets la plus basse à la plus élevée. Cet ordre est 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. Un agrégat 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 dus à un accès fréquent à une partie de la table sur une courte période.

Tables