Orientdb: ハッシュインデックスのビッグデータサポート

現在のハッシュインデックスの実装では、読み取りに1つのI / Oのみが必要であり、書き込みの場合は最大3つのI / Oが必要ですが、それでもランダムなI / Oのオーバーヘッドに悩まされています。 平均的なランダムI / Oには20ミリ秒かかりますが、非常に遅いです。 現在の書き込みキャッシュの最適化はこのオーバーヘッドを償却しますが、大量の挿入が発生した場合でも問題が発生します。 このオーバーヘッドを回避するには、LSMの試行に適用された最適化を行うことをお勧めします。 ナッシェッドのLSMツリーはソートされたディクショナリであり、そのうちの1つのインスタンスはメモリ内にあり、2番目のインスタンスはディスク上で非常に大きなデータチャンクを使用してバックグラウンドでマージされるため、書き込み用に3つのI / Oはなく、約3/16のIOがあります。追加の書き込みキャッシュの最適化が適用されることも考慮に入れると、はるかに高速な単一書き込みの場合、非常に高速なインデックスの実装が可能になります。 追加の最適化はブルームフィルターの使用ですが、サーバーリソースの総浪費であるブルームフィルターはカウントされません。

しかし、それもリソースを消費します。1人で4か月、2人で約2.5か月です。 しかし、結果は本当に価値があるはずです。

この最適化は、 https：//github.com/orientechnologies/orientdb/issues/1756の問題の後に実装する必要があり