Comprendre les performances de Cloud Bigtable

Cette page décrit les performances approximatives que Cloud Bigtable peut atteindre dans des conditions optimales, les facteurs susceptibles d'affecter ces performances ainsi que des conseils pour les tests et la résolution des problèmes associés.

Performances pour des charges de travail types

Cloud Bigtable offre des performances hautement prévisibles, à l'évolutivité linéaire. Si vous évitez les causes de ralentissement décrites ci-dessous, chaque nœud Cloud Bigtable peut offrir le débit approximatif ci-après, suivant le type de stockage utilisé par le cluster :

Type de stockage Lecture   Écriture   Analyses
SSD jusqu'à 10 000 lignes par seconde ou jusqu'à 10 000 lignes par seconde ou jusqu'à 220 Mo/s
HDD jusqu'à 500 lignes par seconde ou jusqu'à 10 000 lignes par seconde ou jusqu'à 180 Mo/s

Ces estimations supposent que chaque ligne contient 1 Ko de données.

En général, les performances d'un cluster évoluent linéairement au fur et à mesure de l'ajout de nœuds au cluster. Par exemple, si vous créez un cluster SSD avec 10 nœuds, le cluster peut accepter jusqu'à 100 000 lignes par seconde pour une charge de travail type de lecture seule ou d'écriture seule.

Planifier votre capacité Cloud Bigtable

Compromis entre un débit élevé et une faible latence

Lors de la planification de vos clusters Cloud Bigtable, il est important de réfléchir au compromis entre le débit et la latence. Cloud Bigtable est utilisé dans un large éventail d'applications, et différents cas d'utilisation peuvent avoir des objectifs d'optimisation différents. Par exemple, pour une tâche de traitement de données par lot, vous pouvez vous soucier davantage du débit que de la latence. D'un autre côté, un service en ligne qui diffuse les requêtes utilisateur peut prioriser la latence par rapport au débit. Ainsi, il est important de planifier la capacité en conséquence.

Les chiffres de la section Performances pour des charges de travail types sont réalisables lorsque vous priorisez le débit, mais la latence de queue de Cloud Bigtable sous une telle charge peut être trop élevée pour les applications sensibles à la latence. En général, Cloud Bigtable offre une latence optimale lorsque la charge du processeur d'un cluster est inférieure à 70 %. Toutefois, pour les applications sensibles à la latence, nous vous recommandons de prévoir au moins deux fois la capacité maximale du nombre de RPS de Cloud Bigtable pour votre application. Cette capacité garantit que votre cluster Cloud Bigtable s'exécute à moins de 50 % de la charge du processeur. Il peut donc offrir une faible latence aux services frontend. Cette capacité fournit également un tampon pour les pics de trafic ou les hotspots d'accès aux clés, qui peuvent générer un trafic déséquilibré entre les nœuds du cluster.

Exécuter vos charges de travail types sur Cloud Bigtable

Exécutez toujours vos propres charges de travail types sur un cluster Cloud Bigtable lorsque vous planifiez la capacité afin de déterminer la meilleure allocation de ressources pour vos applications.

L'outil PerfKit Benchmarker de Google utilise YCSB pour évaluer les services cloud. Vous pouvez suivre le tutoriel de PerfKitBenchmarker pour Cloud Bigtable afin de créer des tests pour vos propres charges de travail. Vous devez alors régler les paramètres des fichiers de configuration d'analyse comparative yaml pour vous assurer que le benchmark généré reflète les caractéristiques suivantes au sein de votre production :

Pour en savoir plus sur les bonnes pratiques, consultez la page Tester les performances avec Cloud Bigtable.

Causes de ralentissement des performances

