インメモリー・データベースの仕組み

インメモリー・データベースの仕組み

メモリーにデータを展開するインメモリー・データベースでは、基本的にディスク・アクセスは存在しません。十分なメモリーを確保することで、劇的なパフォーマンスを得ることができます。

また、従来のデータベースとは異なり、単にクエリーのキャッシュ用途や、インデックスの展開用にメモリーを利用しているわけではありません。

従来のディスクI/Oを使うデータベースは、B+ツリー索引でインデックスを付けています。ディスクI/Oを減らして、より多くのデータを取得できるように設計されています。これに対して、インメモリー・データベースは、インデックス構造をTツリー索引と呼ばれる方法に切り替えているものがあります。

Tツリー索引は、B+ツリー索引に比べて、消費するメモリーがより少なくなっています。具体的な例を挙げると、MySQLのオンメモリー・モードがB+ツリー索引を使っており、Oracle TimesTenがTツリー索引を使っています。

インメモリー・データベースは、抽出する対象のデータをすべてメモリーに展開しています。従来存在していた、クエリー・キャッシュやキャッシュ領域にデータが存在するかどうかをチェックする機能も不要になります。このため、より高速に動作します。

インメモリー・データベースの注意点

インメモリー・データベースには、注意点もあります。すべてのデータをメモリーに展開するので、障害に対する対策がなされているかどうかを確認する必要があります。メモリーには揮発性があるため、システム・ダウン時にバックアップ機能が保証されているかどうか、トランザクションを復元できる仕組みがあるかどうかを確認しなければなりません。

データ永続性の機能については、製品やライブラリごとに実装方針が異なるので、必ず確認しましょう。MySQLでオンメモリー・テーブルに設定したテーブルは、シャットダウン時には、テーブル構造だけを残してデータが消失します。このように、動作設定やバックアップ取得の設定などを定めなければならないものが存在します。

すべてをメモリーに展開するため、ハードウエアの価格はそれなりに高価なものとなります。すべてをインメモリー・データベースに置き換えるほどの高負荷なアプリケーションなのか、つまり費用対効果と見合っているかどうかを、十分に検討しなければなりません。規模や費用に合わせて、既存の環境を残したまま一部の機能だけをインメモリー・データベースに置き換えたり、仮想環境を構築・利用したりすることも検討すべきです。

アプリケーション側でも、注意することがあります。データベースがインメモリー化することによって、クエリーの処理が非常に高速になるからです。検索結果や処理結果を受け取るアプリケーション側では、無駄なロジックやオブジェクトの生成を許容できなくなるかも知れません。また、アプリケーションからデータベースへの接続回数を増やすと、増やした分だけ接続時のコストがかかります。接続時のコストを削減する工夫や、コネクション・プールの設定ノウハウに関しては従来通りです。