Analyser les performances

Cette page décrit les performances approximatives que Bigtable peut fournir dans des conditions optimales, les facteurs pouvant les affecter, ainsi que des conseils pour tester et résoudre les problèmes de performances de Bigtable.

Performances pour des charges de travail types

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 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'à 14 000 lignes par seconde ou jusqu'à 14 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, celui-ci peut accepter jusqu'à 140 000 lignes par seconde pour une charge de travail typique en lecture seule ou en écriture seule.

Planifier la capacité Bigtable

Compromis entre débit élevé et faible latence

Lors de la planification de vos clusters Bigtable, il est important de réfléchir au compromis entre le débit et la latence. 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 classiques sont réalisables lorsque vous donnez la priorité au débit, mais la latence de queue pour Bigtable sous une telle charge peut être trop élevée pour les applications sensibles à la latence. En général, Bigtable offre une latence optimale lorsque la charge du processeur d'un cluster est inférieure à 70 %. Pour les applications sensibles à la latence, nous vous recommandons de prévoir au moins deux fois la capacité de requêtes par seconde (RPS) maximale de Bigtable pour votre application. Cette capacité garantit que votre cluster Bigtable s'exécute à moins de 50 % de la charge du processeur, et offre donc une faible latence aux services frontaux. Cette capacité fournit également un tampon pour les pics de trafic ou les hotspots de clé, qui peuvent générer un trafic déséquilibré entre les nœuds du cluster.

Compromis entre utilisation du stockage et performances

Le stockage est une autre considération à prendre en compte lors de la planification des capacités. La capacité de stockage d'un cluster est déterminée par le type de stockage et le nombre de nœuds dans le cluster. Lorsque la quantité de données stockées dans un cluster augmente, Bigtable optimise le stockage en répartissant la quantité de données sur tous les nœuds du cluster.

Vous pouvez déterminer l'utilisation du stockage par nœud en divisant l'utilisation du stockage (octets) du cluster par le nombre de nœuds qu'il comporte. Prenons l'exemple d'un cluster comportant trois nœuds HDD et 9 To de données. Chaque nœud stocke environ 3 To, ce qui correspond à 18,75 % de la limite de stockage HDD par nœud, c'est-à-dire 16 To.

Lorsque l'utilisation du stockage augmente, les charges de travail peuvent rencontrer une latence accrue dans le traitement des requêtes, même si le cluster dispose de suffisamment de nœuds pour répondre aux besoins généraux en termes de processeur. En effet, plus l'espace de stockage par nœud est élevé, plus cela nécessite de travail en arrière-plan, par exemple pour l'indexation. L'augmentation du travail d'arrière-plan nécessaire pour gérer un espace de stockage important peut entraîner une latence plus élevée et un débit inférieur.

Pour les applications sensibles à la latence, nous vous recommandons de maintenir l'utilisation du stockage par nœud en dessous de 60 %. Si votre ensemble de données croît, ajoutez des nœuds pour conserver une latence faible.

Pour les applications qui ne sont pas sensibles à la latence, le stockage peut dépasser 70 % de la limite, comme expliqué dans la section Stockage par nœud.

Exécuter vos charges de travail types sur Bigtable

Exécutez toujours vos propres charges de travail types sur un cluster 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 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 Bigtable.

Causes de ralentissement des performances

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

  • Vous lisez un grand nombre de clés de lignes ou de plages de lignes non contiguës dans une seule requête de lecture. Bigtable analyse la table et lit les lignes demandées de manière séquentielle. Ce manque de parallélisme affecte la latence globale, et toutes les lectures qui atteignent un nœud à chaud peuvent augmenter la latence de queue. Pour en savoir plus, consultez la section Lectures et performances.
  • Le schéma de la table n'est pas conçu correctement. Pour obtenir de bonnes performances de 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. De plus, les hotspots d'une table peuvent affecter les performances des autres tables de la même instance. Pour en savoir plus, consultez les bonnes pratiques de conception de schémas.
  • Les lignes de votre table 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 Bigtable contiennent un très grand nombre de cellules. 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 horodatées des donné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 ne comporte pas assez de nœuds. Les nœuds d'un cluster fournissent des ressources de calcul permettant au cluster de gérer les lectures et les écritures entrantes, le suivi de l'espace de stockage, et les tâches de maintenance telles que le compactage. Vous devez vous assurer que votre cluster dispose de suffisamment de nœuds pour satisfaire aux limites recommandées en termes de calcul et de stockage. Utilisez les outils de surveillance pour vérifier si le cluster est surchargé.

    • Calcul : si le processeur de votre cluster Bigtable est surchargé, l'ajout de nœuds peut améliorer les performances en répartissant la charge de travail sur davantage de nœuds.
    • Stockage : si l'utilisation du stockage par nœud dépasse la valeur recommandée, vous devez ajouter des nœuds supplémentaires pour maintenir une latence et un débit optimaux, même si le cluster dispose de suffisamment de ressources processeur pour traiter les requêtes. En effet, l'augmentation de l'espace de stockage par nœud requiert davantage de travail de maintenance en arrière-plan par nœud. Pour en savoir plus, consultez la section Compromis entre utilisation du stockage et performances.

  • Le cluster Bigtable a été récemment étendu ou réduit. Une fois que vous avez augmenté le nombre de nœuds dans un cluster, il peut s'écouler jusqu'à 20 minutes en cas de charge élevée avant que vous constatiez une amélioration significative des performances du cluster. Bigtable fait évoluer les nœuds d'un cluster en fonction de la charge subie.

    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 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 Bigtable ou s'ils s'exécutent en dehors de Google Cloud.

  • Vous utilisez la réplication, mais votre application utilise une bibliothèque cliente obsolète. Si vous constatez une latence accrue après avoir activé la réplication, assurez-vous que la bibliothèque cliente Cloud Bigtable utilisée par votre application est à jour. Les anciennes versions des bibliothèques clientes peuvent ne pas être optimisées pour assurer la réplication. Consultez la page Bibliothèques clientes Cloud Bigtable pour rechercher le dépôt GitHub de votre bibliothèque cliente. Si nécessaire, vous pouvez vérifier sa version et la mettre à niveau.

  • Vous avez activé la réplication, mais vous n'avez pas ajouté de nœuds à vos clusters. Dans une instance qui utilise la réplication, chaque cluster doit gérer le travail de réplication en plus de la charge qu'il reçoit des applications. Des clusters sous-provisionnés peuvent entraîner une latence accrue. Vous pouvez le vérifier en consultant les graphiques d'utilisation du processeur de l'instance dans Google Cloud Console.