Plusieurs facteurs peuvent ralentir les performances de Cloud Bigtable par rapport aux estimations ci-dessus :

  • Le schéma de la table n'est pas conçu correctement. Pour obtenir de bonnes performances de Cloud Bigtable, il est essentiel de concevoir un schéma permettant de répartir les lectures et les écritures de manière uniforme sur chaque table. Pour plus d'informations, consultez la page Concevoir votre schéma.
  • Les lignes de votre table Cloud Bigtable contiennent de grandes quantités de données. Les estimations de performances présentées ci-dessus supposent que chaque ligne contient 1 Ko de données. Vous pouvez lire et écrire de plus grandes quantités de données par ligne, mais augmenter le nombre de données par ligne réduira également le nombre de lignes par seconde.
  • Les lignes de votre table Cloud Bigtable contiennent un très grand nombre de cellules. Cloud Bigtable prend du temps pour traiter chaque cellule d'une ligne. En outre, chaque cellule accroît la quantité de données stockées dans la table et envoyées sur le réseau. Par exemple, si vous stockez 1 Ko (1 024 octets) de données, il est beaucoup plus économe en espace de stocker ces données dans une seule cellule plutôt que de répartir les données sur 1 024 cellules contenant chacune 1 octet. Si vous répartissez vos données sur plus de cellules que nécessaire, vous risquez de ne pas obtenir les meilleures performances possibles. Si les lignes contiennent un grand nombre de cellules, car les colonnes contiennent plusieurs versions de données horodatées, envisagez de ne conserver que la valeur la plus récente. Pour une table qui existe déjà, une autre option consiste à envoyer une suppression pour toutes les versions précédentes à chaque réécriture.
  • Le cluster Cloud Bigtable ne possède pas suffisamment de nœuds. Si le cluster Cloud Bigtable est surchargé, l'ajout de nœuds peut améliorer les performances. Utilisez les outils de surveillance pour vérifier si le cluster est surchargé.
  • Le cluster Cloud Bigtable a été récemment étendu ou réduit. Lorsque vous augmentez le nombre de nœuds dans un cluster pour effectuer un scaling à la hausse, il peut s'écouler jusqu'à 20 minutes en mode charge avant que vous ne constatiez une amélioration significative des performances du cluster. Lorsque vous réduisez le nombre de nœuds dans un cluster pour effectuer un scaling à la baisse, essayez de ne pas réduire la taille du cluster de plus de 10 % en 10 minutes afin de minimiser les pics de latence.
  • Le cluster Cloud Bigtable utilise des disques durs. Dans la plupart des cas, votre cluster doit utiliser des disques SSD, dont les performances sont nettement meilleures que celles des disques durs. Pour plus de détails, consultez la page Choisir entre le stockage SSD et HDD.
  • La connexion réseau rencontre des problèmes. Des problèmes de réseau peuvent réduire le débit et accroître la durée des lectures et des écritures. Vous pouvez notamment rencontrer des problèmes si les clients ne s'exécutent pas dans la même zone que le cluster Cloud Bigtable ou s'ils s'exécutent en dehors de Google Cloud.

Étant donné que différentes charges de travail peuvent entraîner une variation des performances, vous devez effectuer des tests avec vos propres charges de travail pour obtenir les repères les plus précis.

Réplication et performance

L'activation de la réplication affectera les performances d'une instance Cloud Bigtable. L'effet est positif pour certaines métriques et négatif pour d'autres. Vous devez comprendre les impacts potentiels sur les performances avant de décider d'activer la réplication.

Débit en lecture

La réplication peut améliorer le débit de lecture, en particulier lorsque vous utilisez le routage multicluster. En outre, la réplication peut réduire le temps de latence en lecture en rapprochant géographiquement vos données Cloud Bigtable des utilisateurs de votre application.

Débit en écriture

Bien que la réplication puisse améliorer la disponibilité et les performances de lecture, elle n'augmente pas le débit en écriture. Une écriture sur l'un des clusters doit être répliquée sur tous les autres clusters de l'instance. En conséquence, chaque cluster utilise des ressources processeur pour extraire les modifications des autres clusters. Le débit en écriture peut en fait diminuer car la réplication nécessite que chaque cluster effectue un travail supplémentaire.

Par exemple, supposons que vous ayez une instance à cluster unique et que le cluster possède trois nœuds :

Instance à cluster unique comportant trois nœuds

Si vous ajoutez des nœuds au cluster, l'effet sur le débit en écriture est différent de si vous activez la réplication en ajoutant un deuxième cluster à trois nœuds à l'instance.

Ajout de nœuds au cluster d'origine : vous pouvez ajouter 3 nœuds au cluster pour atteindre un total de 6 nœuds. Le débit en écriture de l'instance double, mais les données de l'instance ne sont disponibles que dans une zone.

Instance à cluster unique comportant six nœuds

Avec réplication : vous pouvez également ajouter un deuxième cluster avec trois nœuds, pour un total de six nœuds. L'instance écrit maintenant chaque élément de données deux fois : lorsque l'écriture est reçue pour la première fois et à nouveau lorsqu'elle est répliquée sur l'autre cluster. Le débit en écriture n'augmente pas et peut diminuer, mais vous bénéficiez d'une meilleure disponibilité de vos données (dans deux zones différentes).

