キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると

2009年8月18日

2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。

この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。

確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。

両者の違いは何かあるのでしょうか？調べてみることにしました。

インメモリデータベースは1000倍速い

【インタビュー】イン・メモリデータベースの正しい使い方 - Oracle TimesTen (1) Release 7 | マイコミジャーナル

調べてみるとすぐに、両者には明確な性能差があることが分かりました。2007年3月28日付けマイコミジャーナルの記事「【インタビュー】イン・メモリデータベースの正しい使い方 - Oracle TimesTen 」から引用します。

さらに「メモリ上のデータを使えば速くなるというわけではない」(同)とも指摘する。「メモリ上にデータを置くだけで高速化できるのであれば、 Oracle Databaseの(メモリ上にデータをキャッシュする)バッファ・キャッシュを大きくとることで対応できるはずだ。しかし、それだけではたいした効果は期待できない」

2年前の記事ではありますが、オラクルの担当者が上記のように「メモリに置くだけではたいした効果は期待できない」と答えています。

では、Oracleのバッファとインメモリデータベースでは、どれくらいの性能差なのでしょうか。実は1000倍もインメモリデータベースの方が高速だと、ThinkITの2008年7月28日付けの記事「[Think IT] 第3回：性能検証！インメモリDB (1/3)」で説明されています。

1行の検索であれば数マイクロ秒、1行の更新であっても数十マイクロ秒もかかりません。ディスク型RDBMSではどんなにチューニングしたとしてもミリ秒が限界と言われていますので、TimesTenのレスポンスタイムがけた違いに速いことがわかります。

1マイクロ秒とは100万分の1秒、1ミリ秒は1000分の1秒です。Oracle RACでは数ミリ秒、インメモリデータベースのTimesTenでは数マイクロ秒というレスポンスタイムだとすれば、インメモリデータベースは1000倍速くレスポンスを返す、ということになります。

差はどこから生じるのか？

製品情報 - Oracle TimesTen In-Memory Database

こうした性能差はどこから生じるのでしょうか？オラクルのOracle TimesTenの製品情報ページから、Oracle TimesTen製品とテクノロジーホワイトペーパーというドキュメントを参照してみました。

ドキュメントの11ページにある「IMDBテクノロジーの詳細」では、インメモリデータベースではアルゴリズムや構造がメモリ上のデータを扱うのに最適化されていることが、キャッシュを豊富に設定したRDBMSよりも高速な理由だと解説しています。

RDBMSで実行されるほとんどの操作は、「データは主にディスクに存在する」という仮定のもとに行われます。最適化のアルゴリズム、バッファ・プールの管理、索引を利用した検索方法は、この基本的な仮定を重視します。

一方、Oracle TimesTenではデータはメイン・メモリーにあるため、データに対してより直接的なルートをとることができ、コード・パスが短くなり、アルゴリズムも構造も簡潔になります。

両者の具体的な違いとして、クエリーの最適化アルゴリズム、バッファ・プールの管理、索引構造における違いの3つを挙げています。

クエリーの最適化

ディスクベースのRDBMSでは、クエリーの実行がディスクのI/Oを減らすことに最適化されているのに対し、インメモリデータベースでは最初からメモリに最適化されたクエリーの実行になっているとのこと。

ディスクベースのRDBMSは、データがディスク上に存在すると仮定します。データは、パフォーマンスのボトルネックのポイント、つまりディスクのI/Oを減らすために最適化されています。この仮定に基づく限り、ディスクベースの最適化では、主に（または完全に）メイン・メモリーに存在するデータに対して常に最適なプランを提供することはできません。

一方、IMDBのテクノロジーでは、データがメイン・メモリーにあることがわかっているため、より単純な仮定のもとでクエリーを最適化します。このテクノロジーでは、データがディスクに存在するという最悪の事態を想定しなくてよいため、コストの評価もより簡潔になり、さらに高い整合性が得られます。

バッファ・プールの管理

ディスクベースのRDBMSでは、キャッシュ上のデータに対してバッファプールを作成しなければならないことがほとんどだそうです。一方で、インメモリデータベースの場合はそうしたバッファプールは不要とのこと。

従来のRDBMSアーキテクチャでは、メイン・メモリーにキャッシュされたデータに対しバッファ・プールを保持することが必要でした。SQLクエリー・プロセッサでデータのページが必要になった場合、アクセス・メソッドでメモリー内のデータに対するバッファ・プールが最初に検索されます。データがバッファ・プールにあっても、ほとんどの場合には以降の処理にプールのコピーが必要です。追加のデータ・コピーを伴う、このバッファ・プールのメンテナンスと管理では、アプリケーションでデータを使用可能にする最初の負荷と比較して、負荷が大幅に増加します。バッファ・プールは、ディスクベースのデータ管理ソリューションでは必要ですが、メモリーベースのデータ管理では必要ありません。

索引構造

ディスクベースのRDBMSでは、ディスクI/Oを最小化する目的でB-Treeインデックスが用いられるのに対し、インメモリデータベースではより低コストなT-Treeインデックスが用いられているとのこと。

B+ツリーの構造での目的は主に、データ・ファイルの索引付けの検索に必要なディスクI/Oの回数を削減することです。（略）この構造は、データと索引のファイルがディスク上にある場合は有効ですが、データがメモリーにある場合は適していません。データがメモリーに保持されると、索引付けのスキームの目的は、I/Oの削減ではなくCPUサイクルの削減になります。（略）
Oracle TimesTenでは、処理を表す図は簡単です。Tツリーは、メイン・メモリーのアクセスに対して最適化されています。Tツリーは、サイズとアルゴリズムの両面で、B+ツリーに比べ低コストな索引エントリを備えています。