Présentation de Cloud Bigtable

Cloud 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. Cloud Bigtable permet de stocker de très grandes quantités de données à clé unique avec une latence très faible. Il permet des débits élevés en lecture et en écriture, avec une faible latence, et constitue une source de données idéale pour les opérations MapReduce.

Cloud 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 Cloud Bigtable offrent plusieurs avantages essentiels par rapport à une installation HBase autogérée :

  • Une évolutivité incroyable. Cloud 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. Cloud 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. Cloud Bigtable gère les mises à niveau et les redémarrages de manière transparente, et maintient automatiquement une haute durabilité des données. Pour dupliquer des données, il suffit d'ajouter un deuxième cluster à l'instance, et la réplication démarre automatiquement. Plus besoin de gérer d'instances dupliquées ou de régions, il suffit de concevoir un schéma de table. Cloud Bigtable se charge du reste.
  • Le redimensionnement de cluster sans temps d'arrêt. Vous pouvez augmenter la taille d'un cluster Cloud 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 à Cloud Bigtable pour équilibrer les performances entre tous les nœuds de votre cluster.

Points forts

Cloud Bigtable s'adresse en particulier aux 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. Ce service 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).

Cloud 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 ou les taux de change de devises
  • 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 Cloud Bigtable

Cloud Bigtable stocke les données dans des tables extrêmement évolutives, chacune constituant une carte 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, ou versions, à différents horodatages, fournissant un enregistrement de la manière dont les données stockées ont été modifiées au fil du temps. Les tables Cloud Bigtable sont partiellement remplies : une cellule qui ne contient aucune donnée n'occupe aucun espace.

Par exemple, supposons que vous créiez un réseau social pour les présidents américains, que nous appellerons "Prezzy". Chaque président peut suivre les publications des autres présidents. L'illustration ci-dessous représente une table Cloud Bigtable qui répertorie les personnes que chaque président suit sur Prezzy :

Une table Cloud Bigtable avec une ligne par nom d'utilisateur.

Voici quelques points à noter dans cet exemple :

  • La table contient une famille de colonnes, appelée follows. Cette famille contient plusieurs qualificatifs de colonne.
  • Les qualificatifs de colonne sont utilisés sous forme de données. Ce choix de conception tire parti du fait que les tables Cloud Bigtable sont partiellement remplies et que des qualificatifs de colonne peuvent être ajoutés à la volée.
  • Le nom d'utilisateur est utilisé sous forme de clé de ligne. En supposant que les noms d'utilisateur sont répartis par ordre alphabétique de manière uniforme, l'accès aux données sera relativement uniforme dans l'ensemble de la table. Consultez la section Équilibrage de charge pour découvrir comment Cloud Bigtable traite les charges inégales, ainsi que la section Choisir une clé de ligne pour obtenir des conseils détaillés sur le choix d'une clé de ligne.

Architecture Cloud Bigtable

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

Architecture globale de Cloud Bigtable.

Dans cet organigramme, toutes les requêtes client passent par un serveur frontal avant d'être envoyées à un nœud Cloud Bigtable (dans l'article original Bigtable, ces nœuds sont appelés "serveurs de tablet"). Les nœuds sont organisés dans un cluster Cloud Bigtable qui appartient à une instance Cloud 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, ainsi que le débit maximal pour l'ensemble de celui-ci. Si vous activez la réplication en ajoutant un deuxième cluster, vous pouvez également envoyer différents types de trafic à différents clusters. Vous pouvez par ailleurs basculer vers un cluster si l'autre devient indisponible.

Afin de faciliter l'équilibrage de la charge de travail constituée par les requêtes, une table Cloud Bigtable est segmentée en blocs de lignes contiguës, 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 Cloud 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 Cloud Bigtable les reconnaît.

