Google App Engine/JavaのData Storeの「良い」ところ
数回のログにわたって、GAE/Jのデータストアを触ってみた。
雑誌の記事や、いくつかのHPを参考にさせていただいたが、まだ情報量が少ないのだなぁ、と思う。
自分より先に利用をしてみた友人らと話していると、「GAE/Jはデータストアが特殊だからな。。。」という意見を持っている者が多い。
JDOなり、JPAなりの一本槍というのは極端な話だから、そういう意見が出ても、全く不思議はない。
もっと砕けてしまうと、HibernateならHibernateのみで実装するとかいうのも、実際の開発現場ではちょっと厳しい話なのだろうと思う。やっぱり、開発者は融通のきくSQLで実装をしたいという本音がある。EzoGPでのJava開発ではApache iBatisを利用しているのだが、iBatisは適度にオブジェクト指向かつ、SQL指向の開発者にもスムーズに使ってもらえる、という実績があるため。
とはいえ、こういうサービスが利用できるというのは画期的なことで、間違いなく「よいところ」がある。
たとえば。。。
Data Storeそのものについて
公式HP(スタートアップガイド）や、以前のログにあるように、GAE/Jで提供されるJDOやJPAは「不完全（完成形ではない）」で、「何がどう使えるの？」という部分がはっきりしない。
だが、以下に挙げる事項は、間違いなくGAE/Jの大きなメリットだと思う。
RDBのセッティングをしなくてもよい。
実行環境とシームレスにData Storeを利用することができるのは、最大のメリットだと思う（昔、ホストコンピュータでコーディングしていた時を思い出してしまった）。
レンタルサーバーを借りるにしても（自身、3箇所も借りているのだが）、「データベースは何が使える」とか、「そのバージョンはいくつ」だとか、「このバージョンにはこういった癖がある」とかを考慮する必要がない。
ドライバーを用意する必要もないから、それを設定ファイルによって設定する必要もない。
RDBとのマッピングをしなくてよい。
これも、大きなメリットだと思う
ORMを使うと、必ず「XMLでRDBのスキームとマッピングする」という作業が発生する。ORMが、RDBとOO設計の橋渡しをするのだから、仕方ないといえば仕方ないが、興ざめする行為であるのは間違いない。
GAE/Jで作業をしている限り、このマッピングの作業が発生しない。OOで設計したら、それをそのままデータ・ストアに持っていけばいい。
このことは、開発者が思考を分断することなく（XMLを書いたり、それを間違えてParseエラーではまることなく）、アプリケーションと永続化機構を一気通貫で設計・開発することを可能にする。
スタートアップ・ガイドに書いてあるように、GAEのデータストアはRDBではなく、スキームの設計をする必要がない、という文言は、このような意味で捉えるのが正しいと思われる。
SLAについて
まだ、Early Lookの段階なのでSLAが定義されていないが、まず、間違いなく
と思われる（SLAは、AmazonEC2と同様に、ダウンタイムで定義されると仮定）。RDBをスケールアウト構成しようとすると、
- Oracle RACのようにActive-Activeのサーバーに同時に書き込みに行くような仕組み
- Memory Cacheのような、書き込み前のバッファリングの仕組み
- Primaryが落ちたときにSecondaryにFail overする仕組み
- Primaryが復旧し場合に、Secondaryから、Primaryに戻す仕組み
- これらの仕組みを自律的に行う仕組み
などなどといったことが必要となる。
MySQLのようなオープンソースのRDBでも、ある程度の仕組みを作ることができるが「SLAを究極的にあげたい」といった場合には、綿密なサーバー構成（方式設計）・運用体制の確立が不可欠となる。たとえば、Oracleでこういった仕組みを作ると大変に費用がかさむ。いずれの選択でも、費用（もしくは手間）をかけなければ、間違いなくSLAが下がってダウンタイムが発生する。
この部分をGoogleの技術に依存できるのであれば、これまでボトルネックとなっていたRDBのスケールアウトが可能になる。アーキテクト的には、（SLAが上がらない割に手間と費用のかかる）RDBサーバーの方式設計・構築・運用の手間も省けるのはありがたい。
それより何より、JavaEEを動かすことのできるレンタルサーバーは、個人ユースでは高価である（安くても3万円/年位なので、スクリプトだけ動かすサーバーの10倍位の値段と思う）。
それが「無料（厳密には従量制課金）」で利用できることは、とてもありがたいことだ。
