インメモリー・データベースの注意点
データベース利用の今後のあり方
インメモリー・データベースやKVSは、Java EEアプリケーションを劇的に高速化できます。以下では、実際にこれらを適用させる場合に考慮しなければならない点を挙げます。
小さなシステムであっても、データベースを入れ替えるとなると、それなりにコストがかさみます。また、データベースのI/Oが原因となると、アプリケーションの実装で改修するのにも限界があります。KVSの導入やインメモリー・データベースの採用は、システムのパフォーマンス改善のための特効薬ですが、そのリスクとコストは決して小さくありません。
それぞれの関係を簡単に図示すると、以下の図のようになります。
|
|
| 図3: KVSに置換した時のシステム概略図 |
KVSを利用する場合、サーバー機の追加やレプリケーションをしない場合、システムの改修はほとんど必要ありません。しかし、SQLではなく独自APIを利用することになるため、アプリケーションは大幅に改修しなければなりません。また、トランザクション管理の処理を実装する場合は、アプリケーションの改修は非常に困難なものとなります。
|
|
| 図4: インメモリー・データベースに置換した時のシステム概略図 |
インメモリー・データベースを採用する場合は、アプリケーション・ロジックの改修は、基本的に不要です。アプリケーションをそのまま流用して、パフォーマンスだけを高めることができます。しかし、この一方で、メモリーの増設やサーバー機の置き換えなどの作業が発生します。
従来のディスク型データベースとインメモリー・データベースを併用しつつ、負荷の高いところを見積もって、コストとのバランスを考えながら徐々にインメモリー型へと置き換えていくのが現実的です。ディスク型とインメモリー型を共存させるハイブリッド形式にすることで、高負荷に耐えなければならない個所はインメモリー型に、それ以外のデータはディスク型で対応する、といった構成が可能です。
次に示す事例は、とあるCMSサイトの構築例です。自社製品のパッケージ画像や、公開予定の動画コンテンツを配信しています。
エンドユーザーは、参照系の機能をメインに使います。コンテンツの更新は、管理側だけが行います。アプリケーションの特徴として、検索機能が特に多く使われます。検索画面では各種サムネイル画像を製品ごとに表示するほか、データ・サイズの大きいものもあります。検索画面のレスポンスの高速化が望まれています。
分析してみると、コンテンツの更新は、1日に1回程度反映されれば十分であることが分かりました。このため、検索部分のデータをオンメモリー・データベースへ格納する構成とすることで、検索レスポンスの高速化を実現しました。
|
|
| 図5: ハイブリッド化の概略図 |
インメモリー・データベースは、従来のディスク型データベースと競合する存在ではなく、お互いに補完し合う関係にあります。インメモリー・データベースに置き換えて性能を高めることができる一方、インメモリー・データベースの定期バックアップ用に同じテーブル構成のディスク型データベースを用意する使い方もできるでしょう。お互いのメリットを生かしてバランスよく構築することが理想です。
以上、インメモリー・データベースとKVSについて、簡単に概要を紹介しました。規模を問わず、インメモリー・データベースとKVSは、さらに利用されていくことでしょう。用途や利用シーンに合わせてミドルウエアを選択することは、とても大切です。ミドルウエアの選択肢を広げておくことは、パフォーマンスやサイジングの見積もりにも影響するので、今後さらに重要なポイントとなるでしょう。
次回は、JavaVMのヒープ・メモリーの監視方法について解説します。