Instance à deux clusters comportant six nœuds

Dans ces exemples, l'instance à cluster unique peut gérer deux fois le débit en écriture que l'instance dupliquée peut gérer, même si les clusters de chaque instance ont un total de six nœuds.

Latence de réplication

Lorsque vous utilisez le routage multicluster, la réplication pour Cloud Bigtable est cohérente à terme. En règle générale, la réplication de données sur une distance plus longue prend plus de temps. Les clusters dupliqués dans différentes régions ont généralement une latence de réplication supérieure à celle des clusters dupliqués dans la même région.

Profils d'application et routage du trafic

Selon votre cas d'utilisation, vous utilisez un ou plusieurs profils d'application pour acheminer votre trafic Cloud Bigtable. Chaque profil d'application utilise un routage multicluster ou à cluster unique. Le choix du routage peut affecter les performances.

Le routage multicluster peut réduire la latence. Un profil d'application avec un routage multicluster achemine automatiquement les requêtes vers le cluster d'une instance le plus proche du point de vue de l'application. Les écritures sont ensuite dupliquées sur les autres clusters de l'instance. Ce choix automatique de la distance la plus courte entraîne une latence la plus faible possible.

Un profil d'application qui utilise le routage vers un cluster unique peut être optimal pour certains cas d'utilisation, comme pour la séparation de charges de travail ou pour avoir une sémantique de lecture après écriture sur un cluster unique, mais cela ne réduira pas la latence comme le fait le routage multicluster.

Pour comprendre comment configurer vos profils d'application pour ces cas d'utilisation et d'autres, consultez la page Exemples de paramètres de réplication.

Comment Cloud Bigtable optimise vos données au fil du temps

Pour stocker les données sous-jacentes de chacune de vos tables, Cloud Bigtable les partage en plusieurs tablets, qui peuvent être déplacés entre les nœuds du cluster Cloud Bigtable. Cette méthode de stockage permet à Cloud Bigtable d'appliquer deux stratégies différentes pour optimiser les données au fil du temps :

  1. Cloud Bigtable tente de stocker à peu près la même quantité de données sur chaque nœud.
  2. Cloud Bigtable tente de répartir équitablement les lectures et les écritures sur tous les nœuds.

Parfois, ces stratégies sont en conflit. Par exemple, si les lignes d'un tablet sont lues très fréquemment, Cloud Bigtable peut stocker ce tablet sur son propre nœud, même si de ce fait, certains nœuds stockent plus de données que d'autres.

Dans le cadre de ce processus, Cloud Bigtable peut également fractionner un tablet en au moins deux tablets plus petits, pour réduire la taille de tablet ou pour isoler les lignes actives dans un tablet existant.

Les sections suivantes expliquent chacune de ces stratégies plus en détail.

Répartir la quantité de données entre les nœuds

Lorsque vous écrivez des données sur une table Cloud Bigtable, Cloud Bigtable segmente les données de la table en tablets. Chaque tablet contient une plage contiguë de lignes de la table.

Si vous n'avez écrit qu'une petite quantité de données dans la table, Cloud Bigtable stocke tous les tablets sur un seul nœud du cluster :

Cluster à quatre tablets sur un seul nœud.

Au fur et à mesure que les tablets s'accumulent, Cloud Bigtable en déplace certains vers d'autres nœuds du cluster afin que la quantité de données soit répartie plus équitablement sur le cluster :

Des tablets supplémentaires sont distribués sur plusieurs nœuds.

Répartir uniformément les lectures et les écritures entre les nœuds

Si vous avez conçu votre schéma correctement, les lectures et les écritures doivent être réparties de manière assez uniforme sur l'ensemble de la table. Cependant, dans certains cas, vous ne pouvez pas éviter d'accéder à certaines lignes plus souvent que d'autres. Cloud Bigtable vous aide à gérer ces cas en prenant en compte les lectures et les écritures lorsqu'il équilibre les tablets entre les nœuds.

Par exemple, supposons que 25 % des lectures se rapportent à un petit nombre de tablets dans un cluster, et que les lectures sont réparties uniformément sur tous les autres tablets :

Sur 48 tablets, 25 % des lectures correspondent à trois tablets.

Cloud Bigtable redistribue les tablets existants afin que les lectures soient réparties aussi uniformément que possible sur l'ensemble du cluster :

Les trois tablets actifs sont isolés sur un nœud dédié.

