0

GAE とそのデータストアについて読んでいます。この質問と記事に出会いました。したがって、ユーザーを電子メールなどで識別できるかどうか疑問に思います.2 人の異なるユーザーが同じ電子メールを使用しようとしているときに競合を解決する目的で、すべてのユーザーと電子メールに同じ親をキーとして使用することは合理的でしょうか?彼らの識別子？理論的には、ユーザー数が大きくなった場合 (たとえば 10M など)、問題が発生する可能性はありますか? 私の観点からは、gets は問題ないはずですが、puts はロックされているものです。したがって、gets が puts を大幅に支配している場合 (実際には、新しいユーザーを作成する時点でのみ発生します)、問題は見られません。しかし....

Key parent = KeyFactory.createKey("parent", "users");
Key user = KeyFactory.createKey(parent, "user", "user@domain.com");

GAE のデータストアでエンティティ グループを使用する場合 https://developers.google.com/appengine/articles/scaling/contention

4

2 に答える 2

0

また、固有の電子メールの問題に直面しました。これが私が行ったことです。

「メール」という「種類」を設定し、ユーザーが入力したメールを文字列キーとして使用します。これは、フィールドをスケーラブルでデータストア内で一意にする唯一の方法です。次に、「ユーザー」と呼ばれる別の種類をセットアップし、自動生成された ID を使用してキーを取得します。

Eメール

キー: メール、ユーザーキー: datastore.Key

ユーザー

キー: auto_id、パスワード: 文字列、名前: 文字列

このセットアップでは、電子メールをログインとして使用でき、ユーザーは電子メールを変更する (または複数の電子メールを持つ) オプションを使用できますが、電子メールはシステム全体で一意のままです)。

====================

すべてのユーザーを同じ親の下に置くと、スケーラブルではありません。同じエンティティ グループのエンティティが近接して格納されるため、すべてのデータが 1 つの特定の「サーバー」にスタックすることになります。1 秒あたり 5 回の書き込みの問題に直面することになります

=====================

一般的な経験則として、スケーリングするもの (ユーザーなど) は、データ ストアのスケーリング機能の利点を享受するには、ルート エンティティである必要があります。

于 2013-07-06T02:58:22.427 に答える
0

私は私の質問に対する答えを見つけたと思います。エラーの原因セクションのhttps://developers.google.com/appengine/articles/handling_datastore_errors :

最初のタイプのタイムアウトは、単一のエンティティ グループへの書き込みが速すぎるときに発生します。1 つのエンティティ グループへの書き込みは App Engine データストアによってシリアル化されるため、 1 つのエンティティ グループを更新できる速度には制限があります。一般に、これは 1 秒あたり 1 ～ 5 回の更新でうまくいきます。適切なガイドラインとして、エンティティ グループが長期間にわたって 1 秒あたり複数の更新を維持する必要があると予想される場合は、再設計を検討する必要があります。エンティティ グループは同じ祖先を持つエンティティのセットであることを思い出してください。したがって、子を持たないエンティティはそれ自体のエンティティ グループであり、この制限は個々のエンティティへの書き込みにも適用されます。データストアの競合を回避する方法の詳細については、データストアの競合の回避を参照してください。トランザクション中に発生したタイムアウト エラーは、Timeout ではなく appengine.ext.db.TransactionFailedError として発生します。

于 2013-07-06T19:50:37.317 に答える