Facebook では、トピックの下のコメントが多すぎる場合、「コメントをもっと見る」というリンクが表示され、そのリンクをクリックすると、さらにコメントが読み込まれます。
モデルクラスを次のように設計しました。
class Item(db.Model):
...
comments = db.ListProperty(str)
または、コメント用に別のクラスを設計し、アイテムへの参照を追加する必要があります。
class Comment(db.Model):
...
item = db.ReferenceProperty(Item)
現在、コメントを反復処理するために for ループでこれを行っています。
ここで、2 つのコメントがほぼ同時に到着し、インスタンスが急増した場合、1 秒のエンティティ更新にさらされます。(この方法を使用する場合は、必ずリスト プロパティに indexed=False を設定してください。) 先に進む前に、これがどのように機能するかを検討してください。より複雑に見える代替案と比較して、本番環境に入ると実際の利点が得られる可能性があります。
カウンタ フィールドを持つ CommentParent モデルを作成し、インデックス付きフィールドとして parent_id と date_created (auto) を持つ別のコメント モデルを作成しないでください。新しいコメント スレッドを開始する新しいコメントが入ってくると、親エンティティを put() し、コメント テキストと parent_id 参照をタスクキューに送信します。スレッドへの今後のコメントはすべて、同様にキューにパススルーされます (非常に高速なオンライン ハンドラー レイテンシが発生します)。タスクキューにコメント レコードを put() させ、CommentParent カウンターを更新します。カウンター更新の 1 秒制限を回避するには、TQ を調整するか、エンティティ カウンターの代わりにシャード カウンターを使用するかについて少し考える必要があります。(非常に大量のアプリケーションでのカウンターは、非常に難しいことで知られています。)
ユーザーがこのコメント スレッドに入ると、クライアントは parent_id と現在のカウントを受け取ります。次に、parent_id= date_created> フィルターを使用した単純なクエリで処理される最初の N レコード (想定される LIFO モデル) を要求し、date_created の降順と、fetch() 制限またはクエリ内の処理を制限するカウンターのいずれかで並べ替えます。 ier() ループ (私は後者を使用します。) コメントと各コメント date_created を返します (次のクエリの「カーソル ポインター」になります)。クライアントは初期カウンター値を使用して、「さらに N 回読み込む」ボタンのラベルを維持します。（クエリがフェッチ制限よりも少ない数を返すたびに、is_finishedブール値がtrueに設定された別の戻り値を追加します-これにより、カウンター数学への完全な依存が回避されます。）
これにはいくつかの欠点があります。結果整合性とタスクキューの遅延は、時折の非同期カウント、またはコメントの欠落を意味する場合があります。date_created gt と順序降順のセットアップに必要なカスタム インデックスに関連するオーバーヘッドがあります。ただし、実際のプラス面もあります。オンライン ハンドラーのレイテンシが非常に短いことと、1 秒のエンティティ更新制限の問題を引き起こすほぼ同時のコメントのクラスターに関する問題がないことです。また、タスクキューがコメント量の小さなスパイクのバッファとして機能するという非常に重要な利点もあります。このバッファがないと、このようなスパイクが発生するたびにいくつかのインスタンスが起動するという問題が発生する可能性があります。これは、そのようなインスタンスの数に 15 分の充電を掛けたものです。
また、実行する必要がある実際のクエリの数を制限するために memcache を使用する非常に簡単な方法もいくつかあります。スレッドがアクティブな場合、最初の N 個のクエリ結果をキャッシュし、新しいコメントが作成されるまでそのキャッシュを使用できます。そういうもの。もちろん、アプローチで memcache を使用することもできます。いずれにせよ、memcache の使用を検討してください。
HTH -スティーブ