1、テーブルデザイン
- 事前作成領域（事前分割）
- デフォルトでは、自動的にあなたが地域HBaseのテーブルのパーティションを作成するときにデータをインポートする場合、すべてのHBaseのクライアントは、この領域が十分な大きさであり、我々はセグメント化する必要があるまで、領域にデータを書き込むために作成しました。データはHBaseのに書き込まれたとき、クラスタ内の領域分割、ロード・バランシング・データに追従するように、空き領域の一部を、事前に作成されたを通してバルク書き込み速度を高速化する方法です。
- rowKey：HBaseのはのrowKeyにどのような三つの方法をサポートするために、テーブル内のレコードを取得するために使用します
- 単一のrowKeyを経由してアクセス：つまりのrowKeyキーに従ってもらいます
- スキャンは、範囲のrowKeyによって行われる。startRowkeyとendRowkeyによって、この範囲内でスキャンします
- 全表スキャン：すべての行は、直接である、テーブル全体をスキャン
- rowKeyにHBaseのは、任意の文字列、64Kの最大長さは、一般的に10〜100bytes、固定長のための一般的な設計とすることができます
- rowKeyルール
- 小さく、より良いです
- rowKeyは、実際のビジネスに基づいてされるように設計されて
- のハッシュ：
- 否定
- ハッシュ
- 列ファミリ
- HBaseの中で定義されたテーブルの列ファミリーの多くを行います。HBaseのは、現在も2〜3列ファミリーテーブルよりも多くを処理できません。フラッシュ時のカラムファミリーので、最終的にシステムがより多くのI / Oを生成させ、フラッシュを開始するために、隣接する列ファミリー関連効果であろう
- メモリには：キャッシュにRSテーブルにHColumnDescriptor.setInMemory（真）で、テーブルを作成するときは、読んだときにはchacheを打つことを確認することです
- 最大バージョン：あなたがテーブルを作成するとき、あなたは、テーブル内のデータのHColumnDescriptor.setMaxVersions最大バージョン（int型maxVersions）を設定することができ、データのみの最新バージョンを保存する場合は、（1）setMaxVersionsを設定することができます
- 生きるための時間：あなたがテーブルを作成するときは、テーブルのストレージライフサイクルにデータを設定することができ、国有企業のデータは自動的にHColumnDescriptor.setTimeToLive（int型のTimeToLive）によって削除されるだけのデータの最後の2日間を格納する必要がある場合、たとえば、あなたがにsetTimeToLiveを設定することができます（2 * 24 * 60 * 60）
- コンパクト＆スプリット：
- WALログ（ハント）とメモリ（MemStore）を更新するときのHBaseでは、データが最初に書き込まれ、データがmemstoreが一定のしきい値に蓄積Memstoreを、ソートされ、それが新しいMemstoreを作成し、 StoreFileになるために、ディスクに別のスレッドによってフラッシュ古いMemstore権を、フラッシュする追加。同時に、システムは飼育係内のREDOポイントを記録し、この時間は（マイナーコンパクト）の持続性となっている前に、変化を表しています。
- StoreFileは読み取り専用で、一度作成した、それはで変更することはできません。だから、実際には、それが常にHBaseの追加の操作を更新しています。ストアがStoreFileが一定の閾値に達したとき、それは（主要なコンパクト）マージが実行され、キーで修飾さ、大きさが一定の閾値StoreFileに達したときに、大きなStoreFileを形成するために一緒にマージしますこれは、2つのstoreFileに分けstoreFile分割（スプリット）、に戻りました。
- テーブルは常にのrowKeyに従って彼らの合併のすべてのstoreFileとmemstoreストアへのアクセスを必要とする追加の処理読み取り要求に更新されているので、原因storeFileとMemstoreは、通常、メモリと、ソートされたインデックス化されているstoreFile統合プロセスは比較的高速であります
- 実際には、小型手動主要な、必要に応じて、より大きなstoreFile同じ変形を形成するために結合されるのrowKey考えることができます。storeFileが大きく設定されている間、スプリットの発生率を減らします
- HBaseの小さなファイルを防ぐためには、クエリの効率性を確保するためには、あまりにも多くの（ディスクmemstoreを磨くために）、HBaseの彼らは、このプロセスがコンパクトと呼ばれ、これらの小さなstoreFile比較的大きなstoreFileにマージされますときに必要。マイナー圧縮と大きな締固め：HBaseのでは主にコンパクトの2種類があります
- マイナーコンパクション：小さく、めったにファイルをマージしません
- 主要な圧縮：storeFileすべてが一つに統合され、主要な圧密条件を引き起こす可能性がある：major_compactコマンド、majorCompact（）API、RS自動運転（パラメータ：hbase.hregion.majorcompactionのデフォルトは24時間、hbase.hregion.majorcompactionです。同時に、主要な締固めRSを防ぐために、0.2ジェッターのデフォルト）
- hbase.hregion.majorcompaction.jetter効果：フローティング機能は、2つのパラメータはデフォルト値0.2及び24である場合、主要なコンパクト最終値が使用され、所定のパラメータ値をhbase.hregion.majorcompaction：19.2から28.8このスコープ
- 自動主要な圧縮をオフにします
- マニュアルプログラミングの主要な圧縮
- より複雑なマイナーな圧縮操作機構、それがどのようないくつかのパラメータによって決定されます。
-
hbase.hstore.compaction.min ：デフォルトは3で、少なくとも三つの条件ストアファイルを満たすために必要性を表明、マイナーな圧縮は起動しません
-
hbase.hstore.compaction.maxの デフォルト値は、10で10に選択ストアファイルにマイナーな圧縮を表し
-
hbase.hstore.compaction.min.sizeは、 ファイルサイズがマイナーな圧縮で保存ファイルに追加される値ストアファイルよりも小さくなっていることを示しています
-
hbase.hstore.compaction.max.sizeは、 ファイルサイズが値ストアファイルよりも大きいことを示し、マイナーな圧縮を除外されます。
-
hbase.hstore.compaction.ratioは、 年齢に応じたファイルのソートファイルを格納します（と兄は弟）、マイナーな圧縮は常に古いストア・ファイルから選択を開始します
図2に示すように、書き込み動作テーブル
-
複数の同時書き込みHTable
- HTableパラメータ設定
- オートフラッシュ：あなたはHBaseのバッチにデータを書き込むのではなく、プットの実装上の更新を持つことができますので、HTable.setAutoFlush（偽）は、クライアントが書き込みキャッシュを満たした場合にのみ置く、唯一の実際のHBaseを自動フラッシュクライアントをオフにサーバーの起動魅力を書きます。デフォルトの自動フラッシュがオンになっています
- バッファを書く：新しく設立されたバッファはバッファ内の現在の書き込みデータよりも小さい場合、クライアントのバッファサイズを設定し、バッファは、サーバーへのフラッシュになります
- WAL旗
- 注意：クローズWALログを慎重に選択し、このために、RSがダウンした場合、入れ/削除データはWALログに応じて回復することができません。
- 一括書き込み
- マルチスレッドを書きます
3、テーブルの読み取り
- スキャンのキャッシング
- HBaseの設定ファイルはconfにあります
- HTable.setScannerCachingを呼び出すことにより構成されました（）
- scan.setCachingを呼び出すことにより構成されました（）
- ほかの三の優先度よりシニア
- バッチ読取り
- マルチスレッド読み取り
- キャッシュのクエリ結果
- ブロックキャッシュ
- メモリは、主に読み取りのため、部分BlockCacheながら、主に書き込むために使用される部品memstoreとして、HBaseの上の2つの部分RSに分割されています
- 書き込み要求は、最初memstoreを書きます、RSは、各地域にmemstoreフル64Mは、ディスクへのフラッシュフラッシュを開始しますmemstoreを、提供します。場合（HEAPSIZE * hbase.regionserver.global.memstore.upperlimit * 0.9）合計サイズが上限を超えmemstore、限界未満フラッシュまで開始memstore最大から、フラッシュ処理を開始することを余儀なくされます
- まずmemstoreがBlockCacheのチェックを見つける、データを検索するための要求を読んで、それを読むためにディスクを見つけ、その結果BlockCacheを置くことはありません。LRU方式を使用してBlockCache起因した後、従ってBlockCacheは、オンライン達成する（ヒープサイズ* hfile.block.cache.size * 0.85）、データの最も古いバッチを排除する、除去機構を開始します
- そこ1 RS BlockCacheとN Memstoreであり、その大きさは0.8 *以上ヒープサイズではない、またはHBaseのが起動しません。デフォルトはBlockCache 0.2、memstore 0.4です。読み出し応答時間集束システムのために、BlockCacheは、キャッシュヒット率を高めるために、より大きな、例えばBlockCache = 0.4、memstore = 0.39を設定することができます