Test de performance HBase avec YCSB

Lors de l'exécution d'un outil d'analyse comparative des performances sur votre cluster, une décision critique est toujours la taille de l'ensemble de données à utiliser pour un test de performances, et ici nous démontrons pourquoi il est important de sélectionner une taille d'ensemble de données « bien adaptée » lors de l'exécution d'une performance HBase. tester sur votre cluster.

Les configurations de cluster HBase et la taille de l'ensemble de données peuvent faire varier les performances de votre charge de travail et les résultats des tests sur le même cluster. Vous devez choisir cette taille d'ensemble de données en fonction de ce que vous essayez de comprendre sur les performances de votre cluster. Pour montrer la différence entre un ensemble de travail qui tient dans le cache mémoire disponible et un autre qui doit être lu à partir du stockage sous-jacent, nous avons exécuté 2 tests de charge de travail YCSB avec des tailles d'ensemble de données choisies de manière appropriée sur le même cluster de base de données d'exploitation CDP Private Cloud Base 7.2.2. Nous avons utilisé des tailles d'ensembles de données de 40 Go contre 1 To et le débit pour les différentes charges de travail YCSB est comparé ci-dessous, dans le graphique, plus la barre est élevée, meilleur est le débit.

Remarque :Débit =Opérations par seconde

Lorsqu'une application tente d'effectuer une lecture à partir d'un cluster HBase, le serveur de région qui traite la demande vérifie d'abord si les résultats nécessaires se trouvent dans un bloc de données qui est déjà local pour son processus via son cache de blocs. Si le bloc de données est présent, la demande du client peut être traitée directement à partir du cache et cela compte comme un accès au cache. Cependant, si le bloc n'est pas actuellement local pour le processus du serveur de région, cela est compté comme un manque de cache et il doit être lu à partir du HFile dans le stockage HDFS. En fonction de l'utilisation du cache, ce bloc sera ensuite enregistré dans le cache pour les demandes futures.

Comme prévu et vu dans le graphique récapitulatif, une charge de travail où la plupart des ensembles de données tiennent dans le cache a des latences plus faibles et un débit beaucoup plus élevé par rapport à une exécution de charge de travail où les données sont accessibles à partir de HFiles dans le stockage hdfs.

Pour choisir la taille de nos ensembles de données de charge de travail afin d'atteindre nos objectifs de test, il est important de vérifier la taille des segments de mémoire RegionServer, des caches L1 et L2, des caches de tampon du système d'exploitation, puis de définir une taille d'ensemble de données appropriée. Une fois qu'une exécution de charge de travail YCSB a terminé, un bon paramètre à vérifier pour vérifier que tout s'est déroulé comme prévu est la quantité de données qui a été traitée à partir du cache (un accès au cache) et la quantité qui a été consultée à partir du stockage hdfs. Ce rapport entre les accès au cache du serveur de région et le nombre total de demandes de lecture correspond au taux d'accès au cache.

Vous pouvez trouver ces informations dans la configuration du taux d'accès au cache L1 "l1CacheHitRatio". Si vous avez des caches L1 et L2 définis dans votre cluster, le cache L1 sert les blocs d'index et le cache L2 sert les blocs de données, et vous pouvez enregistrer les configurations L1 "l1CacheHitRatio" et L2 "l2CacheHitRatio" pour référence.

Le reste de cet article de blog passera en revue les détails de notre configuration de test, en choisissant la taille de l'ensemble de données, puis en exécutant YCSB avec ces tailles d'ensemble de données.

Configuration du cluster HBase utilisée pour ce test :

• Cluster utilisé : Cluster à 6 nœuds (1 maître + 5 serveurs de région)
• Description : Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 à 2,2 Ghz, 128 Go de RAM, disques de 4 à 2 To
• Sécurité : Aucun configuré (pas de Kerberos)
• Version CDP : CDP Private Cloud Base 7.2.2 Cluster HBase à 6 nœuds avec 1 maître + 5 serveurs de région
• Le JDK a utilisé jdk1.8_232
• Les serveurs de la région HBase ont été configurés avec un tas de 32 Go 
• Le maître HBase a été configuré avec un tas de 4 Go
• Le cache L1 avec LruBlockCache a été utilisé avec une taille de cache de 12,3 Go
• Le cache L1 total dans le cluster est de 61 Go (12,3 x 5 =61 Go)
• Le cache L2 hors tas n'a pas été configuré sur le cluster

Cas de dimensionnement 1 :les données tiennent entièrement dans le cache disponible sur le cluster

Dans notre cluster HBase, nous avons configuré un total de 61 Go (12,3 Go *5) sur les 5 serveurs de région alloués pour le cache de bloc L1. Pour un ensemble de données qui tient entièrement dans le cache, nous avons choisi un ensemble de données de 40 Go en taille.

Cas de dimensionnement 2 :ensemble de données plus grand que le cache disponible sur le cluster

