図解 インデックス爆発 - 後ろ回しゲロ
Google App EngineのDatastoreにはインデックス爆発という現象があります。 こちらで公式に説明されているのですが、 http://code.google.com/intl/ja/appengine/docs/java/datastore/queriesandindexes.html#Big_Entities_and_Exploding_Indexes 自分にとってはすごく分かりにくく、理解するのにとても苦労しましたので、自分なりにメモを残しておきます。 まず2,3の前提を。 基本的な事ですが用語が統一されてなくて惑わされましたw 複合インデックス＝カスタムインデックス＝コンポジットインデックス です。 またGoogle App Engine for Javaでは WEB-INF/appengine-generated/datastore-indexes-auto.xm
Googleの巨大分散データストアBigtableとDatastoreを理解する
今回は、米Googleのクラウド環境に存在するデータベースBigtableとDatastoreサービスを紹介します。「巨大分散」という新たなデータベースの地平を切り開くためにどのような工夫をしているか、じっくり見ていきましょう。 「Bigtable」は、Googleの主要なサービスを支える独自の巨大分散データストアです＊1。Bigtableは、2005年4月から本格的な運用（プロダクション利用）が開始されたもので、Googleの検索サービスをはじめ、Gmail、YouTube、Google Maps、Google日本語入力、そしてApp Engineなど、70以上のプロジェクトで利用されています。その規模は、数P（ペタ）バイト～数十Pバイトに達しているでしょう。 Bigtableは、Google検索サービスにおける膨大なコンテンツやインデックスを保持し、高速に検索するための専用データストア
Song of Cloud: Slim3 Datastoreに乗り換える(2)
前回は思想ばかり書いたので、今回はSlim3 Datastoreの導入手順などを書いてみようかと思います。 Mavenizeされたプロジェクト構成はまだ敷居が高いうえに、エントリがかぶりそうなのでEclipseのGoogle Pluginを使った方法を紹介していきます。 なお、導入手順としてはSlim3本家サイトのほうが楽です。どちらかというと、これまでに作成したプロジェクトをマイグレーションするひと向けになりそうです。 App Engineに対応したプロジェクトの作成 Google Plugin for Eclipse の使用という本家ページを参考しにしてEclipseプロジェクトを作成してください。 ただ、エントリを書いているタイミングではEclipse 3.5に関する情報が書いていなかったため、英語版も参考になると思います。 ちなみに、紙媒体のものでは第3章あたりを参考にするとよいか
Java Cloud Meeting Fukuoka2010に参加してきた
2/20(土)に クラウドで変わるJava開発 – Java Cloud Meeting Fukuoka 2010 というイベントがSeasarFoundationより開催されました。 今回はGoogle App Engine Javaがメイン、という事でスピーカーとして声をかけていただけたのでスピーカーとして参加してきました。 私は「Google App Engine Java プラットーフォームの勘所」と言うことで、「プラットフォームの説明」「各サービス（機能）の説明」、サービスに付いてはDatastoreサービスを重点的に説明するという事を目的にしました。さらに、Datastoreサービスでは「そろそろJDOを公にDISっても言い時期かな」という判断で、思いっ切りDISる事にしました。今まで勉強会などで発表をするときは、できるだけ「LLAPI, JDO, Slim3」どれを選ぶかは好
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
インデックステーブルについてMLで聞いてみた - スティルハウスの書庫の書庫
App Engineのインデックステーブルについて、いまいち理解できてない部分や細かな疑問がいくつかあったのでMLで聞いてみました。 インデックステーブルの各行はどう構成されてる？ How Entities and Indexes are Storedで説明されているEntitiesByProperty ASC/DESCテーブルは、実際には キー："アプリID／カインド名／プロパティ名／プロパティ値" 値：エンティティのキー という構成か？それとも、 キー："アプリID／カインド名／プロパティ名／プロパティ値／エンティティキー" という構成で、値はとくに無いのか？ という質問に対し、Nickさんは 「後者で正しい」（インデックス行のキーにエンティティキーが含まれる構成） と返答してくれました。 また、インデックスについて詳しくはGoogle I/O 2008のUnder the Cover
App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
App EngineのEntityGroupを理解しよう - ひがやすを技術ブログ
App EngineのEntitiGroupは、Keyの親子関係を利用して組み立てられたEntityの集まりです。 Entityとは、Bigtable上の1つの行で、ユニークに識別するためのKeyを持っています。 Keyは、種類をあらわすkindとAppEngineから自動的に採番されるidもしくはアプリケーション側で自由に決めることのできるnameで構成されます。 通常は、AppEngineの自動採番に任せますが、Emailのアドレスをキーに使いたい場合などは、nameを使います。kindはテーブル名のようなものだと思ってください。 Keyの親子関係は次のようにして作ります。 Key grandparentKey = KeyFactory.createKey("Grandparent", "しげお"); Key parentKey = KeyFactory.createKey(grand
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
#appengine JavaのLow-Level API入門 Relationship編
前回のエントリが結構好評だったのと、前回のエントリだけだと、JDOから入った人は「Relationshipどーすんの？」となりそぅな気がしたので、調子に乗ってlow-level APIとJDOでのRelationshipの比較等について書きます。 JDOの方はLLParentクラスがOneToOneでLLChildAを、OneToManyでLLChildBを保持するような構成です。一方low-level APIではJDOと同じ事をキーのみでEntityGroupを構成します。LLParentkindは子エンティティのためのpropertyを一切保持しないと言う事です。JDOの方でもキーのみでEntityGroupを構成する事ができますが、ListPropertyで保持する方が一般的というかORMっぽいかなぁと思いまして。 一見、データの保持の仕方が全く違うよね？と見えますが、実はどちらの方
#appengine JavaのLow-Level API(低レベルAPI)入門
追記このエントリについては今後はWikiでメンテナンスしていきますので、最新の情報はWikiで確認して下さい。 追記スティルハウス社の佐藤さんよりコメントを頂いたので一部の表現を修正しました。取り消し線+青字にしたりしてます。 追記ひがさんよりコメントを頂いたので、最後のTransactionについてのソースコードのサンプルを一部修正しています。子Entityをput()する呼び出しの第一引数にTranscationを指定するように修正しました。 ここから GAE/JのLow-level API（主にDatastore周り）については基本的にJavaDocしかなくて情報量が少ないと思ったので、それなりに使っていくための簡単な説明を書いてみる(@fumokmm氏の発言で思いつきました、Thx！)。 個人的な思いとしては、GAE/JのDatastoreについてJDOから入るのは間違いの元だJD
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.