Présentation de Bigtable

Bigtable est une table partiellement remplie qui peut être étendue à des milliards de lignes et des milliers de colonnes pour permettre de stocker plusieurs téraoctets, voire pétaoctets, de données. Une seule valeur, dite "clé de ligne", est indexée dans chaque ligne. Bigtable est idéal pour stocker de grandes quantités de données à clé unique avec une faible latence. Il permet de lire et d'écrire à haut débit et à faible latence, et constitue une source de données idéale pour les opérations MapReduce.

Bigtable se présente aux applications via plusieurs bibliothèques clientes, dont une extension compatible avec la bibliothèque Apache HBase pour Java. Par conséquent, il s'intègre à l'écosystème Apache existant de logiciels open source pour le big data.

Les puissants serveurs backend de Bigtable offrent plusieurs avantages essentiels par rapport à une installation HBase autogérée :

  • Une évolutivité incroyable. Bigtable évolue en proportion directe du nombre de machines de votre cluster. Une installation HBase autogérée présente un goulot d'étranglement qui limite les performances une fois qu'un certain seuil est atteint. Bigtable, qui ne présente pas cet inconvénient, permet de faire évoluer un cluster pour gérer un plus grand nombre de lectures et d'écritures.
  • Une administration simple. Bigtable gère les mises à niveau et les redémarrages de manière transparente, et maintient automatiquement une haute durabilité des données. Pour répliquer vos données, ajoutez un deuxième cluster à votre instance. La réplication démarre automatiquement. Plus besoin de gérer des réplications ou des régions, il suffit de concevoir des schémas de table. Bigtable se charge du reste.
  • Le redimensionnement de cluster sans temps d'arrêt. Vous pouvez augmenter la taille d'un cluster Bigtable pendant quelques heures pour gérer une charge importante, et la réduire ensuite, le tout sans aucun temps d'arrêt. Une fois que vous avez modifié la taille d'un cluster, il suffit en général de quelques minutes à Bigtable pour équilibrer les performances entre tous les nœuds de votre cluster.

Points forts

Bigtable est idéal pour les applications qui nécessitent un débit et une évolutivité élevés pour les données clé-valeur, dont la valeur unitaire ne dépasse généralement pas 10 Mo. Bigtable est également un excellent moteur de stockage pour les opérations MapReduce par lot, le traitement et l'analyse par flux et les applications de machine learning (apprentissage automatique).

Bigtable permet de stocker et d'interroger tous les types de données suivants :

  • Données de séries temporelles, comme les données d'utilisation de mémoire ou de processeur de plusieurs serveurs
  • Données marketing, comme les données d'historique des achats ou de préférences client
  • Données financières, comme les historiques des transactions, les cours d'actions et les taux de change
  • Données de l'Internet des objets,comme les relevés de consommation des compteurs d'énergie et des appareils ménagers
  • Données graphiques, par exemple sur la manière dont les utilisateurs sont connectés les uns aux autres

Modèle de stockage de Bigtable

Bigtable stocke les données dans des tables extrêmement évolutives, chacune constituant un mappage de clés/valeurs triées. Une table est composée de lignes, chacune décrivant généralement une seule entité, et de colonnes contenant des valeurs individuelles pour chaque ligne. Chaque ligne est indexée par une clé de ligne unique et les colonnes liées les unes aux autres sont généralement regroupées dans une famille de colonnes. Chaque colonne est identifiée par la combinaison d'une famille de colonnes et d'un qualificatif de colonne, c'est-à-dire un nom unique dans la famille de colonnes.

Chaque intersection de lignes/colonnes peut contenir plusieurs cellules. Chaque cellule contient une version unique et horodatée des données pour cette ligne et cette colonne. Le stockage de plusieurs cellules dans une colonne permet de répertorier les modifications apportées aux données stockées pour cette ligne et cette colonne au fil du temps. Les tables Bigtable sont partiellement remplies : si une colonne n'est pas utilisée dans une ligne donnée, elle n'occupe pas d'espace.

Schéma du modèle de stockage Bigtable

Voici quelques points à noter dans cet exemple :

  • Les colonnes ne peuvent pas être utilisées sur une ligne.
  • Chaque cellule d'une ligne et d'une colonne données possède un horodatage unique (t).

Architecture de Bigtable

