Instances, clusters et nœuds

Pour utiliser Bigtable, vous créez des instances qui contiennent des clusters auxquels vos applications peuvent se connecter. Chaque cluster contient des nœuds, à savoir les unités de calcul qui gèrent vos données et effectuent des tâches de maintenance.

Cette page fournit plus d'informations sur les instances, les clusters et les nœuds Bigtable.

Avant de lire cette page, vous devez avoir lu la présentation de Bigtable.

Instances

Une instance Bigtable est un conteneur pour vos données. Les instances possèdent un ou plusieurs clusters situés dans différentes zones. Chaque cluster comporte au moins un nœud.

Une table appartient à une instance, et non à un cluster ou à un nœud. Si vous disposez d'une instance avec plusieurs clusters, vous utilisez la réplication. Cela signifie que vous ne pouvez pas attribuer une table à un cluster individuel ni créer des règles de récupération de mémoire uniques pour chaque cluster d'une instance. Vous ne pouvez pas non plus faire en sorte que chaque cluster stocke un ensemble de données différent dans la même table.

Une instance possède quelques propriétés importantes que vous devez connaître :

  • L'édition (Enterprise ou Enterprise Plus)
  • Le type de stockage (SSD ou HDD)
  • Les profils d'application, qui sont principalement destinés aux instances utilisant la réplication

Les sections suivantes décrivent ces propriétés.

Éditions

Lorsque vous créez une instance, vous devez choisir une édition. L'édition Enterprise est le service Bigtable établi pour les charges de travail mutualisées exigeantes qui nécessitent les plus hauts niveaux de performances et de disponibilité mondiale.

Vous pouvez modifier une édition ultérieurement pour l'adapter à l'évolution de vos charges de travail. Les modifications apportées à l'édition d'une instance prennent effet immédiatement. Pour en savoir plus, consultez la présentation des éditions.

Si vous avez besoin d'une latence de lecture ponctuelle inférieure à la milliseconde, vous pouvez activer le niveau en mémoire intégré (preview) pour votre cluster. Le stockage en mémoire n'est disponible que dans l'édition Enterprise Plus. Pour en savoir plus, consultez la présentation du stockage en mémoire .

Types de stockage

Lorsque vous créez une instance, vous devez choisir le type de disques durs, SSD ou HDD, à utiliser par les clusters de l'instance pour stocker les données. Le stockage SSD constitue souvent, mais pas toujours, le choix le plus efficace et le plus rentable.

Le choix entre disques durs SSD et HDD est définitif. Chaque cluster de votre instance doit utiliser le même type de stockage. Par conséquent, assurez-vous de choisir le type de stockage adapté à votre cas d'utilisation. Pour en savoir plus et pour vous aider à faire votre choix, consultez la page Choisir entre le stockage SSD et HDD.

Si vous devez stocker des données historiques pour des raisons telles que des exigences réglementaires, utilisez le stockage à accès peu fréquent Bigtable dans le cadre du stockage hiérarchisé (preview). Cette option est disponible pour les instances SSD.

Profils d'application

Une fois que vous avez créé une instance, Bigtable l'utilise pour stocker des profils d'application. Pour les instances qui utilisent la réplication, les profils d'application contrôlent la manière dont vos applications se connectent aux clusters de l'instance.

Si votre instance n'utilise pas la réplication, vous pouvez utiliser les profils d'application pour fournir des identifiants distincts à chacune de vos applications ou à chaque fonction d'une application. Vous pouvez ensuite afficher des graphiques distincts pour chaque profil d'application dans la Google Cloud console.

Pour en savoir plus sur les profils d'application, consultez la section Profils d'application. Pour savoir comment configurer les profils d'application de votre instance, consultez la section Configurer des profils d'application.

Clusters

Un cluster représente le service Bigtable dans un emplacement spécifique. Chaque cluster appartient à une seule instance Bigtable. Une instance peut avoir des clusters dans un maximum de huit régions. Lorsque votre application envoie des requêtes à une instance Bigtable, celles-ci sont traitées par l'un des clusters de l'instance.

Chaque cluster est situé dans une seule zone. Une instance peut comporter des clusters dans huit régions au maximum, où Bigtable est disponible. Chaque zone d'une région ne peut contenir que un seul cluster. Par exemple, si une instance possède un cluster dans us-east1-b, vous pouvez ajouter un cluster dans une autre zone de la même région, telle que us-east1-c, ou dans une zone d'une autre région, telle que europe-west2-a.

Le nombre de clusters que vous pouvez créer dans une instance dépend du nombre de zones disponibles dans les régions que vous choisissez. Par exemple, si vous créez des clusters dans huit régions comportant chacune trois zones, l'instance peut avoir 24 clusters au maximum. Pour obtenir la liste des zones et des régions dans lesquelles Bigtable est disponible, consultez Emplacements Bigtable.