Tester les performances avec Cloud Bigtable

Si vous exécutez un test de performances pour une application qui dépend de Cloud Bigtable, suivez ces instructions lorsque vous planifiez et exécutez votre test :

  • Ayez un volume de données suffisant pour le test.
    • Si le volume total de données dans les tables de votre instance de production est de 100 Go ou moins par nœud, effectuez votre test avec une table hébergeant un volume de données comparable.
    • Si les tables contiennent plus de 100 Go de données par nœud, effectuez votre test avec une table contenant au moins 100 Go de données par nœud. Par exemple, si votre instance de production présente un cluster à quatre nœuds et que les tables de l'instance contiennent au total 1 To de données, utilisez une table d'au moins 400 Go dans le cadre de votre test.
  • Utilisez une table unique pour le test.
  • Restez en dessous de l'utilisation de stockage recommandée par nœud. Pour plus d'informations, consultez la page Utilisation du stockage par nœud.
  • Avant le test, effectuez un prétest intensif pendant plusieurs minutes. Cette étape permet à Cloud Bigtable d'équilibrer les données entre les nœuds en fonction des modèles d'accès observés.
  • Exécutez le test pendant au moins 10 minutes. Cette étape permet à Cloud Bigtable d'optimiser davantage les données, et de vous assurer que le test porte à la fois sur les lectures du disque et sur les lectures mises en cache à partir de la mémoire.

Résoudre les problèmes liés aux performances

Si vous pensez que Cloud Bigtable est susceptible de brider les performances de votre application, appliquez tous les conseils suivants :

  • Examinez les analyses Key Visualizer pour votre table. L'outil Key Visualizer pour Cloud Bigtable fournit des analyses quotidiennes qui présentent les modèles d'utilisation de chaque table d'un cluster. Key Visualizer permet de vérifier si vos tendances d'utilisation génèrent des résultats indésirables, tels que du hotspotting sur des lignes spécifiques ou une utilisation excessive du processeur. Apprenez à vous familiariser avec Key Visualizer.
  • Essayez d'insérer des marques de commentaire sur le code qui effectue les lectures et les écritures Cloud Bigtable. Si le problème de performances disparaît, vous utilisez probablement Cloud Bigtable d'une manière qui entraîne des performances réduites. Si le problème de performances persiste, il n'est probablement pas lié à Cloud Bigtable.
  • Créez le moins de clients possible. La création d'un client pour Cloud Bigtable est une opération relativement coûteuse. Par conséquent, vous devez créer le plus petit nombre possible de clients :

    • Si vous avez recours à la réplication ou à des profils d'application pour identifier les différents types de trafic vers votre instance, créez un client par profil d'application et partagez les clients dans l'ensemble de l'application.
    • Si vous n'utilisez pas la réplication ou les profils d'application, créez un client unique et partagez-le dans l'ensemble de l'application.

    Si vous utilisez le client HBase pour Java, vous créez un objet Connection plutôt qu'un client. Vous devez donc créer le moins de connexions possible.

  • Veillez à lire et à écrire de nombreuses lignes différentes dans votre table. Cloud Bigtable fonctionne au mieux lorsque les lectures et les écritures sont réparties uniformément dans la table, ce qui permet à Cloud Bigtable de répartir la charge de travail sur tous les nœuds du cluster. Si les lectures et les écritures ne peuvent pas être réparties sur tous les nœuds Cloud Bigtable, les performances en pâtissent.

    Si vous constatez que vous ne lisez et écrivez qu'un petit nombre de lignes, vous devrez peut-être concevoir à nouveau votre schéma afin que les lectures et les écritures soient réparties plus uniformément.

  • Vérifiez que les performances sont similaires pour les lectures et les écritures. Si vous trouvez que les lectures sont beaucoup plus rapides que les écritures, vous essayez peut-être de lire des clés de ligne inexistantes ou une large plage de clés de ligne ne contenant qu'un petit nombre de lignes.

    Pour établir une comparaison valable entre les lectures et les écritures, vous devez viser au moins 90 % de vos lectures renvoyant des résultats valides. De même, si vous lisez une grande plage de clés de ligne, mesurez les performances en fonction du nombre réel de lignes dans cette plage, plutôt que du nombre maximal de lignes pouvant exister.

  • Utilisez le type de requêtes d'écriture approprié pour vos données. Le choix de la méthode optimale pour écrire vos données permet de maintenir des performances élevées.

Étapes suivantes