事前パーティションとHBaseのののrowKeyのHBaseの設計原理
1、HBaseのプリパーティション
1.1なぜ事前パーティション？
- データの読み書きの効率を高めます
- ロードバランシング、データが防止スキュー
- 災害復旧クラスタスケジューリング地域を促進します
- 数マップを最適化
1.2どのように事前にパーティションをするには？
メンテナンスの領域のrowKey範囲、この領域に保守情報に沿ったデータに付加された場合は、各領域には、startRow属性とendRowKeyを維持します。
1.3は、どのように事前にパーティションを設定するには？
1.3.1、手動で事前パーティションを指定
hbase(main):001:0> create 'staff','info','partition1',SPLITS => ['1000','2000','3000','4000']
図の完了後：
1.3.2 16進数を生成するために、事前分割アルゴリズムを使用して
hbase(main):003:0> create 'staff2','info','partition2',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
図の完了後：
1.3.3、ファイルで作成したルールをゾーニング
次のようにファイルの作成splits.txt内容は以下のとおりです。
cd /export/servers/
vim splits.txt
編集：
aaaa
bbbb
cccc
dddd
その後、実行します。
hbase(main):004:0> create 'staff3','partition2',SPLITS_FILE => '/export/servers/splits.txt'
成功の図の後に：
1.3.4、事前パーティションはのにJavaAPIを使用して作成されます
次のようにJavaコードは次のとおりです。
/**
* 通过javaAPI进行HBase的表的创建以及预分区操作
*/
@Test
public void hbaseSplit() throws IOException {
//获取连接
Configuration configuration = HBaseConfiguration.create();
configuration.set("hbase.zookeeper.quorum", "node01:2181,node02:2181,node03:2181");
Connection connection = ConnectionFactory.createConnection(configuration);
Admin admin = connection.getAdmin();
//自定义算法，产生一系列Hash散列值存储在二维数组中
byte[][] splitKeys = {{1,2,3,4,5},{'a','b','c','d','e'}};
//通过HTableDescriptor来实现我们表的参数设置，包括表名，列族等等
HTableDescriptor hTableDescriptor = new HTableDescriptor(TableName.valueOf("stuff4"));
//添加列族
hTableDescriptor.addFamily(new HColumnDescriptor("f1"));
//添加列族
hTableDescriptor.addFamily(new HColumnDescriptor("f2"));
admin.createTable(hTableDescriptor,splitKeys);
admin.close();
}
rowKeyの2、HBaseのデザインのスキル
HBaseの三次元ストレージ,,列キー（列ファミリーと修飾子に）タイムスタンプ（タイムスタンプ）を素早くのrowKey（行キー）でのHBaseのデータを見つけることができ、この3つの次元を命じました。
：のrowKeyでHBaseの一意の行、HBaseのクエリ、次のように識別する
のrowKey指定一意のレコード取得し、元のGETにより1.
2.スキャンモードを、設定startRow属性範囲マッチングパラメータstopRow
3.フル表スキャン、すなわち、すべての行が直接表全体をスキャン
2.1のrowKey長原理
owkeyバイナリストリームであり、任意の文字列、64キロバイトの最大長さ、一般的に、バイト[]形式で保存10-100bytes実用的なアプリケーションは、典型的には固定された長さに設計することができます。それは短く、より良い、ではない16の以上のバイトをすることをお勧めします次のような理由から、：
- HFILE永続データファイルはです。KeyValueに従って格納されている、のrowKey長すぎる場合、例えばより100バイト、データライン1000Wよりも、光のrowKeyは、これは非常になり、100 *千ワット= 10ギガバイト、約1Gのデータを占有します大規模なストレージ効率HFILEの影響。
- rowKeyフィールドが長すぎる場合MemStore部分データキャッシュメモリは、メモリの有効利用が低下し、システムがないキャッシュより多くのデータが、これは検索効率が低下しますすることができます。
2.2のrowKeyハッシュ原則
rowKeyようにタイムスタンプインクリメントは、バイナリコードの前にいない時、場合上部のrowKeyとしてランダムにプログラムすることによって生成されたハッシュフィールドを、推奨され、均等に各リージョンサーバーに分散されたデータを改善する低放電時間フィールド、ロードバランシングを実現するチャンス。無ハッシュフィールド場合、最初のフィールドは、データの取得は、ホット問題を引き起こし、個々のリージョンサーバーに焦点を当てるように負荷が、クエリの効率を低下させる際に、直接、すべてのデータがリージョンサーバーに集中される時刻情報です。
唯一の原則のrowKey 2.3
この種の特性を最大限に活用するために、時間のrowKeyを設計し、のrowKeyしたがって、辞書順でソートストレージのある、デザインに独自性を確認する必要があり、多くの場合、読み込みに格納されたデータ、最近アクセスすることができます1にデータ。
2.4暑いとは何ですか
HBaseの行は、辞書のrowKeyスキャン動作のこの設計の最適化、および関連する行線の順序付けされた隣接する位置に一緒に読み出されるスキャン容易にするために、アクセスされてもよいです。しかし、悪いのrowKeyのデザインは、ホットソースです。
ホットスポットは、クラスタまたはノードの非常に小さな数（アクセスが読み出し、書き込みまたは他の操作であってもよい）へのクライアントの直接アクセスの多数発生します。ホストは、他の地域のからのサービス要求にできないため、単一のマシンはその容量、パフォーマンスの低下、さらには地域を超えたアクセスが利用できないホットスポット領域を大量に作るだろう、これはまた、同じリージョンサーバー上の他の地域に影響を与えます。
うまく設計されたデータ・アクセス・パターンクラスタがいっぱいになるように、バランスの取れ使用。熱い書き込みを避けるために、デザインは同じ地域の異なるラインを作るのrowKeyが、より多くのデータでは、データではなく一つで、複数のクラスタ領域に書き込む必要があります。ここでは、ホットスポットとその利点と欠点を回避するために、いくつかの一般的な方法は以下のとおりです。
2.4.1、塩
塩は、ここに記載の暗号化塩ではなく、特にフロントのrowKeyランダム数の増加は、そののrowKey異なるの開始前にランダムのrowKeyプレフィックスにしていることを割り当てられています。プレフィックスと種の分布の数は、同じ番号の別の領域を使用するデータに分権化されなければなりません。rowKey分散液を塩析した後、ホットスポットを回避するために、それぞれの領域に応じてランダムに生成された接頭辞であろう。
2.4.2ハッシュ
ハッシュは、常に接頭辞と同じ行を塩します。ハッシュは、クラスタ間で負荷を分散さが、それを読んだことは予測可能であることができます。決定したハッシュを使用すると、クライアントがのrowKeyの再構築を完了することができます、あなたは、データの1行だけを取得するように設定することができます。
2.4.3、逆
ホットスポットを防止する第3の方法では、固定長またはデジタル形式を逆のrowKey。これは、常に手前に変化する部分（最下位部分）のrowKeyになります。これは、効果的にランダムのrowKeyことができますが、注文のrowKeyの犠牲に。
逆電話番号の文字列の後に電話番号のrowKeyと逆のrowKeyの例は、のrowKeyとして使用される固定ホット問題の始まりでの比較結果として、携帯電話番号を避けるようにしてもよいです
例：逆TIMESTAMP
- 、例えばキーの最後に追加タイムスタンプ、一般的なデータ処理の問題は、データへの迅速なアクセスの最新バージョンは、この問題のために非常に便利なのrowKeyの一環として、逆タイムスタンプの使用は、あなたがはLong.MAX_VALUEを使用することができるということです[キー] [reverse_timestamp]、[キー] のrowKeyのHBaseが発注されるので、[キー]を取得する最初のレコードスキャン[キー]の最新値、最初のレコードは、最後のデータが入力されます。
他のいくつかの提言：
永遠に一緒にHBaseの、値とそのキーの伝送に行と列のキー家族のサイズを最小にします。伝送システムとの間の特定の値は、それのrowKey場合、列名は、タイムスタンプも併せて送信されます。あなたの列名がのrowKeyと大きな場合は、この時間は、彼らは、ストレージスペースの多くを取るでしょう。
好ましく文字、できるだけ短いなどのカラム家族。
良い可読性しかし長いプロパティ名が、それは短い属性名が格納されているのHBaseに良くなります。
----------------------------------------------------------------------------------------------------
上記の内容は、ああ、ここで終わりにします。読者のトリプル小扁は、電源ああに固執することです！上記のエラーの対象となっている、我々は最高の関係は相互の成果であるタイムリー助け正しいああ!!!小さなシリーズを歓迎し、我々は次の問題を参照してください。
私は少し反乱軍、キーChuanトレーニング大学生です。プログラミング業界アマチュア...ハッハッハ
| 考えずに学ぶことは学習のない考えは危険で、労働力が失わです。 |