L'organigramme ci-dessous représente une version simplifiée de l'architecture globale de Bigtable :

Architecture globale de Bigtable.

Dans cet organigramme, toutes les requêtes client passent par un serveur frontal avant d'être envoyées à un nœud Bigtable (dans l'article original Bigtable, ces nœuds sont appelés "serveurs de tablet"). Les nœuds sont organisés dans un cluster Bigtable qui appartient à une instance Bigtable, cette dernière jouant donc le rôle de conteneur pour le cluster.

Chaque nœud du cluster gère un sous-ensemble des requêtes adressées au cluster. En ajoutant des nœuds à un cluster, vous pouvez augmenter le nombre de requêtes simultanées qu'il peut gérer. L'ajout de nœuds augmente également le débit maximal pour le cluster. Si vous activez la réplication en ajoutant des clusters supplémentaires, vous pouvez également envoyer différents types de trafic à différents clusters. Il est alors possible de basculer vers un autre cluster si un cluster devient indisponible.

Afin de faciliter l'équilibrage de la charge de travail des requêtes, une table Bigtable est segmentée en blocs de lignes adjacentes, appelés tablets (les tablets sont semblables à des régions HBase). Ces tablets sont stockés sur Colossus, le système de fichiers de Google, au format SSTable. Une table SSTable est une carte immuable, ordonnée et persistante des clés et des valeurs, sous forme de chaînes d'octets arbitraires. Chaque tablet est associé à un nœud Bigtable spécifique. Outre les fichiers SSTable, et pour augmenter la durabilité, toutes les écritures sont stockées dans le journal partagé de Colossus dès que Bigtable les reconnaît.

Il est important de noter que les données ne sont jamais stockées dans les nœuds Bigtable proprement dits : chacun possède des pointeurs vers un ensemble de tablets stockés sur Colossus. Résultat :

  • Le rééquilibrage des tablets entre les nœuds s'effectue rapidement, car les données réelles ne sont pas copiées. Bigtable met à jour les pointeurs de chaque nœud.
  • La reprise après l'échec d'un nœud Bigtable est rapide, car seules les métadonnées doivent être migrées vers le nœud de remplacement.
  • En cas d'échec d'un nœud Bigtable, aucune donnée n'est perdue.

Consultez la page Instances, clusters et nœuds pour plus d'informations sur l'utilisation de ces composants fondamentaux.

Équilibrage de charge

Chaque zone Bigtable est gérée par un processus principal qui équilibre la charge de travail et le volume de données au sein des clusters. Ce processus scinde en deux les tablets les plus sollicitées ou les plus grosses, et fusionne les tablets les moins sollicitées ou les plus petites pour les répartir entre les nœuds selon les besoins. Si un tablet donné reçoit un pic de trafic, Bigtable le scinde en deux, puis déplace l'un des nouveaux tablets ainsi créé vers un autre nœud. En gérant automatiquement toutes les opérations de scission, de fusion et de rééquilibrage, Bigtable vous évite d'avoir à administrer manuellement vos tablets. La page Comprendre les performances de Bigtable permet d'entrer dans le détail du processus.

Pour obtenir les meilleurs résultats d'écriture avec Bigtable, il est important de répartir les écritures le plus uniformément possible entre les nœuds. Pour ce faire, on peut utiliser des clés de ligne qui ne suivent pas d'ordre prévisible. Par exemple, les noms d'utilisateur sont généralement répartis plus ou moins uniformément entre chaque lettre de l'alphabet. Par conséquent, le fait d'inclure un nom d'utilisateur au début de la clé de ligne tendra à entraîner une répartition uniforme des écritures.

De même, il sera beaucoup plus efficace de pouvoir lire plusieurs lignes à la fois en plaçant côte à côte des lignes associées. Par exemple, si vous stockez divers types de données météorologiques recueillies au fil du temps, votre clé de ligne peut indiquer le lieu où elles ont été collectées, suivi d'un horodatage (par exemple, WashingtonDC#201803061617). Ce type de clé de ligne regroupera toutes les données d'un lieu dans une plage de lignes contiguës. Pour les autres lieux, la ligne commencera par un identifiant différent. Par conséquent, si les données sont collectées au même rythme pour plusieurs lieux, les écritures seront toujours réparties uniformément entre les tablets.

