設計スキルを従来のRDBMSデータストアからAppEngineデータストア（つまり、「ソフトスキーマ」スタイル）に移行するのに役立つリソースを探しています。私はいくつかのプレゼンテーションを見てきましたが、すべてが包括的なテーマといくつかの特定のテクニックに触れています。
データの構造、特に既存のアプリケーションの移植方法を再考するための実際のアプローチに関する経験（「溝から」）からの知識をプールできる場所があるかどうか疑問に思います。私たちはHibernateをベースにしており、おそらくデータモデルを使って少し間違った道をたどり、DBが苦労しているいくつかの厄介なクエリを生成しています。
次の場合に返信してください。
経験から知識をプールできるところはないかしら
さまざまなGoogleグループがそのために適していますが、Java-GAEに直接適用できるものがあるかどうかはまだわかりませんが、これまでのGAEの経験はすべてPythonです（発明者のGuido van Rossumと言って誇りに思います） Pythonのメンバーであり、現在Google on App Engineで働いていると、彼の頭脳がどのように機能するかについていくつか教えてくれたと私に話しました。 ）。[私はGoogleで働いていますが、App Engineへの影響は非常に周辺的なものでした。「クラウドの構築」、クラスター、ネットワーク管理SWに取り組み、AppEngineはそのインフラストラクチャをサードパーティの開発者に役立つようにすることを目的としています]。
最適なGAEスケーリングとパフォーマンスのためにデータを非正規化してシャーディングする最善の方法については、確かに多くのエッセイとプレゼンテーションがありますが、品質はさまざまです。これまでに出ている本はまあまあです。今後数か月でさらに多くの人が来て、うまくいけばもっと良いものが来るでしょう（私は2人の非常に熟練した友人と一緒にそれらの1つを書くプロジェクトを持っていましたが、私たちはみんな忙しくてそれを落としてしまいました）。一般的に、Google I / Oビデオと、Googleがアプリエンジンサイトとブログで祝福したエッセイに加えて、 appenginefanのブログのすべてのコンテンツをお勧めします。GuidoがGAEについて教えてくれたことを称賛しました。主にappenginefanから学びました（一部はPalo Altoでの素晴らしいappengineミートアップを通じてですが、彼のブログも素晴らしいです;-)。
非リレーショナルデータベースの設計には、基本的に可能な限り非正規化が含まれます。
例：BigTableは十分な集計機能を提供していないため、RDBMSの世界にあるsum（cash）オプションは使用できません。代わりに、モデルに格納する必要があり、非正規化フィールドの合計を計算するには、モデルの保存メソッドをオーバーライドする必要があります。
頭に浮かぶ基本的な基本設計は、各テンプレートに独自のモデルがあり、入力する必要のあるすべてのフィールドが対応するモデルに非正規化されていることです。モデルでは、signals-update-botsの複雑さが全体的に発生しています。
Google App Engine for Javaを試してみたところ、多くの欠点があることがわかりました。
これは、汎用のJavaアプリケーションホスティングではありません。特に、完全なJREにアクセスすることはできません（たとえば、スレッドを作成できないなど）。この事実を考えると、Google AppEngineJREを念頭に置いてアプリケーションをゼロから構築する必要があります。重要なアプリケーションを移植することは不可能です。
データストアの質問により適切です...
データストアのパフォーマンスはひどいです。私は1時間あたり5000の気象観測を書き込もうとしていましたが、データストアとHTTPリクエストの両方でタイムアウト例外が発生し続けたため、書き込めませんでした。「低レベル」のデータストアAPIを使用すると、ある程度は役に立ちましたが、十分ではありませんでした。
割り当てをいっぱいにしないために、24時間後にそれらの気象観測を削除したかったのです。繰り返しますが、削除操作に時間がかかりすぎたため、実行できませんでした。この問題により、データストアの割り当てがいっぱいになりました。めちゃくちゃ、GAEデータストア内の大量のデータを簡単に削除することはできません。
私が好きだったいくつかの機能があります。Eclipseの統合は巧妙です。appspotアプリケーションサーバーのUIは、Tomcatを使用するよりも100万倍優れています（ログの見栄えなど）。しかし、マイナスは私にとってそれらの利点をはるかに上回りました。
要するに、通常のJava /アプリケーションホスティング環境ではかなり些細なことをするために、私は常にヤクを剃らなければならないことに気づきました。
タイムアウトは厳しく、パフォーマンスは問題ありませんでしたが、あまり良くなかったので、時間を節約するために余分なスペースを使用していることに気づきました。たとえば、トレーディングカードとプレーヤーの間には多対多の関係があったので、誰が何を所有しているかという情報を複製しました。カードオブジェクトにはプレーヤーのリストがあり、プレーヤーオブジェクトにはカードのリストがあります。
通常、すべての情報を2回保存するのはばかげている（そして同期が外れる傾向がある）が、それは本当にうまく機能した。
Pythonでは、最近リモートAPIがリリースされたため、データストアへのインタラクティブシェルを取得して、タイムアウトや制限なしでデータストアを操作できます（たとえば、大量のデータを削除したり、モデルをリファクタリングしたりできます）。ジュリアンが言ったように、バルク操作を行うのは非常に困難だったので、これは素晴らしく便利です。