YCSBを使用したHBaseパフォーマンステスト

クラスタでパフォーマンスベンチマークツールを実行する場合、重要な決定は常にパフォーマンステストに使用するデータセットサイズです。ここでは、HBaseパフォーマンスを実行するときに「適切な」データセットサイズを選択することが重要である理由を示します。クラスタでテストします。

HBaseクラスターの構成とデータセットのサイズによって、同じクラスターでのワークロードのパフォーマンスとテスト結果が異なる場合があります。このデータセットのサイズは、クラスターのパフォーマンスについて理解しようとしていることに基づいて選択する必要があります。使用可能なメモリキャッシュに収まるワーキングセットと、基盤となるストレージから読み取る必要のあるワーキングセットの違いを示すために、同じCDPプライベートクラウドベース7.2.2オペレーションデータベースクラスターで、適切に選択されたデータセットサイズで2つのYCSBワークロードテストを実行しました。 40GBと1TBのデータセットサイズを使用し、さまざまなYCSBワークロードのスループットを以下で比較します。グラフでは、バーが高いほどスループットが高くなります。

注：スループット=1秒あたりの操作数

アプリケーションがHBaseクラスターから読み取りを行おうとすると、リクエストを処理するリージョンサーバーは、最初に、必要な結果が、ブロックキャッシュを介してプロセスに対して既にローカルになっているデータブロックにあるかどうかを確認します。データブロックが存在する場合、クライアントリクエストはキャッシュから直接処理でき、これはキャッシュヒットとしてカウントされます。ただし、ブロックが現在リージョンサーバープロセスに対してローカルではない場合、それはキャッシュミスとしてカウントされ、HDFSストレージのHFileから読み取る必要があります。キャッシュの使用率に応じて、そのブロックは将来のリクエストのためにキャッシュに保存されます。

予想され、要約チャートに示されているように、ほとんどのデータセットがキャッシュに収まるワークロードは、hdfsストレージのHFilesからデータにアクセスするワークロード実行と比較して、レイテンシが低く、スループットがはるかに高くなります。

テスト目標を適切に満たすようにワークロードデータセットのサイズを選択するには、RegionServerヒープ、L1およびL2キャッシュ、OSバッファキャッシュのサイズを確認してから、適切なデータセットサイズを設定することが重要です。 YCSBワークロードの実行が完了した後、期待どおりに実行されたことを確認する方法として、キャッシュから処理されたデータ（キャッシュヒット）とhdfsストレージからアクセスされたデータの量を確認するための適切なパラメーターを確認します。読み取り要求の総数に対するRegionServerのキャッシュヒットのこの比率が、キャッシュヒットの比率です。

この情報は、L1キャッシュヒット率「l1CacheHitRatio」構成から見つけることができます。クラスタにL1キャッシュとL2キャッシュの両方が設定されている場合、L1キャッシュはインデックスブロックを提供し、L2キャッシュはデータブロックを提供し、参照用にL1「l1CacheHitRatio」とL2「l2CacheHitRatio」の両方の構成を記録できます。

このブログ投稿の残りの部分では、テストセットアップの詳細、データセットサイズの選択、およびそれらのデータセットサイズでのYCSBの実行について説明します。

このテストに使用されるHBaseクラスター構成：

• 使用されるクラスター： 6ノードクラスター（1マスター+ 5リージョンサーバー）
• 説明： Dell PowerEdge R430、20c / 40t Xenon e5-2630 v4 @ 2.2Ghz、128GB RAM、4-2TBディスク
• セキュリティ： 構成なし（Kerberosなし）
• CDPバージョン： CDPプライベートクラウドベース7.2.26ノードのHBaseクラスターと1つのマスター+5つのリージョンサーバー
• JDKはjdk1.8_232を使用しました
• HBaseリージョンサーバーは32GBのヒープで構成されました
• HBaseマスターは4GBのヒープで構成されました
• LruBlockCacheを使用したL1キャッシュが12.3GBのキャッシュサイズで使用されました
• クラスター内のL1キャッシュの合計は61 GB（12.3 * 5 =61 GB）
• L2オフヒープキャッシュがクラスターに構成されていません

サイジングケース1：データはクラスターで使用可能なキャッシュに完全に収まります

HBaseクラスターでは、L1ブロックキャッシュに割り当てられた5つのリージョンサーバー全体で合計61GB（12.3GB * 5）を構成しました。キャッシュに完全に収まるデータセットには、40GBのデータセットを選択しました。 サイズで。

