Slim3 DatastoreはGoogle App Engine for Javaのデータストアを操作するライブラリです。 最近JDOからSlim3 Datastoreに乗り換えつつあるので、背景や使い方などをつらつらと書いていきます。

Slim3 Datastoreの特徴

Slim3 Datastoreはデータストア低レベルAPIの薄いラッパーとして作成されています。他のラッパープロダクト(JDO/JPA)と違いApp Engineのデータストア専用に作られているため、提供される機能が非常に直感的で、さらにかなり高速に動きます。 ざっくり説明すると、以下のような機能を提供しています。

1. データストア上のデータと自作のモデルオブジェクトを相互に変換する

他にも色々とあった気がしますが、Slim3 Datastoreを利用する最大のメリットは上記の点でしょう。 しかもこの変換層をコンパイル時に自動生成しますので、非常に高速に動作します。

なぜJDOを使わないか

App EngineのデータストアをJavaから利用する場合、本家ドキュメントではJDOを推奨しています。

JDO インターフェースを使用しているアプリケーションは、データベース固有のコードを使用することなく、リレーショナルデータベース、階層型データベース、オブジェクトデータベースなどさまざまな種類のデータベースで作業できます。他のインターフェース標準については、JDO を使用し、アプリケーションを別のストレージ ソリューションへと簡単に移行できます。

App Engine での JDO の使用

私もApp Engine for Javaの公開当初からJDOを利用してきましたが、次の理由でSlim3 Datastoreに乗り換えることにしました。

1. App Engineのデータストアを利用した時点でポータビリティが存在しない

   App Engineのデータストア向けにモデリングした場合、それを他のストレージソリューション上でそのまま流用できると思えませんし、いまいちその需要が見えません。JDOで開発している他のアプリケーションをApp Engine上でそのまま動作させてみようという挑戦をする場合に、コードの一部を流用できるかもしれません。現在の私の認識はそんなレベルです。

2. アプリケーションサーバとJDOの相性がそれほど良くない

   JDOはエンティティのライフサイクル管理がありますが、分散アプリケーションサーバを利用するApp Engineとあまり相性がよくありません。アプリケーションサーバをまたいでライフサイクル管理するならまだしも、個々のサーバで閉じて管理するため、多くの場合邪魔になります。

3. データストアとJDOの相性がそれほど良くない

   JDOは仕様としてかなり大きく、App Engineのデータストアを操作するためにはかなりオーバースペックです。そのため、JDOで公開されている機能のほとんどがApp Engine上で利用できません。

4. 初期化が遅い

   JDOを初めて使うときにはPersistenceManagerFactoryというオブジェクトを初期化しますが、これが残念なくらい遅いです。通常のアプリケーションなら問題にならない程度の速度ですが、頻繁にデプロイ/アンデプロイを繰り返すようなelasticなシステムでは致命的です。

5. 動作も遅い

   データストア上のエンティティを自作のモデルオブジェクトにマッピングする操作が妙に遅い感じです。それ以外にも、エンティティを前述のライフサイクル管理から切り離す(detach)という余計なコピーが多くの場合に必要になるのも速度低下の要因になりそうです。

過去にハマった経験があるのでネガティブな情報が多いですが、だいたいこんな感じです。 ちなみにJPAも利用できますが、あれはRDBにターゲットしたインターフェースですので、JDOよりもさらに相性が悪い状態です。使ったこともないので割愛します。

なぜ低レベルAPIを使わないか

データストア低レベルAPIはApp EngineのデータストアをJavaから利用する上でのプリミティブとなるAPIで、JDOやJPAなどのラッパーから利用されます。 JDOとは異なり非常に高速に動作し、App Engineのデータストア専用に作られているため、APIのミスマッチも見受けられません。App Engineはリバースエンジニアリングを禁止しているため、この中身について詳細を紹介することはできませんので、インターフェースレベルで簡単に問題点(?)を挙げます。

1. 型安全性がない

   データストアの読み書きはエンティティという単位で行いますが、これをすべてEntityというクラスで表現しています。エンティティが持つプロパティなどはgetProperty(String), setProperty(String, Object)などの型安全でないメソッドを利用することになります。静的型付けのない言語ならまだしも、JavaでこれをやるとString定数とキャストの嵐になり、メンテナンスが困難になります。

2. 気がつくと機能が増えてる

   App Engine自体が発展途上のサービスなので、気がつくと低レベルAPIの動作が変化したり機能が増えていたりします。そのまま使うと一定のリスクがあるように思えます。

低レベルAPIはデータストア操作のプリミティブなので、上記のような問題点はある意味で筋違いな指摘です。ですが、それなりに洗練されているAPIですので、上記の問題点を解決すればJDOより使いやすいのではないかと思いました。

Slim3 Datastoreに乗り換えた

さて、前置きが長くなりましたが、そんなこんなで今後はJDOをあきらめてSlim3 Datastoreを使っていくことにしようかと思っています。Slim3 Datastoreは低レベルAPIの薄いラッパーで、低レベルAPIと似通ったインターフェースを提供しています。また、ユーザ定義のモデルクラスをもとに前述のEntityオブジェクトとの相互変換ロジックを自動生成する機能を持っていて、ジェネリクスをうまく取り入れて静的に型安全性を確保しているところがかなり使いやすくなっています。

また、パフォーマンスに影響が出る個所でリフレクションを利用せず、ベタにマッピングするコードを生成しているため、非常に高速に動作します。HotSpotVMの性質を考えると、自分で変換コードを書くよりもパフォーマンスが高い可能性があるくらいです。

今回はJDOを捨てた言い訳をつらつらと書いてみましたが、次回から実際にSlim3 Datastoreを使ってみようと思います。 本家のドキュメントもかなり充実していますので、そちらも参照しながら進めていく予定です。