問題タブ [bigtable]

データストアにBigTableを使用するGoogleAppEngine用のアプリケーションを開発しています。

ストーリーを共同で書くためのアプリケーションです。とてもシンプルな趣味のプロジェクトで、楽しみのために取り組んでいます。これはオープンソースであり、ここで見ることができます：http ://story.multifarce.com/

アイデアは、誰でも段落を書くことができ、それを他の2人が検証する必要があるということです。ストーリーは任意の段落で分岐できるため、ストーリーの別のバージョンを別の方向に続けることができます。

次のツリー構造を想像してみてください。

すべての数字は段落になります。すべてのユニークなストーリーラインのすべての段落を選択できるようにしたいと思います。基本的に、それらのユニークなストーリーラインは（2、7、2）です。（2、7、6、5）; （2、7、6、11）および（2、5、9、4）。ノード「2」が2回表示されることを無視して、ウィキペディアからツリー構造図を取得しました。

また、提案されたソリューションの図を作成しました：https ://docs.google.com/drawings/edit?id=1fdUISIjGVBvIKMSCjtE4xFNZxiE08AoqvJSLQbxN6pc&hl=en

構造を設定するには、書き込みと読み取りの両方でパフォーマンスが効率的ですが、最も重要なのはどのようにすればよいですか？

PenWag.comでMySQLからCassandraへの変換を急いでいるところです。Cassandraでは、GUIDからキーオフされたユーザーを保存していますが、ユーザーはGUIDではなく電子メールでサインインします（明らかに）。ユーザーのキーとしてのGUIDは、2つの理由から、電子メールよりも私にとって理にかなっています。実用的な観点からは、すべてのSuperColumnsを含む行を変更または削除/追加するのは面倒すぎるようです。理論的な観点からは、それはまだ同じユーザーですが、なぜ彼らのキーを変更する必要がありますか？

それでも、私の質問は次のとおりです。別のColumnFamilyにインデックスを作成し、ログインをサポートするようにemail->GUIDをマッピングしています。これは標準タイプのCFであり、列名は電子メールで、値はGUIDです。マッピングごとにSC全体がロードされないようにするのは、SuperではなくStandardです。「メールの変更」のサポートは簡単で、列の削除/追加だけです。ただし、これに代わる方法は、インデックスを列ではなく行として格納することです。行キーは電子メールであり、列はGUIDを保持します。管理する列（GUID）しかないため、これらの行の削除/追加は面倒ではありません。

どちらのアプローチでもうまくいくようです。それぞれの長所と短所は何ですか？ベストプラクティスはありますか？

Google App Engine を使用していますが、一部のデータ クエリでパフォーマンスが低下しています。App Engine データストアの設計は、SQL データベースでの作業とは異なる考え方であると読みましたが、これが最善の方法であるかどうか確信が持てません。正しい軌道に乗るために、2 つの質問があります。

具体的には：

FooタイプとタイプがありUserFooます。それぞれUserFooが対応する の「インスタンス」であり、Fooそのインスタンスに固有のデータを保持します。私のFooタイプにはfooCode一意の識別子であるプロパティがあり、それらのプロパティを使用してUserFooそれぞれをマップします。次に、次のようなコードで各 Foo を操作します。FoofooCode

注:fooCode新しい を簡単に削除して再追加Fooし、対応するすべての を再マップする必要がないように、参照キーを使用していUserFooます。

一般に：

GAE データストア テーブルを設計するための一般的なアプローチと、それらを使用するためのベスト プラクティスは何ですか?

db.get() のパフォーマンスは db.get_by_key_name() のパフォーマンスと比べてどうですか?

Bulkoader.yaml：

model.py：

すべて問題ないようですが、アップロードすると次のエラーが発生します。 BadValueError: Property data is 24788 bytes long; it must be 500 or less. Consider Text instead, which can store strings of any length.

何らかの理由で、データは文字列プロパティであると見なされます。

誰かが私がこれを修正する方法を知っていますか？

appcfg.py を使用してローカル データ ストアにいくつかのレコードをアップロードしようとしています。

実際に挿入されるレコードはごく少数で、次の出力が得られます (大量のエラーがあります)。

何が問題なのですか？

appcfg.py を使用してデータをアップロードしようとすると、ログインの詳細が完全に正しいにもかかわらず、認証エラーが発生します。

問題は何でしょうか？

デフォルトでは、GAE は一意のキーをデータベース エントリに追加します。

さらに、数値の一意のキーを持つことは可能ですか?

エリアス

サンプルモデル：

1. QueryまたはGqlQueryを使用してクエリを実行し、 barプロパティに特定の値を持つすべてのFooエンティティを返すにはどうすればよいですか？

2. IDのリストがある場合、 idプロパティがそのリストにあるすべてのエンティティを返す単一のフィルターはありますか？

次のデータモデルがあります。

スタジアムで友達でもあるすべてのユーザーを見つけたいです。私はこのようにすることができます：

これは、非常に少数のオブジェクトで機能します。ユーザーが一握り以上の友達を持つとすぐに、これは機能しません。アプリエンジンでこれに対する解決策はありますか? 性能の良いものは思いつきません。

ありがとう

-------- いくつかのサンプルデータ --------

もし私がユーザー「john」なら、私の友達は { tim, mary } です。Stadiumname='abc' を指定してスタジアム クエリを実行すると、{ tim } が返されるはずです。