サイズ設定ケース2：クラスターで使用可能なキャッシュよりも大きいデータセット

2番目のシナリオでは、データを使用可能なキャッシュよりもはるかに大きくする必要があります。適切なデータセットサイズを選択するために、クラスター内の構成済みのHBaseブロックキャッシュとOSバッファーキャッシュの両方を調べました。特定のHBaseクラスターでは、RegionServer間で集約された場合、構成されたL1ブロックキャッシュは61Gです。サーバーノードにはそれぞれ合計128GのRAMがあり、サーバープロセス専用ではないメモリをOSで使用して、基盤となるHDFSブロックを効果的にキャッシュし、全体的なスループットを向上させることができます。テスト構成では、この目的のために各リージョンサーバーノードで約96GのOSキャッシュを使用できます（データノードまたはOSプロセスが使用するメモリを無視して単純化します）。これを5つのリージョンサーバー全体で集計すると、バッファー（96G * 5リージョンサーバー）でほぼ500Gの可能性がありました。したがって、構成されたブロックキャッシュと使用可能なOSバッファキャッシュの両方を超える1TBのデータセットサイズを選択しました。

ターゲットデータサイズをYCSBパラメータに変換する

YCSBでは、行はデフォルトで1KBであるため、YCSBの「ユーザーテーブル」にロードする行数に応じて、YCSBの「ユーザーテーブル」テーブルのデータサイズを簡単に見積もることができます。したがって、100万行をアップロードすると、1,000,000 * 1KB=1GBのデータがYCSBの「ユーザーテーブル」にアップロードされます。

2つのテストに使用されたデータセットのサイズは次のとおりです。

• 40GBのデータ 4,000万行
• 1TBデータ 10億行

テスト方法

CDP Private Cloud Base 7.2.2が6ノードクラスターにインストールされ、4,000万行のワークロードデータ（合計データセットサイズ=> 40 GB）が生成され、YCSBワークロードが実行されました。ロード後、すべての圧縮操作が完了するのを待ってから、ワークロードテストを開始しました。

HBaseで実行されたYCSBワークロードは

1. ワークロードA：50％の読み取りと50％の更新
2. ワークロードC：100％読み取り
3. ワークロードF：50％読み取りおよび50％更新/読み取り-変更-書き込み比率：50/50
4. カスタム更新のみのワークロード：100％更新
   

各YCSBワークロード（A、C、F、およびUpdateOnly）はそれぞれ15分間実行され、YCSBスループット*を測定するために、実行の間に再起動せずに完全な実行が5回繰り返されました。示されている結果は、5回の実行から最後の3回の実行で取得された平均です。 1回目と2回目の実行のペナルティを回避するために、最初の2回のテスト実行は無視されました。

40GBの実行が完了したら、ユーザーテーブルを削除し、10億行を再生成して、1TBのデータセットサイズを作成し、同じクラスターで同じ方法でテストを再実行しました。

テスト結果

40GBのYCSB結果

40GBの場合、データはクラスター上の61GBL1キャッシュに完全に収まります。テスト中にクラスターで観察されたL1キャッシュヒット率は99％に近かった。

ヒント： データをキャッシュに収めることができる小さなデータセットの場合、ロード時のキャッシュオプションを使用し、テーブルオプションPREFETCH_BLOCKS_ON_OPENを使用してキャッシュを事前にウォームアップして100％のキャッシュヒット率を取得することもできます。

各YCSBワークロードを5回ごとに15分間実行し、最初の実行のペナルティを回避するために、最後の3回の実行の平均を取りました。

40G L1キャッシュヒット率99％で見られた結果 リージョンサーバーのサーバーを以下の表に示します。

1TBのデータセットを使用したYCSBの結果

1 TBの場合、データはクラスターの61GBL1キャッシュまたは500GBOSバッファーキャッシュに収まりません。テスト中に観察されたクラスターのL1キャッシュヒット率は82〜84％でした。

各ワークロードを5回ごとに15分間実行し、最初の実行のペナルティを回避するために、最後の3回の実行の平均を取りました。

1TBで見た結果 L1キャッシュヒット率82-84％ リージョンサーバーのサーバーを以下の表に示します。

*スループット（ops / sec）=1秒あたりの操作数

分析：

上記の2つの異なるデータセットサイズのテスト結果を比較すると、同じワークロードスループットが1秒あたり3K操作から1秒あたり165K操作までどのように変化するかがわかります。 ウォームアップされたキャッシュを使用した40Gデータセットから、hdfsストレージからよりも迅速にデータにアクセスする場合。

