Tair LDB Prefixkeyの範囲に基づいてパフォーマンス最適化プロジェクトの提案案を検索


prefix bloomfilterに基づくフィルタリング思想とget_rangeインタフェースのデータの特徴は、指導者の指導の下で、以下の簡単な方案を提出して、get_rangeインタフェースの範囲検索プロセスを最適化し、prefixに基づいてフィルタリングを行い、無効なディスクIOを低減することができる.
最適化対象インタフェース
int get_range(int area, const data_entry &pkey, const data_entry &start_key,   
    const data_entry &end_key, int offset, int limit, vector<data_entry*> 
    &values,shorttype=CMD_RANGE_ALL);

提案案
1.get_のためrangeインタフェースのデータはprefix_からput/prefix_incrインタフェースが入ってくるとprefixの長さ情報はそれらのpkeyパラメータから得ることができ、pkeyのデータ型はdata_である.entry、属性prefix_がありますsizeでは、クライアントがpkeyとskeyをmkey(mkeyのprefix_sizeがpkeyのsizeに設定されている)に統合した後、valueとともにサーバ側に転送します.
クライアントとサーバ側の接続中にkeyのタイプをLdbKeyクラス、valueのタイプをLdbItemクラス、LdbItemにkeyのprefix_を含むsize情報は、その後、両方がSliceタイプに変換されてleveldbの最下位層に送信されて記憶動作を行う.注意valueにはprefixが含まれていますszie情報(シーケンス化情報、直接抽出できない)のため、filter blockを生成する際にvalueからprefix_を抽出できます.size情報(LdbItem形式で分析抽出)を使用して、必要なprefix bloomfilterを生成します.抽出された具体的な実装はleveldbレイヤの外に置くことができ,leveldbの中で呼び出すことができる(分離操作).
2.prefix_に抽出size情報の後、私たちはすべてのkeysに対してprefix bloomfilterを実現し、簡単を実現するために、私たちは既存のfilter blockに新しいprefix bloomfilterを加えることができて、既存のbloomfilterと一緒に保存して、方法も簡単で、元のfilter block buildingの過程(filter_block.cc)で、keyのprefixも普通のkeyとして一緒にfilterに参加して、両者のフィルタリングアルゴリズムも一致している.
注意:現在、filterの作成はキーを追加するたびにbits_が大きくなります.per_key_個のビットですが、keysのprefixの一部は同じであり、filterに繰り返し追加されることもないので、最終的に増加したbitsは許容できるはずです.
3.get_rangeインタフェースで、sstableが見つかった場合(まずmemtableとimmutable memtableを調べ、両者はディスクIO操作がない)、(1)まず[pkey+skey,pkey+end]の範囲に基づいて可能なsstfilesを検索する.
(2)fileごとにdataindex blockの情報を範囲検索し続け,[pkey+skey,pkey+end]という範囲を含む可能性のあるblocksを見つける.
(3)各blockを読む前に、filter blockに格納されているfilterを取得し、prefixのMayMatch法によりそのblockにプレフィックスpkeyが含まれているか否かを判断し、含まれていない場合はこのblockを直接スキップすることでprefix bloomfilterによりblockフィルタリングを実現し、不要なディスクIO操作を低減する.
get_についてrangeインタフェースの現在の実装方法を参照してください.
tairでget/get_rangeインタフェースの理解とget_rangeコマンドラインテストインタフェースの追加