1つは、HBaseテーブルの作成例です
「win_kangll_day」というテーブルが次のように作成されます。テーブルには「d」と「t」の列ファミリーが1つだけあり、次の属性はすべてこの列ファミリーの設定です。これらの属性は基本的に、テーブルの読み取りと書き込みのパフォーマンスに多少なりとも影響します。「win_kangll_day」の作成では、データ圧縮、データエンコーディング、事前パーティション化、およびその他の属性設定を使用します。
create 'win_kangll_day',{NAME=>'d',VERSIONS => 1,COMPRESSION=>'SNAPPY',DATA_BLOCK_ENCODING => 'FAST_DIFF'},{SPLITS=> ['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']}
alter 'win_kangll_day', {NAME => 't',VERSIONS => 1,COMPRESSION=>'SNAPPY',DATA_BLOCK_ENCODING => 'FAST_DIFF'},{SPLITS=> ['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']}2.テーブル作成で使用される属性の概要
2.1。データ圧縮
データ圧縮はHBaseが提供するもう1つの機能です。HBaseがデータブロックをHDFSに書き込む前に、まずデータブロックを圧縮してからディスクに配置します。これにより、ディスクスペースの使用量を減らすことができます。データを読み取るとき、ブロックは最初にHDFSからロードされ、次に解凍され、次にBlockCacheにキャッシュされ、最後にユーザーに返されます。書き込みパスと読み取りパスは次のとおりです。
上の図と組み合わせて、データ圧縮がリソース使用量と読み取りおよび書き込みパフォーマンスに与える影響を見てみましょう。
（1）リソース使用量：圧縮の最も直接的で重要な機能は、データハードドライブの容量を減らすことです。理論的には、スナッピーな圧縮率は5：1に達する可能性がありますが、テストデータによっては、圧縮率が理論的に理想的でない場合があります。 ;圧縮/解凍には間違いなく多くの計算と多くのCPUリソースが必要です;読み取りパスによると、データがキャッシュに読み込まれる前にブロックブロックが解凍され、メモリにキャッシュされたブロックが解凍されるため、比較されます非圧縮状態では、基本的にメモリの前後に影響はありません。
（2）読み取りと書き込みのパフォーマンス：データ書き込みは、最初にkvデータ値をキャッシュに書き込み、最後にフラッシュハードディスクを統合することであり、圧縮はフラッシュ段階で実行されるため、フラッシュ操作に影響します。書き込みパフォーマンス自体はそれほど影響はありません。データをHDFSから読み取る場合は、最初に解凍する必要があるため、理論的には読み取りパフォーマンスが低下します。データがキャッシュから読み取られる場合は、キャッシュすでに解凍されているため、パフォーマンスに影響はありません。一般に、ほとんどの読み取りはホットリードであり、キャッシュされた読み取りが大部分を占め、圧縮は読み取りに大きな影響を与えません。特定のリファレンス：HBase2.2ドキュメント
圧縮機能はディスクスペースリソースと引き換えにCPUリソースを使用し、読み取りと書き込みのパフォーマンスにはあまり影響を与えないことがわかります。HBaseは現在、一般的に使用される3つの圧縮方法を提供しています：GZip | LZO | Snappy次の表は、圧縮率とコーデック率の公式比較です。
2.2。エンコード/デコード
HBaseは、データ圧縮に加えて、データエンコーディング機能も提供します。圧縮と同様に、KVデータはデータがディスクに配置される前にエンコードされますが、圧縮とは異なり、データブロックはキャッシュされる前にデコードされないため、キャッシュにヒットする後続のクエリもエンコードされたデータブロックであり、デコードする必要があります。特定のKVデータを取得します。書き込みパスと読み取りパスは次のとおりです。
同様に、データ圧縮がリソース使用量と読み取りおよび書き込みパフォーマンスに与える影響を見てみましょう。
（1）リソースの使用：圧縮と同様に、エンコードの最も直接的で重要な機能は、データハードドライブの容量を減らすことですが、データ圧縮率は一般にデータ圧縮ほど高くなく、理論的には5：2です。 / decodeも一般的に多くの計算が必要であり、多くのCPUリソースが必要です。読み取りパスによると、データがキャッシュに読み込まれる前にブロックブロックはデコードされません。メモリにキャッシュされたブロックはエンコードされます。したがって、エンコードされていない場合と比較して、同じデータブロックの高速化はより少ないメモリを消費します。つまり、より高いメモリ使用率です。
（2）読み取りおよび書き込みパフォーマンス：データ圧縮と同様に、データエンコードもhdfsステージへのデータフラッシュで実行されるため、書き込みプロセスに直接影響しません。前述のように、データブロックはエンコードされた形式でブロックキャッシュにキャッシュされます。したがって、同じサイズのブロックキャッシュはより多くのデータブロックをキャッシュでき、読み取りパフォーマンスに役立ちます。一方、ユーザーはキャッシュからデータブロックをロードした後、KVを直接取得することはできませんが、最初にそれをデコードする必要があります。これは、読み取りパフォーマンスにつながりません。十分なメモリがある場合、データエンコーディングによって読み取りパフォーマンスが低下することがわかります。また、メモリが不足している場合は、特定の結論を引き出すためにテストが必要です。
HBaseは現在、一般的に使用される4つのエンコード方法を提供しています：Prefix | Diff | Fast_Diff | Prefix_Tree
2.2.1。どのタイプのコンプレッサーまたはデータブロックエンコーダー（公式）が
使用するかは、データの特性によって異なります。間違ったタイプを選択すると、データが占めるスペースが少なくなるのではなく、多くなり、パフォーマンスに影響を与える可能性があります。
一般に、スペースを小さくするか、圧縮/解凍を高速化するかを選択する必要があります。以下は
、圧縮とコーデックに関するドキュメントでガイドされているいくつかの一般的なガイドラインです。
- （値と比較して）長いキーまたは複数の列がある場合は、プレフィックスエンコーダーを使用します。FAST_DIFFを使用することをお勧めします。
- 値が大きい場合（画像などの事前圧縮されていない場合）は、ブロックコンプレッサーを使用します。
- 頻繁にアクセスされないコールドデータにはGZIPを使用します。GZIP圧縮は、SnappyやLZOよりも多くのCPUリソースを使用しますが、より高い圧縮率を提供します。
- 頻繁にアクセスされるホットデータには、SnappyまたはLZOを使用します。GZIPと比較して、SnappyとLZOはCPUリソースをあまり使用しませんが、圧縮率は高くありません。
- ほとんどの場合、SnappyまたはLZOをデフォルトで有効にすることは、パフォーマンスのオーバーヘッドが低く、スペースを節約できるため、適切な選択です。
- Snappyが2011年にGoogleによってリリースされる前は、デフォルト値はLZOでした。Snappyの品質はLZOと似ていますが、パフォーマンスが向上しています
2.3。事前パーティション化
2.3.1。なぜ事前パーティション化するのか
- データの読み取りと書き込みの効率を高め、さまざまな地域にデータを書き込みます
- データの偏りを防ぎ、ホットな問題の読み取りと書き込みを防ぐための負荷分散
- クラスター災害復旧スケジューリング領域を促進する
2.3.2。事前パーティション化の方法
各リージョンはstartRowとendRowKeyを維持します。追加されたデータが特定のリージョンによって維持されるrowKey範囲を満たす場合、データはメンテナンスのためにこのリージョンに渡されます。
次の例は、手動による事前パーティション化です。
create 'win_kangll_day',{NAME=>'d',VERSIONS => 1,COMPRESSION=>'SNAPPY',DATA_BLOCK_ENCODING => 'FAST_DIFF'},{SPLITS=> ['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']}