インメモリデータベース、性能がどれだけ違うのか調べてみると2009年8月18日2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。RAC)でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。調べてみることにしました。マイコミジャーナル調べてみるとすぐに、両者には明確な性能差があることが分かりました。「メモリ上のデータを使えば速くなるというわけではない」(同)とも指摘する。Databaseの(メモリ上にデータをキャッシュする)バッファ・キャッシュを大きくとることで対応できるはずだ。それだけではたいした効果は期待できない」2年前の記事ではありますが、オラクルの担当者が上記のように「メモリに置くだけではたいした効果は期待できない」と答えています。Oracleのバッファとインメモリデータベースでは、どれくらいの性能差なのでしょうか。(1/3)」で説明されています。1行の検索であれば数マイクロ秒、1行の更新であっても数十マイクロ秒もかかりません。ディスク型RDBMSではどんなにチューニングしたとしてもミリ秒が限界と言われていますので、TimesTenのレスポンスタイムがけた違いに速いことがわかります。1マイクロ秒とは100万分の1秒、1ミリ秒は1000分の1秒です。RACでは数ミリ秒、インメモリデータベースのTimesTenでは数マイクロ秒というレスポンスタイムだとすれば、インメモリデータベースは1000倍速くレスポンスを返す、ということになります。ホワイトペーパーというドキュメントを参照してみました。ドキュメントの11ページにある「IMDBテクノロジーの詳細」では、インメモリデータベースではアルゴリズムや構造がメモリ上のデータを扱うのに最適化されていることが、キャッシュを豊富に設定したRDBMSよりも高速な理由だと解説しています。RDBMSで実行されるほとんどの操作は、「データは主にディスクに存在する」という仮定のもとに行われます。最適化のアルゴリズム、バッファ・プールの管理、索引を利用した検索方法は、この基本的な仮定を重視します。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サイクルの削減になります。TimesTenでは、処理を表す図は簡単です。Tツリーは、メイン・メモリーのアクセスに対して最適化されています。Tツリーは、サイズとアルゴリズムの両面で、B+ツリーに比べ低コストな索引エントリを備えています。競合製品もここで参照してきた情報の多くはオラクルから提供されたものであるため、マーケティング的な要素が含まれている可能性はありますが、それでもインメモリデータベースとRDBMSのキャッシュでは多くの違いがあることが分かりました。1/3、日立システムアンドサービス扱っているExasolのExcasolなどがあります。今後はそれらの動向にも注目していくつもりです。OraclePublickey広告.NET帳票ツール。デザイナはExcel。クラウド/サーバー環境対応。.NET5/6/8に対応。デザイナはExcelのため、エンドユーザーも編集可能。ノーコードでCSVファイルから帳票を出力する、CSVReportも新収録。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Feed最新記事10本GitHubで最も使われている言語、PythonがJavaScriptを抜いて1位に。生成AI関連プロジェクト急増で。Sonnetが選択可能に。100」の仮想マシンを正式提供開始JetBrains、JavaScript/TypeScriptのためのIDE「WebStorm」と.NETのためのIDE「Rider」、非商用利用ならば無償で利用可能に。1.0」、12月に正式リリース予定。MemoryDBで提供開始Webブラウザ上でWebAssembly製コンパイラによりC言語をWebAssemblyにコンパイル、そのまま実行可能に。