SSD がコモディティになっても状況はかわらない - kazuhoのメモ置き場

脊髄反射。 Oracle や MySQL など近年の RDBMS はインデックスのデータ構造にB木 (の変種) を採用していますが、その理由はここにあります。 SSD がコモディティになると状況は変わる (中略) 二次記憶上での検索用のインデックスにはこれまで B木のようなディスクに最適なデータ構造が必然的に選択されてきましたが、SSD に変わると、現実的に利用可能なデータ構造にも幅が出て、アプリケーションによっては劇的な改善が可能になるというわけです。 この先 SSD の普及によって、色々なソフトウェアで、驚くような改善が行われる機会を目にすることが多くなるのではないかと思います。その時、単に SSD に変わったから速くなったと捉えるのではなく、どのようなデータ構造が選択されて、そのデータ構造の特性が SSD とどのようにマッチしたのかという視点で見ていくことが大切ではないかと思います。

[festango]

"(マルチコア化のようなトレンドと違い) 既存のコードがそのまま速くなるフリービールな点が、SSD のいいところ。"

[shigeo-t]

「状況はかわらない」に同意。SSDになって高速になってもインメモリよりは遅い。RDBMSチューニングの基本は「いかにディスクIOさせないか」。あとは局所的にインメモリDB使ってIO時間短縮するか。

[ysano2005]

「むしろ、(マルチコア化のようなトレンドと違い) 既存のコードがそのまま速くなるフリービールな点が、SSD のいいところ。」

[NOV1975]

インメモリDBでデータ構造が大きく変わっているんじゃなければHDDが(今よりも遥かに高速な)SSDに変わったところで変わらんよな。

[dealforest]

既存のコードがそのまま速くなるフリービールな点が、SSD のいいところ

[takeshiketa]

実測あるのみ

[taroleo]

DBMSとしては、index構造よりも、leafのchainの探索とか、external merge sortとか、hash joinなどがSSDで高速化できる恩恵が大きい。