Consultez la section Choisir une clé de ligne pour savoir comment choisir une clé de ligne adaptée à vos données.

Types de données acceptés

Dans la plupart des cas, Bigtable traite toutes les données en tant que chaînes d'octets brutes. Le seul cas où Bigtable essaie de déterminer le type de données est celui où la cible doit être un entier de 64 bits codé comme une valeur de 8 octets en mode big-endian dans une opération d'incrémentation.

Utilisation de la mémoire et du disque

Les sections suivantes décrivent la manière dont plusieurs composants de Bigtable influent sur l'espace de mémoire et de disque qu'utilise votre instance.

Colonnes inutilisées

Les colonnes inutilisées dans une ligne Bigtable n'occupent pas d'espace dans cette ligne. Une ligne est essentiellement un ensemble d'entrées clé/valeur, une clé étant la combinaison d'une famille de colonnes, d'un qualificatif de colonne et d'un horodatage. Si une ligne ne contient pas de valeur pour une colonne spécifique, l'entrée clé-valeur n'est pas présente.

Qualificatifs de colonne

Les qualificatifs de colonne occupent de l'espace dans une ligne, car chaque qualificatif de colonne utilisé dans une ligne est stocké dans celle-ci. Par conséquent, utiliser des qualificatifs de colonne comme données est souvent efficace.

Pour en savoir plus sur les qualificatifs de colonne, consultez Colonnes.

Compactages

Bigtable réécrit régulièrement les tables pour supprimer les entrées supprimées et pour réorganiser les données afin d'accroître l'efficacité des lectures et des écritures. Il s'agit d'une opération de compactage. Il n'existe aucun paramètre de configuration pour le compactage : Bigtable compacte vos données automatiquement.

Mutations et suppressions

Les mutations, ou modifications apportées à une ligne, occupent davantage d'espace de stockage, car Bigtable les enregistre de manière séquentielle et ne les compacte que périodiquement. Lorsque Bigtable compacte une table, il supprime les valeurs qui ne sont plus nécessaires. Si vous modifiez la valeur d'une cellule, la valeur d'origine et la nouvelle seront stockées sur le disque pendant un certain temps, jusqu'à ce que les données soient compactées.

Les suppressions occupent également un espace de stockage supplémentaire, du moins à court terme, car il s'agit en fait d'un type de mutation particulier. Tant que la table n'est pas compactée, la suppression des données utilise davantage d'espace de stockage, au lieu d'en libérer.

Compression des données

Bigtable compresse automatiquement vos données à l'aide d'un algorithme intelligent. Vous ne pouvez pas configurer les paramètres de compression de votre table. Cependant, il est utile de savoir comment stocker les données pour qu'elles soient compressées efficacement :

  • Les données aléatoires ne peuvent pas être compressées aussi efficacement que les données répétitives. Un texte, comme celui que vous lisez en ce moment, est un exemple de données répétitives.
  • La compression donne de meilleurs résultats lorsque des valeurs identiques sont proches les unes des autres, soit sur la même ligne, soit sur des lignes adjacentes. Les données peuvent être compressées efficacement si vous organisez vos clés de ligne de sorte que les lignes contenant des ensembles de données identiques soient adjacentes.
  • Bigtable compresse les valeurs dont la taille est inférieure à 1 Mio. Si vous stockez des valeurs supérieures à 1 Mo, compressez-les avant de les écrire dans Bigtable. Vous pouvez ainsi économiser des cycles de processeur, de la mémoire de serveur et de la bande passante réseau.

Durabilité des données

Lorsque vous utilisez Bigtable, vos données sont stockées sur Colossus, le système de fichiers interne à très haute durabilité de Google, qui utilise des périphériques de stockage dans les centres de données de Google. Vous n'avez pas besoin d'exécuter de cluster HDFS ni d'autre système de fichiers pour utiliser Bigtable. En coulisse, Google utilise des méthodes de stockage exclusives pour assurer une durabilité des données supérieure à celle de la réplication HDFS standard à trois voies.

La durabilité est encore améliorée lorsque vous utilisez la réplication. Bigtable conserve une copie distincte de vos données à l'emplacement que vous sélectionnez pour chaque cluster d'une instance répliquée.

Modèle de cohérence

