sql >> データベース >  >> NoSQL >> HBase

HBaseコンパクションとは何ですか?

    圧縮モデルは、CDH 5 /HBase0.96で大幅に変更されています。知っておくべきことは次のとおりです。

    Apache HBaseは、ログ構造のマージツリーに基づく分散データストアであるため、ストアごとに1つのファイル(列ファミリー)のみを使用することで、最適な読み取りパフォーマンスが得られます。ただし、その理想は、大量の着信書き込みの期間中は不可能です。代わりに、HBaseはHFileを組み合わせて、読み取りに必要なディスクシークの最大数を減らしようとします。このプロセスは圧縮と呼ばれます 。

    コンパクションは、リージョン内の1つのストアからいくつかのファイルを選択し、それらを結合します。このプロセスでは、入力ファイルのKeyValueを読み取り、削除されておらず、存続時間(TTL)内であり、バージョン数に違反しないKeyValueを書き出します。新しく作成された結合ファイルは、リージョン内の入力ファイルを置き換えます。

    これで、クライアントがデータを要求するたびに、HBaseは、入力ファイルからのデータがディスク上の1つの連続したファイルに保持されていることを認識します。したがって、必要なシークは1つだけですが、以前はファイルごとに1つ必要でした。ただし、ディスクIOは無料ではありません。注意を怠ると、データを何度も書き換えると、深刻なネットワークとディスクのオーバーサブスクリプションが発生する可能性があります。言い換えると、圧縮とは、ディスクIOの一部を、後でシークを減らすために交換することです。

    この投稿では、CDH 4での圧縮の使用と影響、およびCDH 5での圧縮モデルの変更(HBase 0.96に基づいて再構築されます)について詳しく学習します。

    CDH4での圧縮

    理想的な圧縮では、今後の読み取りで最も多くのシークを減らすファイルを選択すると同時に、必要なIOの量が最も少ないファイルを選択します。残念ながら、その問題は将来の知識がなければ解決できません。そのため、HBaseが努力すべき理想であり、これまでに実際に達成できるものではありません。

    不可能な理想の代わりに、HBaseはヒューリスティックを使用して、ストア内のどのファイルが適切な候補である可能性が高いかを選択しようとします。ファイルは、同じようなファイルを同じようなファイルと組み合わせる必要があるという直感に基づいて選択されます。つまり、ほぼ同じサイズのファイルを組み合わせる必要があります。

    HBase 0.94(CDH 4で出荷)のデフォルトポリシーは、HFileのリストを調べて、すべてのファイルの合計にhbase.store.compaction.ratioを掛けたサイズよりも小さいサイズの最初のファイルを見つけようとします。そのファイルが見つかると、HFileと、シーケンスIDが小さいすべてのファイルが圧縮対象として選択されます。

    最大のファイルが最も古いというデフォルトの場合、このアプローチはうまく機能します:

    ただし、ファイルの経過時間とサイズの相関関係に関するこの仮定は、場合によっては誤りであり、現在のアルゴリズムが最適ではないものを選択することになります。むしろ、バルクロードされたファイルは、通常フラッシュされるHFileとは非常に異なる方法でソートされる可能性があり、場合によっては異なるため、優れた例になります。

    CDH5での圧縮の変化

    最近、圧縮が大幅に変更されました。 HBase0.96およびCDH5では、ファイル選択アルゴリズムがHBASE-7516を介して構成可能になりました。そのため、ユーザー指定の圧縮ポリシーを使用できるようになりました。この変更により、経験豊富なユーザーが圧縮を実行する方法をテストおよび反復できるようになります。

    デフォルトの圧縮選択アルゴリズムもExploringCompactionPolicyに変更されました。このポリシーは、提案された圧縮内のすべてのファイルが指定された比率内にあることを保証するという点で、古いデフォルトとは異なります。また、圧縮率の範囲内のサイズを持つ最初のファイルセットを選択するだけではありません。代わりに、ルールに違反しない可能性のあるすべてのセットを調べてから、予想される最小量のIOに対して最も影響力があると思われるものを選択します。そのために、ExploringCompactionPolicyは、比率内のほとんどのファイルを削除する圧縮を選択します。同点の場合は、サイズが小さいファイルのセットが優先されます。

    今後のリリースでは、階層型圧縮、ストライプ圧縮、レベルベースの圧縮など、さらに多くの変更が計画されています。

    結論

    一部のユースケースでは、この作業はまったく影響を与えません。圧縮はすでにかなりよく研究されているので、それは良いことです。ただし、トラフィックスパイクが大きいユーザーやバルクロードを使用するユーザーの場合、この作業により、IO待機時間とリクエストレイテンシが大幅に改善されます。特定のバルクロードのユースケースでは、圧縮によりディスクIOが90%減少しました。

    HBaseのPerfTestCompactionPoliciesのテストケースの結果は次のとおりです。

    お近くのクラスターに関しては、CDH 5(この記事の執筆時点ではベータ版)でこの作業を確認してください。

    参考資料:

    • 圧縮ポリシーの調査
    • https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
    • https://issues.apache.org/jira/browse/HBASE-7516
    • https://issues.apache.org/jira/browse/HBASE-7678
    • https://issues.apache.org/jira/browse/HBASE-7667
    • https://issues.apache.org/jira/browse/HBASE-7055
    • http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/

    1. 2つのモジュールで同じredis接続を使用する必要がありますか? (私はFlaskを使用しています)

    2. そのjavaドライバーでのMongoDbの$set相当

    3. セロリはピアによって接続をリセットします

    4. predisでredisタイムアウト