Pour le deuxième scénario, nous voulons que les données soient beaucoup plus volumineuses que le cache disponible. Pour choisir une taille d'ensemble de données appropriée, nous avons examiné à la fois le cache de blocs HBase configuré et le cache de tampon du système d'exploitation dans le cluster. Dans notre cluster HBase donné, le cache de blocs L1 configuré est de 61 Go lorsqu'il est agrégé sur les RegionServers. Les nœuds de serveur avaient chacun un total de 128 Go de RAM et toute mémoire non dédiée à un processus de serveur peut être utilisée par le système d'exploitation pour mettre en cache efficacement les blocs HDFS sous-jacents et augmenter le débit global. Dans notre configuration de test, il y a environ 96 Go de cache OS disponible sur chaque nœud de serveur de région à cet effet (en ignorant la mémoire utilisée par les processus DataNode ou OS pour simplifier les choses). En agrégeant cela sur les 5 serveurs de région, nous avions un potentiel de près de 500G pour les tampons (96G * 5 serveurs de région). Nous avons donc choisi une taille d'ensemble de données de 1 To, dépassant à la fois le cache de blocs configuré et le cache de tampons du système d'exploitation disponible.

Transformer les tailles de données cibles en paramètres YCSB

Dans YCSB, une ligne est de 1 Ko par défaut. En fonction du nombre de lignes que vous chargez dans la "table utilisateur" YCSB, vous pouvez facilement estimer la taille des données de votre table "table utilisateur" YCSB. Ainsi, si vous importez 1 million de lignes, vous avez importé 1 000 000 x 1 Ko =1 Go de données dans la "table utilisateur" YCSB.

Les tailles des ensembles de données utilisées pour nos deux tests étaient :

• 40 Go de données avec 40 millions de lignes
• 1 To de données avec 1 milliard de lignes 

Méthodologie des tests

