汎用のデータ構造を作ろうとしています。基本的に、これはクライアントがサブスクライブできる更新の追加専用リストになります。クライアントは更新を送信することもできます。
これを実装する方法についての提案に興味があります。データとインデックスを含む ndb.Model 'Update' を作成するか、メイン エンティティで Repeated=true の StructuredProperty を使用することができます。また、何らかの方法でキーのリストを保存し、実際の更新データを強くリンクされていない構造に保存することもできます。
繰り返されるプロパティがどのように機能するのかわかりません.それらのリストに(Python APIを介して)追加すると、それらすべてを書き換える必要がありますか?
私も一貫性について心配しています。複数のクライアントが更新を送信している可能性があるため、それらが互いに上書きして更新が失われたり、何らかの形で同じインデックスを持つ 2 つの更新が発生したりしたくありません。
問題は、データストア内の各モデルの最大合計サイズがあることです。
そのため、更新を蓄積する単一のモデル (データを直接保存するか、キーを収集することにより) は、最終的にはスペースが不足します (ただし、構造化されたプロパティに関して制限がどのように適用されるかはわかりません)。
あなたが言うように、モデルを「更新」しないのはなぜですか。単純なバージョンは、提供された更新ごとに新しいモデルを作成して保存することです。保存日をモデルのフィールドとして追跡すると、それらをクエリするときに時間で並べ替えることができます（おそらく、何らかのレベルで上限があります）。
また、同時のクライアント更新が互いに上書きすることを心配する必要がないように、データストアがそれを心配します。また、割り当てられた「インデックス」について心配する必要はありません。自動的に行われます。
データストアの読み取りにはコストがかかる可能性があるため、単一で繰り返しプロパティを使用するバージョンを実装し、N 個のキーが保存された後に新しいモデルに移行できると確信していますが、それをトランザクションにラップする必要があります。複数の更新が衝突しないことなどを確認してください。
結果を生成するクエリをキャッシュし、新しい更新が保存されたときにのみ無効にすることもできます。NDB も自動キャッシングを提供しているため、NDB を参照してください (ただし、クエリ用ではありません)。