第3回　HibernateとCaché、性能比較の結論を出そう

ネクストデザイン
村山 徹
2006/2/3

■総合的な性能比較

開発容易性

　ともに、O/Rマッピングが解消されることで、オブジェクト指向設計・プログラミングに集中でき、生産性や品質が向上します。

　Cachéの場合、Cachéスタジオを使って永続クラスを定義しますので、Cachéスタジオの操作を覚える必要があります。今回は特に、永続化の責務を持つクラスを完全に分割しましたので、Cachéスタジオを使用する場面（頻度）は少なく、通常のEclipseでの開発スタイルで行えました。

　Hibernateの場合、本事例では永続クラスの定義にXML設定ファイルを使いました。ただし、この方法では、クラス数が増えたときなど、設定ファイルの作成、保守が大きな負担になる可能性があります。XML設定ファイルを使う場合には、このあたりの対策が必要かもしれません。しかし、Hibernateには、XDocletやアノテーションを利用する方法もあります。POJO内に、アノテーションを含めることでXML設定ファイルは必要なくなります。今後は、アノテーションを使った方法が増えるでしょう。

サポート

　ともにサポートが利用できます（有償）。

費用

　Hibernateは無償で商用利用が可能（LGPLライセンス）です。また、永続ストレージとして利用できるRDBMSには無償のものと有償のものがあります。Cachéは有償です。

速度性能

　単純には比較できませんが、今回、簡単なベンチマークを行ったところ、Hibernateが実アクセスしない（RDBMSに対して実際にSQL文を発行しない）操作を繰り返している間は、両者の速度性能に大きな違いはありませんでした。しかし、トランザクションをコミットした時点で大きな差が出ました（Cachéの方が10倍強高速）。これは、実アクセスを伴わないようなメソッド呼び出しを繰り返した後、コミット時にすべての実アクセスが行われるようなテストを行った場合の結果です。

　Hibernateでは、コミットするとその時点で未実行の更新（SQL文）が残っていれば、そこですべてが実行（実アクセス）されます。未実行の更新が残っていなければ、コミット自体は短時間で終わります。また、コミット時以外でも、アプリケーション側から強制的に実アクセスさせることができます。この点をうまく利用すれば、見掛け上の性能差を小さくすることができるでしょう。

　一方、強制的な実アクセスが必要となるケースもあります。例えば本事例の場合、操作画面上で、あるユースケースに別のシナリオが追加された場合、その変更は即座に画面上のツリー構造に反映されなければなりません。そのユースケースのシナリオ・リストを最新の状態にするためには、強制的な実アクセスが必要です（リスト6の注2）。もし、実アクセスを強制しなければ、シナリオ・リストの状態は変わらず、そのユースケースは、新たにシナリオが追加されたことを知ることができません。このような強制的な実アクセスが必要なケースが多く、関連先のリストのサイズ（本稿の場合、シナリオの数）が大きいアプリケーションでは、速度性能が問題となるかもしれません。

　画面ベースの業務アプリケーションなのか、本事例のような「保存」や「上書き」アクション、「undo/redo」のあるアプリケーションなのか、バッチシステムなのかなどによって評価方法を変える必要があるでしょう。

情報量

　今日のシステム開発では、インターネット上に存在する情報の質や量は重要なポイントです。現時点では、Hibernateの方が多いといえます。

繰り返し開発

　オブジェクト指向開発は、繰り返し開発が基本です。繰り返しの中で、永続クラスの属性や関連は変わります。その際に、以前のデータを無効にしないで永続クラスを再定義できるのか、あるいは将来、システムをバージョンアップした場合にデータの互換性を保つことは容易なのか、などは重要な問題です。

　Cachéの場合は、拡張方向（属性が増えるなど）のスキーマ展開が可能です。Hibernateの場合は、SchemaUpdateツールによってスキーマ更新がサポートされています。用語は違いますが、ともに拡張方向については、この問題は解決できるようです。ただし、今回の事例では使っていません。詳細は各マニュアルで確認してください。

どちらを使うべきか

　設計モデルの比較で見たとおり、設計時点で永続化方式を決める必要はないでしょう。適切な設計モデルを作っておけば、どちらの永続化方式にも容易に移行できます。「どちらを使うべきか」は、パフォーマンスや費用などの観点から選択することになるでしょう。

■最後に

　これまで、永続化が必要なシステムをJavaで開発する場合、実装環境が整っていたとはいえません。なぜなら、優れたオブジェクト・モデルを作成しても、それをスムーズに実装することは難しかったからです。O/Rマッピングを追加することで設計モデルは複雑になり、実装にも大きな負荷がかかったからです。

　しかし、この問題は今後、O/RマッピングツールやJava EE 5（EJB3.0、Java Persistence API）、オブジェクト指向データベースなどによって、大きく改善、解消されるはずです。そして、このような環境が手に入るようになれば、システム開発の現場では、オブジェクト・モデルの優劣が重要課題となり、ドメイン・オブジェクトが欠如したようなシステムは少なくなるでしょう。そうなれば、Java言語の普及だけでなく、オブジェクト指向技術の真価が発揮され、ソフトウェア開発が大きく進展するのではないかと期待しています。

　ただ、このようなツールや環境を導入しても、オブジェクト設計がなされていなければ、効果がないことも忘れないでください。（連載完）

筆者プロフィール

村山 徹（むらやま とおる） ネクストデザイン有限会社 代表取締役。 オブジェクト指向技術に惹かれ、管理者よりも技術者としての活動を優先すべく、1998年1月、現在の会社を設立する。以降、オブジェクト指向技術を使ったシステムの開発、セミナー講師、UMLツールの企画、開発、販売に携わる。

4/4

Index
対決！ O/Rマッパー vs. オブジェクト指向DB（3） HibernateとCaché、性能比較の結論を出そう
	Page 1 ・はじめに ・継承と関連の定義（Hibernateの場合）
	Page 2 ・継承と関連の定義（Cachéの場合） ・アプリケーションコードを書く
	Page 3 ・本事例における設計モデルを比較する
	Page 4 ・総合的な性能比較 ・最後に

対決！ O/Rマッパー vs. オブジェクト指向DB

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）