次のグラフは、スループットを示し、2つの異なるサイズのデータ​​セットで実行した場合に異なるワークロードでスループットがどのように変化したかを比較しています。グラフのバーが高いほど、スループットが向上します。

注：スループット=1秒あたりの操作数

グラフに示されているように、ワークロードA、ワークロードC、ワークロードFなどのデータを読み取るYCSBワークロードは、データがキャッシュに簡単に収まる40Gの場合と、HFileデータが必要な1TBのデータサイズの場合のスループットがはるかに優れていました。 HDFSからアクセス

キャッシュヒット率を見ると、40Gデータセットのキャッシュヒット率は99％に近く、1TBデータセットのキャッシュヒット率は約85％であるため、1TBの場合のデータの15％はhdfsストレージからアクセスされました。 。

実行したYCSBカスタム更新のみのワークロードは、更新のみを実行し、読み取りを実行しなかったため、どちらの場合も同じスループットでした。

HBaseのパフォーマンス中に、95パーセンタイルと99パーセンタイルのレイテンシーを詳しく調べます。平均遅延は、合計スループットを合計時間で割ったものですが、95パーセンタイルと99パーセンタイルは、合計ワークロードスループットに影響を与える実際の外れ値を示しています。 1 TBの場合、95パーセンタイルと99パーセンタイルの高遅延の外れ値によりスループットが低下し、40 GBの場合、99パーセンタイルの低遅延キャッシュヒットにより総スループットが向上します。

下のグラフは、平均レイテンシ、95パーセンタイルレイテンシ、99パーセンタイルレイテンシのレイテンシの比較と、さまざまなサイズのデータ​​セットで実行した場合のワークロードごとの違いを示しています。

上のグラフでは、hdfsからのデータにアクセスする1TBデータセットで観察されたレイテンシと比較して非常に低いため、40GBデータセットのレイテンシを表すバーを確認するのは困難です。

レイテンシ値のログを使用してレイテンシグラフをプロットし、下のグラフに違いを示しました

上記のように、キャッシュヒット率が99％に近く、ほとんどのワークロードデータがキャッシュで利用できる40GBの場合、レイテンシははるかに低くなります。 1TBのデータセットと比較すると、HFileデータはHDFSストレージからアクセスする必要があるため、キャッシュヒット率は約85％でした。

ウォームアップされたキャッシュから99％のデータが返される40Gの場合のワークロードCの平均および99レイテンシは、約2〜4ミリ秒でした。 1TBの場合の同じワークロードCの99パーセンタイル遅延は、ワークロードC（読み取り専用ワークロード）で約100ミリ秒でした。

これは、オンヒープブロックキャッシュからのキャッシュヒットが約2ミリ秒で読み取りを返し、キャッシュミスとHDFSからのレコードの取得にこのクラスターで約100ミリ秒かかる可能性があることを示しています。

推奨事項：

YCSBベンチマークテストを実行する場合、データセットのサイズによってパフォーマンス結果に大きな違いが生じるため、テストのサイズを適切に設定することが非常に重要です。同時に、最小レイテンシと99番目のレイテンシのキャッシュヒット率とレイテンシの違いを確認すると、クラスター内の基盤となるストレージからデータにアクセスする場合と比較して、キャッシュヒットのレイテンシを見つけるのに役立ちます。

ヒント：

リージョンサーバー上のワークロードのキャッシュヒット率を確認するには、次のコマンドを使用できます

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

以下の手順に従って、HBaseWebUIからキャッシュヒット率を表示することもできます。

1. HBaseWebUIからリージョンサーバーをクリックします
2. [キャッシュのブロック]セクションで、L1（およびL2が構成されている場合はL2）を選択して、キャッシュヒット率を確認します。

L1ブロックキャッシュからのキャッシュヒット率を示すスクリーンショットを以下に示します。

上記のHBaseスクリーンショットとブロックキャッシュに関する詳細情報へのリンクは次のとおりですhttps://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html

YCSBについて

YCSBは、コンピュータープログラムの取得および保守機能を評価するためのオープンソース仕様およびプログラムスイートです。これは、NoSQLデータベース管理システムの相対的なパフォーマンスを比較するために使用される非常に人気のあるツールです。

YCSBを使用してオペレーショナルデータベースのパフォーマンスをテストするには、ブログHBaseでYCSBを実行する方法を確認してください。