Les instances Bigtable à cluster unique fournissent une cohérence forte. Par défaut, les instances disposant de plusieurs clusters fournissent une cohérence à terme, mais pour certains cas d'utilisation, elles peuvent être configurées pour fournir une cohérence écriture-lecture ou une cohérence forte, en fonction des paramètres de la charge de travail et du profil d'application.

Sécurité

L'accès à vos tables Bigtable est contrôlé par votre projet Google Cloud et les rôles Cloud IAM (Cloud Identity and Access Management) que vous attribuez aux utilisateurs. Par exemple, vous pouvez attribuer des rôles IAM qui empêchent certains utilisateurs de lire des tables, d'écrire dans des tables ou de créer des instances. Si un utilisateur n'a pas accès à votre projet ou ne dispose pas du rôle IAM avec les autorisations appropriées pour Bigtable, il ne peut accéder à aucune de vos tables.

Vous pouvez également contrôler l'accès aux données de table en créant une vue autorisée d'une table qui représente un sous-ensemble de ses données. Vous pouvez ensuite accorder des autorisations autorisées au niveau de la vue à certains utilisateurs sans leur accorder d'autorisations au niveau de la table.

Vous pouvez gérer la sécurité au niveau du projet, de l'instance, de la table ou des vues autorisées. Bigtable n'est pas compatible avec l'application de restrictions de sécurité au niveau des lignes, des colonnes ou des cellules.

Chiffrement

Par défaut, toutes les données stockées dans Google Cloud, y compris les données des tables Bigtable, sont chiffrées au repos à l'aide des mêmes systèmes de gestion des clés renforcés que nous utilisons pour nos propres données chiffrées.

Si vous souhaitez avoir davantage de contrôle sur les clés utilisées pour chiffrer vos données Bigtable au repos, vous pouvez utiliser des clés de chiffrement gérées par le client (CMEK).

Sauvegardes

Les sauvegardes Bigtable vous permettent d'enregistrer une copie du schéma et des données d'une table, puis de restaurer vers une nouvelle table ultérieurement. Vous pouvez restaurer les sauvegardes et les copies de sauvegarde sur une nouvelle table dans toute région ou tout projet dans lequel vous disposez d'une instance Bigtable, quel que soit l'emplacement de la table source.

Capture des données modifiées

Bigtable fournit la capture de données modifiées (CDC) sous la forme de flux de modifications. Les flux de modifications vous permettent de capturer et de diffuser les modifications de données dans une table au fur et à mesure qu'elles se produisent. Vous pouvez lire un flux de modifications à l'aide d'un service tel que Dataflow pour prendre en charge des cas d'utilisation, y compris l'analyse des données, les audits, les exigences d'archivage et le déclenchement de la logique d'application en aval. Pour en savoir plus, consultez la section Présentation des flux de modifications.

Routage de requêtes avec des profils d'application

Les règles de routage du profil d'application vous permettent de contrôler les clusters qui gèrent les requêtes entrantes de vos applications. Les options de règles de routage incluent les suivantes :

  • Routage à cluster unique: envoie toutes les requêtes vers un seul cluster.
  • Routage multicluster vers n'importe quel cluster: envoie des requêtes au cluster disponible le plus proche dans une instance, y compris les options suivantes :
    • Tous les clusters: tous les clusters de l'instance peuvent recevoir des requêtes.
    • Routage vers un groupe de clusters: un groupe de clusters spécifié dans l'instance peut recevoir des requêtes.

Autres options pour le stockage et les bases de données

Bigtable n'est pas une base de données relationnelle traditionnelle. Bien qu'elle prenne en charge les requêtes SQL, certains cas d'utilisation peuvent être mieux adaptés à une autre option de base de données.

  • Si vous avez besoin de traiter des requêtes interactives sur un système de traitement analytique en ligne (OLAP), tournez-vous plutôt BigQuery.
  • Si vous devez stocker des objets hautement structurés dans une base de données de documents, avec prise en charge des transactions ACID et des requêtes de type SQL, envisagez d'utiliser Firestore.
  • Pour le stockage de données en mémoire avec une faible latence, envisagez d'utiliser Memorystore.
  • Pour synchroniser des données entre utilisateurs en temps réel, envisagez d'utiliser Firebase Realtime Database.

Pour plus d'informations sur les autres options de bases de données, consultez la présentation des services de base de données. Google Cloud offre également un large éventail d'options de stockage.

Étape suivante