Engineのデータストアに乗り換えるときのつまずきポイントとか実例とか無印吉澤(※新エントリはhatenablogに掲載中)吉澤です。このサイトではIPv6やP2Pなどの通信技術から、SNSやナレッジマネジメントなどの理論まで、広い意味での「ネットワーク」に関する話題を扱っていたのですが、はてなブログに引っ越しました。使っている方は以下のボタンで変更ください。Engine(GAE)を色々いじって遊ぶという2泊3日の合宿に参加してました。Engineに置き換えようとしたらどれくらい大変なのか?」をテーマに決めて、下の本を読みながらコードを書いたり消したりして遊んでました。先にまとめまだ勘違いも多そうですが、今回分かった「リレーショナルデータベースに慣れた人のつまずきポイント」を先にまとめておきます。GAEのデータストアでは、複合主キーのある表を作れない。JDOだと、@PrimaryKeyを複数のインスタンス変数に付けるとコンパイル時に例外が出る。ちなみに、主キーのない表も作れない。こちらもコンパイル時に例外が出る。一意なIDを割り当てるためのカウンター(オートインクリメント機能)が必要なら、自前で実装する必要がある。トランザクション処理を使うことで、このようなカウンターを実装できる。JDOインターフェイスでは、valueStrategyにIdGeneratorStrategy.INCREMENT(なんかそれっぽい)を選べるが、GAEでは使えないらしく実行時に例外が出る。UNIQUE制約に相当する機能もない。自前で実装することもできない?UNIQUE制約は、自前で定義することもできない、ような気がする......。GAEのトランザクション処理は参照したデータに対する排他処理のため、新しく追加する行の値に対する制約にはなり得ないのではないか。多対多の関係を表現しにくい。リレーショナルデータベースに慣れていると、多対多の関係を表現するときは、関係を表す表を新たに追加したくなってしまうけど......。GAEでは複数の表をまたがるトランザクションは基本的に作れないので、途中で処理に失敗した場合の例外処理を書くのがすごく面倒。JOIN処理なんて無い。多対多を実現する方法としては、一方の表に、もう一方のIDのリストを格納する列を用意すると楽。:A」のような形で記述できる。JDOとJPAのどっちを使えばいいのか分からない。JPAを選んでもリレーショナルデータベース固有の機能は使えないので、JDOを使っておけば良いような気がする。情報がなくてよく分からない......。以下は、上のつまずきポイントに気付くまでに、実際に書いたり消したりしていたソースコードの話です。文章の最後にソースコードも置いておきましたので、興味のある方はダウンロードしてみてください。Info?)のテーブル定義がシンプルだったので、これをGAEのデータストアに置き換えることを試みました。GAEのデータストアへのアクセス方法は以下の3種類があるのですが、今回は最も情報が多いJDOを使っています。API、RDB向け)ローレベルAPI(Key-Valueで値を保持するAPI、高速だが低機能)まず、元にしたAndroidアプリのテーブル定義は、以下のようなものです。個人情報(information)と情報提供先(knowers)の関係を、主キーのないinformation_knowersテーブルで表現しています。これを、GAEのデータストアで定義すると、以下のようになります。GAE上で扱う表のことを、ここでは「エンティティ」と呼んでいます。して見ると、リレーショナルデータベースでの定義と比べて、やや汚くなってるのが分かります。以下は、リレーショナルデータベース版との違いです。Knowerエンティティの列に、関係するInformationのIDのリストを追加。IDを一意に割り当てるためのカウンタを追加。主キーが必須なので、ダミーの主キーを定義している。今この資料を書きながら思ったけど、IDを一意に割り当てるためのカウンタ類は、1つのエンティティにまとめてしまえそう......。最後にこのアプリを、ユーザ毎に別の領域にデータを格納できるように拡張すると、データストアの定義は以下のようになります。「110487681081245093660」というのは、Googleが提供するアカウント認証サービスから取得できる、ユーザ毎に一意なユーザID。ユーザ毎に一意なIDを使っている。ユーザIDとユーザ毎に一意なIDを組み合わせた複合主キーが使えたら、ホントはそっちの方がよかったんだけど......。クエリとインデックスの方法を使って前方一致検索をすることで、特定のユーザに関係する列のみを取り出すことができる。リンク先にあるのはPython版のコードだが、Java版でも同じ方法が使える。実例とソースコードを、それぞれ以下の場所に置いておいたので、もし興味があったら覗いてみてください。Engineのソースコードを書くのも、本番環境にデプロイするのもすごく簡単です。このデータストアを使って大規模なコードを書くのは、正直言って全然出来そうな気がしません。こんなのを使ってあんなgmailみたいな巨大アプリを書いてると思うと、やっぱりGoogleの連中はイッちゃってるよ、あいつら未来に生きてんな......と思っていたら、今回の合宿の参加者から「Googleの中では、BigTableに(GAEには含まれてない)Chubbyを組み合わせて使ってるんじゃない?」との指摘が。そんな、ひどい......。次の日記(2009/10/17)»2004|06|07|09|11|12|2005|01|02|03|04|05|06|07|08|09|10|11|12|2006|01|02|03|04|05|06|07|08|09|10|11|12|2007|01|02|03|05|06|07|08|09|10|11|12|2008|01|02|03|04|05|06|07|09|10|11|2009|01|02|03|04|05|07|08|10|2010|01|03|2015|03|スパム対策のため、60日以上前の日記へのコメント及びトラックバックは管理者が確認後に表示します。この日記に無関係と判断したコメント及びトラックバックは削除する可能性があります。31このサイトについてこの日記を書いているのは、吉澤というソフトウェア技術者です。muziyoshiz.jpまでどうぞ。