É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.

Démarrages à froid

Bigtable fonctionne mieux avec les tables volumineuses fréquemment consultées. Par conséquent, si vous commencez à envoyer des requêtes après une période d'inactivité, vous constaterez peut-être une latence élevée pendant que Bigtable rétablit les connexions.

Si vous savez que vous allez parfois envoyer des requêtes à une table Bigtable après une période d'inactivité, vous pouvez essayer les stratégies suivantes pour garder votre connexion à chaud et éviter cette latence élevée. Cela peut également contribuer à améliorer les performances pendant les périodes de faible nombre de requêtes par seconde.

Si vous utilisez une version du client Cloud Bigtable pour Java antérieure à la version 2.18.0, vous pouvez activer l'actualisation des canaux. Dans les versions ultérieures, l'amorçage des canaux est activé par défaut.

Lors des démarrages à froid ou des périodes de faible nombre de requêtes par seconde, le nombre d'erreurs renvoyées par Bigtable est plus pertinent que le pourcentage d'opérations renvoyant une erreur.

Comment Bigtable optimise vos données au fil du temps

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

  1. Bigtable tente de stocker à peu près la même quantité de données sur chaque nœud.
  2. 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, 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, 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 Bigtable, Bigtable segmente les données de la table en tablets. Chaque tablet contient une plage contiguë de lignes de la table.

Si vous avez écrit moins de plusieurs Go de données dans la table, Bigtable stocke toutes les tablettes dans un seul nœud de votre cluster:

Cluster à quatre tablets sur un seul nœud.

Au fur et à mesure que les tablettes s'accumulent, Bigtable déplace certaines d'entre elles vers d'autres nœuds du cluster afin que la quantité de données soit équilibrée de manière plus équitable dans 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. 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.

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 Bigtable

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

  • Faites des tests avec suffisamment de données.
    • 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 à 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 à 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 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 Bigtable génère de nouvelles données d'analyse toutes les 15 minutes et affiche 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. Lisez la présentation Premiers pas avec Key Visualizer.
  • Essayez d'insérer des marques de commentaire sur le code qui effectue les lectures et les écritures Bigtable. Si le problème de performances disparaît, vous utilisez probablement 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é à Bigtable.

  • Créez le moins de clients possible. La création d'un client pour 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. Bigtable fonctionne au mieux lorsque les lectures et les écritures sont réparties uniformément dans la table, ce qui permet à 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 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.

  • Vérifiez la latence d'une seule ligne. Si vous constatez une latence inattendue lors de l'envoi de requêtes ReadRows, vous pouvez vérifier la latence de la première ligne de la requête pour identifier la cause. Par défaut, la latence globale d'une requête ReadRows inclut la latence de chaque ligne de la requête, ainsi que le temps de traitement entre les lignes. Si la latence globale est élevée, mais que celle de la première ligne est faible, cela signifie que la latence est due au nombre de requêtes ou au temps de traitement, plutôt qu'à un problème lié à Bigtable.

    Si vous utilisez la bibliothèque cliente Bigtable pour Java, vous pouvez afficher la métrique read_rows_first_row_latency dans l'Explorateur de métriques de la console Google Cloud après avoir activé les métriques côté client.

  • Utilisez un profil d'application distinct pour chaque charge de travail. Si vous rencontrez des problèmes de performances après l'ajout d'une charge de travail, créez un profil d'application pour celle-ci. Vous pouvez ensuite surveiller les métriques de vos profils d'application séparément pour résoudre d'autres problèmes. Consultez la section Fonctionnement des profils d'application pour savoir pourquoi il est recommandé d'utiliser plusieurs profils d'application.

  • Activez les métriques côté client. Vous pouvez configurer des métriques côté client pour optimiser et résoudre les problèmes de performances. Par exemple, étant donné que Bigtable fonctionne mieux avec un nombre de RPS élevé et réparti uniformément, une latence P100 (max.) plus élevée pour un petit pourcentage de requêtes n'indique pas nécessairement un problème de performances plus important avec Bigtable. Les métriques côté client peuvent vous donner des informations sur la partie du cycle de vie de la requête qui peut être à l'origine de la latence.

Étapes suivantes