インメモリー・データベースの注意点
データベースとJavaEEの関係
今回は、Java EEアプリケーションのチューニングの観点で高パフォーマンスを期待できる新たなデータベースの選択肢として、インメモリー・データベースとKVS(キー・バリュー・ストア)を紹介します。
エンタープライズ・アプリケーションでは、データベースとのデータの受け渡しが必ず発生します。システムの規模によっては、単一のデータベースでは収まらず、複数のサーバーに配置されたデータベースと連結し、検索から更新処理までを行います。
多種多様な機能に応じて、さまざまなクエリーが発行されます。1つの機能で、マスター・テーブルの検索から業務データの検索、更新チェックから更新処理と、複数のクエリーが順次発行されていきます。データベースの処理速度が、アプリケーションのパフォーマンスに直接影響することになります。
図1: データベースのディスクI/Oを検討する |
データベース処理のパフォーマンスを上げる方法として従来、SQLをチューニングする方法や、環境を分散化する方法が採られてきました。現在は、レスポンス要求がさらに高くなってきており、これを解決する手段として、KVS型データベースとインメモリー・データベースが登場してきました。
インメモリー・データベースとKVSの登場
データベースを大別すると、従来のリレーショナル・データベースの構成を採用するものと、そうでないものの2つがあります。前者は、従来のリレーショナル・データベースと同様、SQLでクエリーを発行します。一方、後者は、SQLでクエリーを記述せず、独自のAPIを持っています。
SQLでクエリーを記述しないタイプの中には、KVSと呼ばれるデータベースがあります。KVSは、キー項目と値の組み合わせを保持するハッシュ型データ構造を持っており、分散化環境に優れているのが特徴です。
リレーショナル型データベースが使われる理由は、複雑なロジックをSQLに持たせることができる点と、トランザクション管理によってデータの一貫性を保つことができる点です。
リレーショナル型データベースにも、テーブルをメモリー上に展開する機能を備えているものがあります。MySQL、H2 Database、HSQLDBなどが相当します。特にMySQLでは、メモリー上に展開するかどうかをテーブルごとに選択できます。操作も非常に簡単です。
インメモリー・データベースは、リレーショナル型データベースのデータ整合性と高速性を両立させることができます。データを一切ディスクに持たず、すべてメモリー内に展開するので、ディスクへの読み書きが発生しません。従来のディスク型データベースよりも数倍から数百倍の性能を発揮できます。
搭載可能なメモリー容量も増えました。従来は、32bit OSの制限で、扱えるメモリー容量は2Gバイトが限界でしたが、現在は64bit OSが使われるようになり、数Tバイトのメモリーが扱えるようになりました。搭載するメモリーさえあれば、大量のデータを一括で扱えるようになりました。
大容量メモリーの低価格化も進み、導入事例も徐々に増えてきました。昨今のアプリケーションでは高パフォーマンスを期待されることもあり、リレーションナル・データベースのオンメモリー・モードでの需要やインメモリー・データベースの需要が高まってきています。
インメモリー・データベースやKVSが注目される背景
一般的には、ディスク型のデータベース同士で比較すると、検索性能では、リレーショナル型よりもKVSの方が比較にならないほど上回っています。レプリケーション性にも優れます。一方、リレーショナル型は、データの整合性を保つ機能に優れており、トランザクション管理機能によってデータの不整合やロストに対して対処できるという特徴があります。
それぞれの機能を比較すると、以下のようになります。
表1: ディスク型データベースのリレーショナル型とKVSの比較
機能 | リレーショナル型 | KVS | インメモリーDB |
---|---|---|---|
即応答性 | △ | ◎ | ◎ |
スケーラビリティ | △ | ◎ | △ |
トランザクション機能 | ◯ | △ | ◯ |
読み取り一貫性の保証 | ◯ | △ | ◯ |
排他制御 | ◯ | △ | ◯ |
クエリー | SQL | 独自API | SQL |
このように、それぞれのデータベースは、機能の違いが明確です。
システムの規模によっては、負荷分散のためにデータベースをレプリケーション(コピー)することもあるでしょう。しかし、リレーショナル型は、トランザクション管理による一貫性を保持するため、データの書き込み処理も分散させるためには、相当な手間がかかります。
この一方で、昨今のWebアプリケーションは、膨大な量のリクエストをさばいて瞬時にレスポンスを返すリアルタイム性が求められます。
従来型の、ディスクI/Oが発生するリレーショナル・データベースでは、データベースとのI/Oにミリ秒の時間が必要になります。秒間1000件以上のリクエストともなると、これが大きな足かせとなってしまいます。
こうした高トランザクションをさばくために選択されるのが、KVSと、インメモリー・データベースです。KVSは、高速にデータI/Oをさばくことができ、レプリケーションも簡単です。インメモリー・データベースは、そもそもディスクI/Oを発生させません。
KVSのデメリットは、独自APIを使っているものがほとんどである点です。リレーショナル型で使っていたロジックをそのまま流用することはできません。トランザクション管理機能も基本的にありません。
KVSには、一部トランザクション管理機能を備えるものもありますが、こちらにはリレーショナル型と同様の欠点があります。レプリケーションの際にデータ整合性を保たなければならず、このための処理によって大幅に速度が劣化します。せっかくのKVSのメリットが失われてしまいます。
これに対して、インメモリー・データベースは、非常に高速に動作するうえに、リレーショナル型の利点をそのまま残しています。
インメモリー型は、ディスクに退避していたバッファをそのままメモリーに展開したものではありません。メモリー・アクセス用に内部ロジックを最適化したOracle TimesTenのように、高速性を確保しつつ、従来通りのトランザクション管理やSQLを利用できる製品も登場しています。特に、インメモリー型のランダム・アクセス速度は、ディスク型と比較して1000倍と言われています。享受できるメリットはディスク型とは段違いです。