6

TokuDBにあるようなフラクタルツリーインデックスについて学んでいます。私は、ほとんどの場合CPUキャッシュに書き込み、低速のRAMメモリに書き出すことはめったにないため、書き込みを高速化するために使用する戦略に魅了されています。ただし、フラクタルツリーインデックスは、最終的にRAMへの大きな書き込みを実行し、次にディスクへの巨大な書き込みを実行し、次にディスク上で完全に巨大な書き込みを実行する必要があります。私が混乱するのはここです。フラクタルツリーインデックスはこれを効率的に行うことができますか？たとえば、Bツリーが最悪のシナリオの更新でディスクを更新できるよりも効率的ですか？また、ディスク上の巨大な書き換えは、そのデータのルックアップ時間にどのような影響を及ぼしますか？また、その逆に、そのデータに対していくつかのルックアップを実行すると、巨大な書き換えのプロセスにどのような影響がありますか？

これに答えるためのコンテキストとして、次のことを知っておく必要があります。

  • このスライドプレゼンテーションで学んだフラクタルツリーインデックスについて学んだことはすべて
  • 回転する中型ハードドライブがどのように機能するかについての良いメンタルモデルがありません。
  • 「ジャイアントリライト」と言うと、基本的には、同じ長さ（サイズ）の2つの並べ替えられた配列があり、2^largeNumberそれらを並べ替えられた1つの配列（サイズ）に書き込むということです2^(largeNumber+1)。
4

1 に答える 1

4

http://www.youtube.com/watch?v=88NaRUdoWZMで私のビデオを視聴することをお勧めします。これにより、フラクタルツリーインデックスがどのように機能するかをよりよく理解できる可能性があります。インデックスがメインメモリに収まらない場合、フラクタルツリーインデックスはメッセージの大きなグループをバッファリングでき、バッファがオーバーフローするとツリーをゆっくりと押し下げます。最終的にリーフノードに到達すると、リーフを取得してすべてのメッセージを適用するための単一のIOがあります。フラクタルツリーインデックスは、単一のIO全体で多くの操作を集約し、書き込みが高度に圧縮されるため、書き込みIOが大幅に少なくなります。高度に圧縮されたデータを読み取るため、読み取りIOも大幅に削減されます。

これがあなたの質問に完全に答えるかどうかはわかりませんが、うまくいけば役立つでしょう。

于 2012-09-14T02:07:55.443 に答える