1

競合と、それがアプリケーション エンジン スタックにどのように適用されるかについて頭を悩ませようとしています。

私はそのように構築されたモデルを持っています

class Events(db.Model):
    #Owner Identification Number
    owner_id        = db.StringProperty(required=True)

    #Authentication Token
    auth_token      = db.StringProperty(required=True)

    #generic, b, c, d, ...
    driver          = db.StringProperty(required=True)

    #Start Time and Date
    tStart          = db.DateTimeProperty(auto_now=True)

    #Define whether the event is active or inactive
    active          = db.BooleanProperty(default=False)

    #Payload store, this will store each payload block sent or pulled
    payloads        = db.StringListProperty(indexed=False)

このモデルはいくつかのイベントを保持します。各イベントには所有者とペイロードがあり、イベントの所有者は自分のイベントとの間でペイロードを書き込み、他の多くのイベントはイベントから読み取ります。これは一種のトランスクリプション スタックです。

私の質問は競合についてです。これによって影響を受けるのでしょうか。もしそうなら、どうすればそれを防ぐために再構築できますか。

ありがとうございました。

4

4 に答える 4

2

私も Google App Engine は初めてです。したがって、基本的に競合を回避することは、実際には書き込みスループットを向上させる方法を尋ねることです。私が考えることができる解決策は次のとおりです。

  1. トランザクションを犠牲にする
  2. memcached でのバッチ書き込み
  3. シャードカウンター
  4. バックグラウンド タスク キュー

https://developers.google.com/appengine/articles/sharding_counters

https://developers.google.com/appengine/articles/scaling/contention

他のアイデアはありますか？私も知りたいです！

于 2012-05-27T17:20:41.500 に答える
1

App Engine では、イベントの各インスタンスはオブジェクト全体として読み書きされます。Event の各インスタンスでの競合が心配になります。Event の 1 つのインスタンスを頻繁に更新する必要がある場合は、競合について心配する必要があるかもしれません。別のインスタンスを更新する場合、心配する必要はありません。

競合とは正確に何を意味するのかわかりません。a) トランザクションの整合性、または b) 書き込みパフォーマンスの制限について言及している可能性があります。対処すべき結果整合性の問題はありますが、読み取りパフォーマンスに問題はないはずです。

a) Event インスタンスが更新された後に正しいデータを読み取る必要がある場合は、キーによるデータストア get() リクエストを使用する必要があります。query() リクエストは古いデータを返す場合があります。

b) 書き込みパフォーマンスが心配な場合は、何らかの方法でエンティティを複数のエンティティに分割する必要があります。次のように、イベントごとに複数のペイロード エンティティを使用することを検討することもできます。

class Payload(db.Model):
    event = db.ReferenceProperty(Events)
    payload = db.StringProperty()

このようにして、各ペイロードを個別に記述できますが、インデックスを作成する必要があり、取得するにはイベントごとにクエリを実行する必要があるため、少しコストがかかります。イベントを祖先に設定して、祖先クエリを一貫性のあるクエリに使用できるようにすることができます。

于 2012-05-27T22:33:46.607 に答える
1

あなたの場合、適用される制限は、エンティティの書き込み/更新の制限です。これは、エンティティ (またはエンティティ グループ) ごとに 1 秒あたり 1 回の書き込み/更新です。

読み取りに制限はありません。

コストを下げて応答時間を改善するために、読み取りのキャッシュに memcache を使用することをお勧めします。Python NDB を使用する場合、キャッシングはデフォルトで有効になっています。

解決策：私見は、書き込みスループットを向上させ、同時に読み取りをバックエンドにするための優れたソリューションです。それらは (ほとんどの場合) 常に共有メモリとして使用できるインスタンス上にあります。そのため、同時読み取りを行いながら、書き込みをバッチ処理 (およびタスク キューを介してフラッシュ) できます。

注:インスタンスは 1 日に 1 回程度再起動されるため、信頼できるストレージとして扱うことはできません。データストア内のエンティティを非同期的に (バックエンド スレッドまたはタスク キューを介して) トランザクションで更新しながら、スマート キャッシュとして使用できます。

于 2012-05-27T19:58:46.880 に答える
1

あなたのモデルに問題はありません:

  1. Eventsエンティティは、あなたの言葉と例から判断すると、エンティティグループ外のルートエンティティだけで、競合税を支払うことはありません。
  2. 1 つのエンティティを頻繁に更新すると競合が発生する可能性がありますが、所有者が 1 秒に 1 回以上エンティティを更新することに疑いの余地はありません (1QPS は、心に留めておかなければならないしきい値であり、それを超えると危険ゾーンにいることになります)。
  3. データストアの読み取り操作は、競合の問題を引き起こしません。
于 2012-05-27T20:11:38.243 に答える