Présentation de Bigtable

Bigtable est une table partiellement remplie qui peut s'étendre à des milliards de lignes et à des milliers de colonnes, ce qui vous permet 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 un débit élevé en lecture et en écriture avec une 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 ne présente pas ce goulot d'étranglement. Vous pouvez donc faire évoluer votre cluster pour gérer plus d'opérations de lecture et d'écriture.
  • 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 simplement un second cluster à votre instance. La réplication démarre automatiquement. Vous n'avez plus besoin de gérer les instances répliquées ni les régions. Il vous suffit de concevoir vos schémas de table, et 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. Lorsque vous modifiez la taille d'un cluster, il ne faut généralement que quelques minutes à Bigtable pour équilibrer les performances sur tous les nœuds du 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, où chaque valeur ne dépasse généralement pas 10 Mo. Bigtable excelle également en tant que moteur de stockage pour les opérations MapReduce par lot, l'analyse et le traitement par flux, et les applications de machine learning.

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 de transactions, les cours d'actions et les taux de change.
  • Données de l'Internet des objets,telles que les rapports 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 seule clé de ligne 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 de la famille de colonnes et d'un qualificatif de colonne, qui est 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, qui fait office 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 du cluster. Si vous activez la réplication en ajoutant des clusters, vous pouvez également envoyer différents types de trafic vers différents clusters. Ensuite, si un cluster devient indisponible, vous pouvez basculer vers un autre cluster.

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, toutes les écritures sont stockées dans le journal partagé de Colossus dès que Bigtable les reconnaît, ce qui augmente la durabilité.

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 tablettes d'un nœud à un autre se fait rapidement, car les données réelles ne sont pas copiées. Bigtable met simplement à jour les pointeurs de chaque nœud.
  • La récupération après la défaillance 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é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 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. À 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. Si vous organisez vos clés de ligne de sorte que les lignes contenant des blocs de données identiques soient côte à côte, les données peuvent être compressées efficacement.
  • Bigtable compresse les valeurs dont la taille ne dépasse pas 1 Mio. Si vous stockez des valeurs supérieures à 1 Mio, compressez-les avant de les écrire dans Bigtable, afin d'économiser les cycles de processeur, la mémoire du serveur et 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 arrière-plan, Google utilise des méthodes de stockage propriétaires pour offrir une durabilité des données supérieure à celle de la réplication à trois voies HDFS standard.

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 gérer la sécurité au niveau du projet, de l'instance et de la table. Bigtable n'accepte pas les 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 la restaurer dans une nouvelle table ultérieurement. À l'aide de sauvegardes et de copies de sauvegarde, vous pouvez restaurer dans une nouvelle table dans n'importe quelle région ou projet où 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 des données modifiées (CDC, Change Data Capture) 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 à 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 tels que l'analyse de données, les audits, les exigences d'archivage et le déclenchement d'une logique d'application en aval. Pour en savoir plus, consultez la page 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.
  • Routage vers un groupes de clusters : envoie les requêtes au cluster disponible le plus proche dans un groupe de clusters sélectionné dans une instance.

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 des transactions en ligne (OLTP, Online Transaction Processing), envisagez plutôt 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 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 plutôt Firestore.
  • Pour le stockage de données en mémoire avec une faible latence, envisagez d'utiliser Memorystore.
  • Pour synchroniser des données entre les 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