Présentation de Bigtable

Bigtable est une table partiellement remplie qui peut s'adapter à des milliards de lignes et de 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 avec une faible latence. Il permet un débit élevé en lecture et en écriture à faible la latence. C'est aussi 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 effectue un scaling vertical par rapport au nombre de machines de votre cluster. Une base de données HBase autogérée présente un goulot d'étranglement qui limite les performances après une un certain seuil est atteint. Bigtable ne dispose pas de Vous pouvez ainsi augmenter la capacité de votre cluster pour gérer plus de lectures et les opérations 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 une seconde vers votre instance, et la réplication démarre automatiquement. Aucun autre la gestion des instances répliquées ou des régions ; il vous suffit de concevoir vos 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. Après avoir modifié la taille d'un cluster, il suffit généralement 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 nécessitant un débit évolutivité pour les données clé-valeur, où chaque valeur n'est généralement pas supérieure à 10 Mo. Bigtable est également un excellent moteur de stockage pour MapReduce par lots. les opérations, 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 taux de change.
  • Données de l'Internet des objets,comme les relevés de consommation des compteurs d'énergie et appareils électromé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 de ces tables est un mappage clé-valeur trié. 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 qui liés les uns aux autres sont généralement regroupés dans une famille de colonnes. Chaque est identifiée par la combinaison d'une famille de colonnes et d'une colonne qualifier, qui est un nom unique dans la famille de colonnes.

Chaque intersection d'une ligne et d'une colonne peut contenir plusieurs cellules. Chaque cellule contient une version horodatée unique des données pour cette ligne et cette colonne. Le stockage de plusieurs cellules dans une colonne fournit un enregistrement de la façon dont les données stockées pour cette ligne et cette colonne ont changé au fil du temps. Les tables Bigtable sont creux; si une colonne n'est pas utilisée dans une ligne donnée, elle n'occupe aucune 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"). La les nœuds sont organisés dans un cluster Bigtable appartenant une instance Bigtable, un 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 aussi le débit maximal pour le cluster. Si vous activez la réplication en ajoutant des clusters, vous peuvent également envoyer différents types de trafic à différents clusters. Si un 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 tablette est associé à un nœud Bigtable spécifique. En plus des SSTable, toutes les écritures sont stockées dans le journal partagé de Colossus dès qu'elles sont reconnues par Bigtable, ce qui offre une durabilité accrue.

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 rapide, car les données réelles ne sont pas copiées. Bigtable met à jour des pointeurs pour chaque nœud.
  • La reprise en cas de défaillance d'un nœud Bigtable est rapide, 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 permet de segmenter les équipes tablettes en deux et fusionne les tablettes les moins consultées/les plus petites, en les redistribuant 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 y parvenir, vous pouvez l'objectif est d'utiliser des clés de ligne qui ne suivent pas un 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 qui ne sont pas utilisées dans une ligne Bigtable n'occupent aucune sur cette ligne. Chaque ligne est essentiellement un ensemble d'entrées de valeurs-clés, où la clé est une combinaison de la famille de colonnes, du qualificatif de colonne et du code temporel. Si une ligne ne contient pas de valeur pour une colonne spécifique, la la 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, sur la même ligne ou dans des lignes adjacentes. Si vous organisez vos clés de ligne des lignes contenant des fragments de données identiques sont côte à côte, les données peuvent être de manière efficace.
  • Bigtable compresse des valeurs pouvant atteindre 1 Mio. Si vous stockez des valeurs supérieures à 1 Mio, compressez-les avant les écrivant dans Bigtable, ce qui vous permet d'économiser des cycles de processeur, la mémoire 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 un cluster HDFS ni aucun autre système de fichiers pour utiliser Bigtable. En arrière-plan, Google utilise un stockage propriétaire permettant d'obtenir une durabilité des données supérieure à celle fournie Réplication à trois voies HDFS

La durabilité est encore améliorée lors de l'utilisation de 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 des tables en créant une vue autorisée d'une table qui représente un sous-ensemble des données de la table. Ensuite, vous pouvez accorder des autorisations au niveau de la vue à certains utilisateurs en leur accordant des 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 des 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 votre les données Bigtable au repos, vous pouvez utiliser le chiffrement géré par le client (CMEK).

Sauvegardes

Les sauvegardes Bigtable vous permettent d'enregistrer une copie le schéma et les données d'une table, puis d'effectuer une restauration vers une nouvelle table ultérieurement. En utilisant et des copies de sauvegarde, vous pouvez restaurer une nouvelle table dans n'importe quelle région ou dans lequel vous disposez d'une instance Bigtable, la table source.

Capture des données modifiées

Bigtable permet de capturer les données modifiées (CDC, Change Data Capture) sous la forme de modifications flux. Les flux de modifications vous permettent de capturer et de diffuser les modifications de données dans une table au fur et à mesure que les changements 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 de la logique d'application en aval. Pour plus consultez la page Présentation des modifications flux.

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: les requêtes sont envoyées au cluster le plus proche cluster disponible dans une instance, avec les options suivantes: <ph type="x-smartling-placeholder">
      </ph>
    • N'importe quel cluster: n'importe quel cluster de l'instance peut recevoir des requêtes.
    • Routage de groupe de clusters: un groupe spécifique de clusters de 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. 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 pour le traitement des transactions en ligne (OLTP, Online Transaction Processing) envisagez d'utiliser 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 très structurés dans une base de données de documents, avec des transactions ACID et des requêtes de type SQL, envisagez 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, vous pouvez utiliser le Firebase Realtime base de données.

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