Les instances Bigtable ne disposant que d'un seul cluster n'utilisent pas la réplication. Si vous ajoutez un deuxième cluster à une instance, Bigtable commence automatiquement à répliquer vos données en conservant des copies distinctes des données dans chacune des zones des clusters et en synchronisant les mises à jour entre les copies. Vous pouvez choisir le cluster auquel vos applications se connectent, ce qui permet d'isoler différents types de trafic les uns des autres. Vous pouvez également laisser Bigtable équilibre le trafic entre les clusters. Si un cluster devient indisponible, vous pouvez basculer d'un cluster à un autre. Pour découvrir comment fonctionne la réplication, consultez la présentation de la réplication.

Dans la plupart des cas, vous devez activer l'autoscaling pour un cluster, afin que Bigtable ajoute et supprime des nœuds selon les besoins pour gérer les charges de travail du cluster.

Lorsque vous créez un cluster, vous pouvez activer la mise à l'échelle des nœuds par deux, une configuration qui définit le cluster pour qu'il soit toujours mis à l'échelle par incréments de deux nœuds. Pour en savoir plus, consultez la section Facteur de mise à l'échelle des nœuds.

Nœuds

Chaque cluster d'une instance possède un ou plusieurs nœuds, qui correspondent à des ressources de calcul permettant à Bigtable de gérer vos données.

La capacité de calcul et les performances d'un nœud dépendent de l'édition de l'instance. Pour en savoir plus, consultez la page Analyser les performances.

En coulisses, Bigtable divise toutes les données d'une table en tablets distincts. Les tablets sont stockés sur le disque, séparément des nœuds mais dans la même zone que ces derniers. Un tablet est associé à un unique nœud.

Chaque nœud est responsable des éléments suivants :

  • Effectuer le suivi de tablets spécifiques sur le disque
  • Gérer les lectures et écritures entrantes pour ces tablets
  • Effectuer les tâches de maintenance sur ces tablets, telles que des compactages périodiques

Un cluster doit disposer de suffisamment de nœuds pour assimiler la charge de travail actuelle et la quantité de données qu'il stocke. Sinon, le cluster risque de ne pas pouvoir gérer les requêtes entrantes, ce qui peut entraîner une augmentation de la latence. Surveillez l'utilisation du processeur et de l'espace disque de vos clusters et ajoutez des nœuds à une instance lorsque ses métriques dépassent les recommandations de la section Planifier votre capacité.

Pour en savoir plus sur le stockage et la gestion des données par Bigtable, consultez la page Architecture Bigtable.

Pour les jobs de lecture à haut débit, vous pouvez utiliser Data Boost pour Bigtable pour le calcul au lieu des nœuds de votre cluster. Data Boost vous permet d'envoyer des jobs et des requêtes de lecture volumineux à l'aide du calcul sans serveur, tandis que votre application principale continue d'utiliser les nœuds de cluster pour le calcul. Pour en savoir plus, consultez la page Présentation de Data Boost.

Pour les charges de travail de données historiques auxquelles vous n'avez pas besoin d'accéder souvent, vous pouvez utiliser le niveau d'accès peu fréquent dans les instances SSD.

Nœuds pour les clusters dupliqués

Lorsque votre instance comporte plusieurs clusters, le basculement devient un élément à prendre en compte lorsque vous configurez le nombre maximal de nœuds pour l'autoscaling ou que vous allouez manuellement les nœuds.

  • Si vous utilisez le routage multicluster dans l'un de vos profils d'application, un basculement automatique peut se produire si un ou plusieurs clusters ne sont pas disponibles.

  • Lorsque vous basculez manuellement d'un cluster à un autre ou qu'un basculement automatique se produit, le cluster de réception doit idéalement disposer d'une capacité suffisante pour prendre en charge la charge. Vous pouvez soit toujours allouer suffisamment de nœuds pour prendre en charge le basculement, ce qui peut être coûteux, soit vous appuyer sur l'autoscaling pour ajouter des nœuds lorsque le trafic bascule. Toutefois, sachez que les performances peuvent être brièvement affectées pendant la mise à l'échelle du cluster.

  • Si tous vos profils d'application utilisent un routage à cluster unique, chaque cluster peut avoir un nombre différent de nœuds. Redimensionnez chaque cluster en fonction de sa charge de travail.

    Comme Bigtable stocke une copie de vos données sur chaque cluster, chacun d'eux doit toujours disposer de suffisamment de nœuds pour couvrir l'espace disque utilisé et dupliquer les opérations d'écriture entre les clusters.

    Vous pouvez toujours basculer manuellement d'un cluster à un autre si nécessaire. Cependant, si un cluster a beaucoup plus de nœuds qu'un autre et que vous devez basculer vers celui comportant moins de nœuds, vous devrez peut-être commencer par ajouter des nœuds. Rien ne garantit que des nœuds supplémentaires seront disponibles au moment où vous aurez besoin d'effectuer un basculement. La seule façon de réserver des nœuds consiste à les ajouter à votre cluster.

Étape suivante