2

私のバックグラウンドはリレーショナル DB で、主に学習のために Google AppEngine の実験を行っています。ユーザーが州 (CA、NY、TX など) に属し、政党 (共和党、民主党など) を選び、特定の年 (今のところ 2012 年ですが、アプリは 2016 年に再利用される可能性があります)。

ユーザーが自分の投票履歴を確認して、現在の選挙で一度変更できるようにしたい. また、ユーザーが郵便番号を指定することを要求し、州および/または郵便番号ごとにいくつかのレポートを実行するとよいと思います。

リレーショナル DB を使用して、次のようなテーブルをいくつか作成するようです。

Users(userid, username, city, state, zip)
UserVote(userid, year, vote)

次に、SQL を使用してレポートを実行します。AppEngine データストアでは、集計レポートを実行するのがやや難しいようです。

私の最初の取り組みはUser、各ユーザーがリストを含むことができるVotes場所で分割し、別の場所に集計を二重に保存することです。

助言がありますか？

PS AppEngine-MapReduceプロジェクトを見たことがありますが、それがやり過ぎかどうかはわかりません。

4

1 に答える 1

1

これをどこで読んだか正確には覚えていませんが、GAE のリスト プロパティは、約 200 アイテムに達すると遅くなります。ユーザーと投票の外部キーアプローチを支持して、これに反対することをお勧めします。

MAX、SUM、COUNT などの一般的なヘルパー関数がないため、集計は困難です。最善のアプローチは、集計とカウントを別のデータ型に格納して、簡単にクエリを実行し、ユーザーが投票するたびに更新できるようにすることです。AppEngine では、後でより高速なクエリを実行できるように、書き込みを行うときに時間を費やす方が簡単です。

Java のオブジェクトの例を次に示します。

@PersistenceCapable
public class User{
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;
    ...
}

@PersistenceCapable
public class Vote{
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    private Key userKey;  // References a User
    ...
}

@PersistenceCapable
public class UserStats{
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    private Key userKey;  // References a User
    ...
}

また、基盤となるデータストアは大規模なデータ セットに対するクエリを簡単に処理するように設計されているため、従来のシャーディングは AppEngine ではあまり意味がありません。例外は、頻繁に変更できる特定のカウンターがあり、複数のユーザーが同時に変更する可能性がある場合です。これは、MySQL で慣れているものとは異なるタイプのシャーディングです。シャーディング カウンターに関する Google の記事は次のとおりです: http://code.google.com/appengine/articles/sharding_counters.html

于 2011-05-31T03:41:35.280 に答える