CDP Private Cloud Base 7.2.2 a été installé sur le cluster à 6 nœuds et les données de charge de travail avec 40 millions de lignes (taille totale de l'ensemble de données => 40 Go) ont été générées et les charges de travail YCSB ont été exécutées. Après le chargement, nous avons attendu que toutes les opérations de compactage soient terminées avant de commencer le test de charge de travail.

Les charges de travail YCSB exécutées sur HBase étaient

1. Charge de travail A :50 % de lecture et 50 % de mise à jour
2. Charge de travail C :100 % de lecture 
3. Charge de travail F :50 % de lecture et 50 % de ratio de mise à jour/lecture-modification-écriture :50/50
4. Charge de travail de mise à jour personnalisée uniquement :mise à jour à 100 %
   

Chaque charge de travail YCSB (A, C, F et UpdateOnly) a été exécutée pendant 15 minutes chacune, et l'exécution complète a été répétée 5 fois sans redémarrage entre les exécutions pour mesurer le débit YCSB*. Les résultats affichés sont des moyennes prises pour les 3 dernières exécutions à partir des 5 exécutions. Les 2 premiers tests ont été ignorés pour éviter la pénalité du premier et du deuxième passage.

Une fois les exécutions de 40 Go terminées, nous avons supprimé la table utilisateur et régénéré 1 milliard de lignes pour créer une taille d'ensemble de données de 1 To et réexécuté les tests avec la même méthodologie sur le même cluster.

Résultats des tests

Résultats YCSB avec 40 Go

Dans le cas de 40 Go, les données peuvent tenir entièrement dans le cache L1 de 61 Go sur le cluster. Le taux d'accès au cache L1 observé dans le cluster lors du test était proche de 99 %.

Astuce : Pour les ensembles de données plus petits où les données peuvent tenir dans le cache, nous pouvons également utiliser l'option de cache lors du chargement et préchauffer le cache pour obtenir un taux d'accès au cache de 100 % à l'aide de l'option de table PREFETCH_BLOCKS_ON_OPEN

Nous avons exécuté chaque charge de travail YCSB pendant 15 minutes toutes les 5 fois et avons pris les moyennes des 3 dernières exécutions pour éviter la pénalité de première exécution.

Résultats observés avec taux d'accès au cache L1 40 G de 99 % sur les serveurs de la région sont indiqués ci-dessous dans le tableau : 

Résultats YCSB avec un ensemble de données de 1 To

Dans le cas de 1 To, les données ne rentrent pas dans le cache L1 de 61 Go sur le cluster ou le cache de tampon du système d'exploitation de 500 Go. Le taux d'accès au cache L1 dans le cluster observé pendant le test était de 82 à 84 %.

Nous avons exécuté chaque charge de travail pendant 15 minutes toutes les 5 fois, et avons pris les moyennes des 3 dernières exécutions pour éviter la pénalité de première exécution.

Résultats obtenus avec 1 To Taux d'accès au cache L1 82-84 % sur les serveurs de la région sont indiqués ci-dessous dans le tableau : 

*Débit (ops/sec) =Nombre d'opérations par seconde

Analyse :

En comparant les résultats des tests pour les deux tailles d'ensembles de données différentes ci-dessus, nous pouvons voir comment le même débit de charge de travail peut varier de 3 000 opérations par seconde à 165 000 opérations par seconde lorsque les données sont accessibles plus rapidement à partir de l'ensemble de données 40G avec un cache préchauffé par rapport au stockage hdfs.

Le graphique ci-dessous montre le débit et compare l'évolution du débit pour différentes charges de travail lorsqu'il est exécuté avec les 2 ensembles de données de tailles différentes. Dans le graphique, plus la barre est élevée, meilleur est le débit.

Remarque :Débit =Opérations par seconde

Comme le montre le graphique, les charges de travail YCSB qui lisent des données telles que la charge de travail A, la charge de travail C et la charge de travail F avaient un bien meilleur débit dans le cas 40G où les données s'intègrent facilement dans le cache par rapport au cas de taille de données de 1 To où les données HFile devaient être accessible depuis HDFS

En regardant les taux d'accès au cache, l'ensemble de données 40G avait un taux d'accès au cache de près de 99 %, et l'ensemble de données de 1 To avait un taux d'accès au cache d'environ 85 %, donc 15 % des données dans le cas de 1 To étaient accessibles à partir du stockage hdfs .

La charge de travail personnalisée de mise à jour uniquement du YCSB que nous avons exécutée avait le même débit dans les deux cas, car elle n'effectuait que des mises à jour et aucune lecture.

Pendant les performances de HBase, nous examinons de près les latences des 95e et 99e centiles. La latence moyenne n'est que le débit total divisé par le temps total, mais le 95e centile et le 99e centile montrent les valeurs aberrantes réelles qui affectent le débit total de la charge de travail. Dans le cas de 1 To, les valeurs aberrantes de latence élevée dans les 95e et 99e centiles entraînent un ralentissement du débit, et dans le cas de 40 Go, les accès au cache à faible latence dans le 99e centile entraînent une augmentation du débit total.

Le graphique ci-dessous montre la comparaison de la latence pour la latence moyenne, la latence au 95e centile et la latence au 99e centile et comment elle diffère pour différentes charges de travail lorsqu'elle est exécutée avec des ensembles de données de tailles différentes.

Dans le graphique ci-dessus, il est difficile de voir les barres représentant la latence pour l'ensemble de données de 40 Go, car elles sont extrêmement faibles par rapport à la latence observée pour l'ensemble de données de 1 To accédant aux données à partir de hdfs.

Nous avons tracé le graphique de latence en utilisant le journal des valeurs de latence pour montrer la différence dans le tableau ci-dessous

Comme indiqué ci-dessus, les latences sont beaucoup plus faibles dans le cas de 40 Go où le taux d'accès au cache est proche de 99 % et la plupart des données de charge de travail sont disponibles dans le cache. En comparaison avec l'ensemble de données de 1 To, le taux d'accès au cache était d'environ 85 %, car les données HFile devaient être accessibles à partir du stockage HDFS.

La latence moyenne et 99 pour la charge de travail C dans le cas 40G où 99 % des données sont renvoyées depuis le cache préchauffé était d'environ 2 à 4 ms. La latence au 99e centile pour la même charge de travail C dans le cas de 1 To était d'environ 100 ms pour la charge de travail C (charge de travail en lecture seule).

Cela montre qu'un accès au cache du cache de blocs sur le tas renvoie une lecture en environ 2 ms et qu'un échec du cache et l'obtention d'un enregistrement à partir de HDFS peuvent prendre environ 100 ms sur ce cluster.

Recommandation : 

Lors de l'exécution d'un test d'analyse comparative YCSB, la taille de l'ensemble de données fait une différence substantielle dans les résultats de performance, et il est donc très important de dimensionner le test de manière appropriée. Dans le même temps, l'examen du taux d'accès au cache et des différences de latence entre la latence minimale et la 99e latence vous aidera à trouver la latence d'un accès au cache par rapport au moment où les données sont accessibles à partir du stockage sous-jacent dans le cluster.

Astuce :

Pour vérifier les taux d'accès au cache de votre charge de travail sur un serveur de région, vous pouvez utiliser la commande ci-dessous

curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio

Vous pouvez également afficher le taux d'accès au cache à partir de l'interface utilisateur Web HBase en suivant les étapes ci-dessous :

1. Depuis l'interface utilisateur Web HBase, cliquez sur le serveur de région 
2. Sous la section Bloquer le cache, sélectionnez L1 (et L2 si L2 est configuré) pour examiner les taux d'accès au cache.

Une capture d'écran montrant le taux d'accès au cache à partir du cache de bloc L1 est illustrée ci-dessous :

Voici un lien vers plus d'informations sur la capture d'écran HBase illustrée ci-dessus et le cache de bloc https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

À propos du BSJC

YCSB est une spécification open-source et une suite de programmes pour évaluer les capacités de récupération et de maintenance des programmes informatiques. C'est un outil très populaire utilisé pour comparer les performances relatives des systèmes de gestion de base de données NoSQL.

Pour utiliser YCSB afin de tester les performances de la base de données opérationnelle, consultez le blog Comment exécuter YCSB pour HBase