Il est important de noter que les données ne sont jamais stockées dans les nœuds Cloud 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 est très rapide, car les données réelles ne sont pas copiées. Cloud Bigtable se contente d'actualiser les pointeurs de chaque nœud.
  • La reprise après l'échec d'un nœud Cloud Bigtable est très 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 Cloud 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 Cloud 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és ou les plus gros, et fusionne les tablets les moins sollicités ou les plus petits pour les répartir entre les nœuds selon les besoins. Si un tablet donné reçoit un pic de trafic, Cloud 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, Cloud Bigtable évite aux utilisateurs d'avoir à administrer manuellement leurs tablets. La page Comprendre les performances de Cloud Bigtable permet d'entrer dans le détail du processus.

Pour obtenir les meilleurs résultats d'écriture avec Cloud Bigtable, il est important de répartir les écritures le plus uniformément possible entre les nœuds. À cet effet, 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 définir une clé de ligne adaptée à vos données.

Types de données acceptés

Dans la plupart des cas, Cloud Bigtable traite toutes les données en tant que chaînes d'octets brutes. Le seul cas où Cloud 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 Cloud Bigtable influent sur l'espace de mémoire et de disque qu'utilise votre instance.

Cellules vides

Les cellules vides d'une table Cloud Bigtable n'occupent pas d'espace. 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 clé spécifique, l'entrée clé/valeur est tout simplement absente.

Qualificatifs de colonne

Chaque qualificatif de colonne utilisé dans une ligne est stocké dans celle-ci, et y occupe donc à ce titre de l'espace. Dès lors, il est souvent pertinent d'utiliser des qualificatifs de colonne comme données. Dans l'exemple Prezzy ci-dessus, les qualificatifs de colonne de la famille follows correspondent au nom des utilisateurs suivis. Pour ces colonnes, l'entrée clé/valeur n'est donc qu'un simple espace réservé.

Compactages

Cloud 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 : Cloud Bigtable compacte vos données automatiquement.

Mutations et suppressions

Les mutations, ou modifications apportées à une ligne, occupent davantage d'espace de stockage, car Cloud Bigtable les enregistre de manière séquentielle et ne les compacte que périodiquement. Lorsque Cloud 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

Cloud 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.
  • Compressez les valeurs supérieures à 1 Mio avant de les stocker dans Cloud Bigtable. Cela permet d'économiser les cycles du processeur, la mémoire du serveur et la bande passante réseau. Cloud Bigtable désactive automatiquement la compression pour les valeurs supérieures à 1 Mio.

Durabilité des données

Lorsque vous utilisez Cloud 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 Cloud Bigtable. Si votre instance utilise la réplication, Cloud Bigtable conserve une seule copie de vos données dans Colossus pour chacun de ses clusters. Chaque copie est placée dans une zone ou région différente, ce qui améliore d'autant plus la durabilité.

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. En outre, nous créons des sauvegardes de vos données pour vous protéger contre les événements catastrophiques et permettre une récupération après sinistre.

Sécurité

L'accès à vos tables Cloud Bigtable est contrôlé par votre projet Google Cloud et les rôles IAM (gestion de l'authentification et des accès) 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 Cloud Bigtable, il ne peut accéder à aucune de vos tables.

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

Sauvegardes

Les sauvegardes Cloud Bigtable vous permettent d'enregistrer une copie du schéma et des données d'une table, puis de restaurer depuis la sauvegarde vers une nouvelle table ultérieurement. Les sauvegardes vous aident à récupérer des données corrompues au niveau de l'application ou à corriger des erreurs d'opérateur, comme la suppression accidentelle d'une table.

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

Cloud Bigtable n'est pas une base de données relationnelle. Il n'accepte pas les requêtes SQL, ni les jointures, ni les transactions à plusieurs lignes.

  • Si vous avez besoin d'une compatibilité SQL complète avec un système de traitement de transactions en ligne (OLTP), envisagez plutôt d'utiliser Cloud Spanner ou Cloud SQL.
  • 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 avez besoin de stocker des objets hautement structurés dans une base de données de documents, acceptant les transactions ACID et les requêtes de type SQL, envisagez plutôt 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.

Étapes suivantes