Présentation de 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. Bigtable permet de stocker de très grandes quantités de données à clé unique avec une latence très faible. 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 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. 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 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).

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 de Bigtable

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. 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, 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 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 est très rapide, car les données réelles ne sont pas copiées. Bigtable se contente d'actualiser les pointeurs de chaque nœud.
  • La reprise après l'échec d'un nœud 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 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é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, 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 évite aux utilisateurs d'avoir à administrer manuellement leurs 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. À 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 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 est tout simplement absente.

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.

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

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. Si votre instance utilise la réplication, 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 copies de vos données pour vous protéger contre les événements catastrophiques et permettre une récupération après sinistre.

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 gérer la sécurité au niveau du projet, de l'instance et de la table. 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 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

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.

Étape suivante