ストレージDB
データをストレージに持ち、可能な限りメモリにキャッシュする。
メモリDB
データをメモリに持ち、入りきらない部分をストレージに退避させる。
疑問
こう考えるとオーバーヘッドは一緒じゃないのか?と思われるかもしれない。
MySQLのソースを見てみる。b-tree関係ではたくさんのfread,fwrite等のファイルアクセス関数を呼んでいる。
「メモリ上に存在するデータはメモリだから高速だ」
本当にそうだろうか?
正確には「仮想メモリ上に存在するデータ」である。
仮想メモリである以上、データの実体はメモリか、外部ストレージ上に存在している。
高速化のために外部ストレージからメモリにロードしたが必ずしも物理メモリ上にあるとは限らない。
明示的にバッファリングしたが、仮想メモリ機構はその意図が分からずにページアウトしてしまった…ということもありうる。
仮想メモリ機構によるファイルとのマッピングはハードウェアによる支援があり、上手く最適化すればストレージDBよりもシンプルに高速に出来る。
例えばある行を読み込むとする。
ストレージDBはそのデータがメモリ上に存在するかチェックする。存在しなければストレージからメモリ上に読み込む。これらをソフトウェアで行う。
メモリDBはそのデータを参照しようとする。仮想メモリ機構はそれが物理メモリになければページインする。これらはハードウェアによる支援とOSによって行われる。
ソフトウェアの複雑さが軽減され高速になる。
難点はDB特有のデータ構造、アクセスパターンにより適切なキャッシュアルゴリズムを適用できないこと…と思っていた、ページに対してページアウトさせない属性を与えることで最適化が可能とみている。
ストレージDBでもこの最適化はメモリバッファのページアウトを禁止することで可能であるが、せっかくの仮想メモリ機構を使わないのは無駄であると考える。
メリットとしては32ビット仮想メモリ空間でもストレージにアクセスできるサイズまでDBを拡張できることだと思う。
最終更新:2008年11月15日 00:16