Bツリーやその他のデータ構造は、ソリッドステートドライブの出現により廃止されますか？

現在、多くの（おそらくほとんどの）データベースアプリケーションは、Bツリーとバリエーションを使用してデータを格納しています。これは、このデータ構造がハードディスクの読み取り、書き込み、およびシーク操作を最適化するためです（これらの操作は、全体的な効率において重要な役割を果たしますデータベース）。

ただし、ソリッドステートドライブ（SSD）は従来のハードディスク（HDD）を完全に置き換える必要がありますが、Bツリーとバリエーションは時代遅れになり、ダイレクトアクセスメモリでより効率的に動作するデータ構造の余地ができます。もしそうなら、それらの構造は何になりますか？（例：ハッシュテーブル、AVLツリー）

database data-structures

— ダニエル・スコッコ
ソース

データベース実装以外の多くのアプリケーションがあるため、データベース実装の観点から、または一般的に廃止されるかどうかを尋ねていますか？

— ペムダス

データベースの観点から。

— ダニエルスコッコ

回答:

Bツリーは、ほとんどの場合、ハードディスクのデータベースインデックスに使用されますが、複数のキャッシュ層と仮想メモリを備えた最新のメモリ階層を考えると、メモリ内データ構造としても利点があります。仮想メモリがSSD上にある場合でも、それは変わりません。

私は、C ++で非常に多く書いたインメモリB +スタイルのマルチウェイツリーライブラリを使用します。それはパフォーマンス上の利点を持つことができます-元々書かれた理由はキャッシュをより良く使用しようとすることでした-しかし私はそれがしばしばそのように機能しないことを認めなければなりません。問題はトレードオフです。つまり、アイテムは挿入および削除のノード内を移動する必要があります。これはバイナリツリーでは発生しません。また、私がそれを最適化するために使用した低レベルのコーディングハックのいくつか-まあ、彼らはおそらくオプティマイザーを混乱させ、打ち負かす、と真実が語った。

とにかく、たとえデータベースがSSDに保存されていても、それは依然としてブロック指向のストレージデバイスであり、Bツリーや他のマルチウェイツリーを使用することには利点があります。

しかし、約10年前に、キャッシュを使用しないアルゴリズムとデータ構造が発明されました。これらは、キャッシュなどのサイズや構造を意識していません-メモリの階層を（漸近的に）可能な限り最適に使用します。Bツリーは、特定のメモリ階層に最適化するために「調整」する必要があります（ただし、非常に幅広いバリエーションでかなりうまく機能します）。

キャッシュ忘却型データ構造は、まだほとんど見られていませんが、そうではありませんが、通常のインメモリバイナリツリーは時代遅れになる可能性があります。また、クラスターサイズやハードディスクキャッシュのページサイズを気にしないので、ハードディスクやSSDにとっても価値があるかもしれません。

Van Emde Boasのレイアウトは、キャッシュを意識しないデータ構造において非常に重要です。

MIT OpenCoursewareアルゴリズムコースには、キャッシュ忘却型データ構造が含まれています。

— スティーブ314
ソース

面白い。このトピックをさらに調査するために、いくつかの良いポインタ（しゃれはありません！）を提供しました。ありがとう。

— ダニエルスコッコ

このMITコースには、キャッシュ忘却型データ構造に関する情報も含まれています。

— dan_waterworth

こんにちは、SSDのためではなく、キャッシュを無視するデータ構造のために、Bツリーが廃止されるということですか？しかし、DBMSのブロック管理のような他のデータ構造はどうでしょうか？

— ヤンボー

@ user955091-キャッシュを意識しないデータ構造（キャッシュを意識しないモデルで最適な構造を意味するため）を意味していましたが、当時は少し興奮しすぎていました。他のデータ構造はすぐに消えることはありません。一つには、キャッシュだけがパフォーマンスの問題ではありません-並列処理は異なる要求をします。さらに、キーベースの順序付けが必要になることは多くの場合、特別な場合です-通常、ハッシュテーブルが重要です。「ランダム化された」レイアウトをキャッシュフレンドリーと見なすのは難しいかもしれませんが、アイテムを直接取得するための1つのアクセスは勝ちにくいです- 局所性は必要ありません。

— Steve314 14

先験的、はい、ほとんどのデータベースエンジンは、ディスクがゆっくりと移動してデータがフェッチされるハードドライブではローカリティがすべて重要であるため、データを格納するための最も効率的なデータ構造ではなくなるため、書き換える必要がありますブロック単位で、データの変更には次のことが必要です。

ヘッドをディスク上の適切な場所に移動します（約10ミリ秒）。
ディスクが回転するのを待ちます（10k rpmで、これは毎秒167回の回転を意味しますが、平均して半分の回転だけを待つため、約3msです）。
ブロックを読み取ります（〜3ms）。
RAMで変更します。（〜10ns）
ヘッドを再びディスク上の正しい場所に移動します（再度10ms以内）。
ディスクが再び回転するのを待ちます（再び3ms以内）。
ブロックを書き込みます（〜3ms）。

それは10 + 3 + 3 + 10 + 3 + 3 = 34ミリ秒です

ディスク上の位置に関係なく、SSDで同じことを行うのは平均で1ミリ秒です。

また、ハッシュテーブルははるかに高速であるため、ハッシュテーブルの方がより良い代替品になると考えられます。

唯一の問題は、ハッシュテーブルが順序を保持していないため、Van Emde Boasのように次と前を見つけることができないことです。

見る：

次と前を見つけることが重要なのはなぜですか？xより大きく、zより小さいすべての要素を取得するとします。findpreviousおよびfind nextでインデックスを使用する必要があります。

さて、唯一の問題は、順序を保持する機能を持つハッシュテーブルが見つからないことです。Bツリーのバケットのサイズは重要かもしれませんが、キャッシュ忘却型アルゴリズムで解決されます。

だから私はこれが自由な問題だと思います。

— ウィルヘルムヴァンエンデボアス
ソース

ハッシュテーブルは（通常）パフォーマンスをモデル化するキャッシュ忘却型WRTですが、それはそのモデルで効率的であることを意味するものではありません。問題は、ハッシュ関数は通常、アイテムを「ランダムに」分散させるように設計されていることです。これが、ハッシュテーブルが順序付けられておらず、ローカリティが低い理由です。つまり、隣接するキーを使用してアイテムのシーケンスを識別できたとしても、ブロックごとに2つ以上のアイテムを読み取ってもメリットが得られない可能性があります（SSDは依然としてブロックデバイスです）。

— Steve314

もちろん、ハッシュは「キー変換」とも呼ばれ、変換は「ランダム」である必要はありません-合理的に効率的な順次アクセスを可能にするハッシュ関数を定義することが可能です（検索を排除せず-情報が失われますハッシュ関数、結局のところ-それを最小化する）、ハッシュの衝突をまれに保ちながら、いくつかの局所性の利点を提供します。

— Steve314