最近、Google App Engineとそのデータストアで遊んでいて、参照プロパティを使用してデータモデルとリレーションシップを作成しました。
ただし、データストアの祖先の概念についてはよくわかりません。それらの目的は何ですか、なぜ私はそれらを使用する必要がありますか?それらはデータストアエンティティの参照プロパティとどのように関連していますか?
最近、Google App Engineとそのデータストアで遊んでいて、参照プロパティを使用してデータモデルとリレーションシップを作成しました。
ただし、データストアの祖先の概念についてはよくわかりません。それらの目的は何ですか、なぜ私はそれらを使用する必要がありますか?それらはデータストアエンティティの参照プロパティとどのように関連していますか?
エンティティ グループ/祖先のもう 1 つの利点は、(結果整合性ではなく) 強い整合性の島を作成できることです。
たとえば、プロジェクトとそのタスクを作成できます。祖先がなければ、タスクを「クローズ」し、プロジェクトのタスク リスト画面に戻り、開いているタスクのクエリを実行できます。結果整合性のために、閉じたばかりのタスクがまだ表示される可能性があります。クエリは、更新がまだ複製されていないサーバーに対して解決された可能性があります。
ただし、祖先を使用すると、強力な一貫性が得られます。したがって、タスクからプロジェクトへの単純な外部キーの代わりに、プロジェクトをプロジェクト タスクの祖先にします。これで、タスクのクエリを実行するときに、プロジェクト キーも指定して祖先クエリにできます。結果は強い一貫性があり、閉じたばかりのタスクが結果の一部になることはありません。
通常使用される例は、著者とその本です。
各本はデータストアに個別のエンティティとして保存され、その名前と著者はモデルのフィールドとして保存されます。
単一の著者によるすべての本を知りたい場合は、次のようなクエリを実行できます。
book.author == desired_author
しかし、祖先を使用すると、各本を保存して、モデル (新しい作成者モデル) をその親 (祖先) に設定することもできます。
これで、「この著者を親とするすべての本を見せて」と簡単に言うことができます。
むしろ、「この祖先のすべての子を見せて」と、その著者によるすべての本が返されます。
この例ではあまり役に立たないように見えるかもしれませんが、「著者」の代わりに「ユーザー」があり、「本」の代わりに「掲示板メッセージ」と数万のメッセージがあると想像すると、突然非常に便利になりますユーザーごとにすべてのメッセージを検索できる (たとえば、自分のメッセージを表示する)。
https://developers.google.com/appengine/docs/python/datastore/queryclass#Query_ancestor
ancestor (ancestor)
Adds an ancestor filter to the query. The query will return only entities with the specified ancestor.
私が期待する各レコードを見つけるためのコストの点でもメリットがあります。
祖先を提供すると、(新しい) エンティティは、提供された祖先と同じエンティティ グループの一部になります。したがって、祖先として共通のルート エンティティを持つすべてのエンティティは、同じデータストア ノードに格納されます。この「局所性」により、トランザクション内のすべてのエンティティ (同じエンティティ グループ内) に対して多数のアクションを実行できます。次に、祖先クエリ (共通のルート エンティティの子であるエンティティのみを返すなど) を含むクエリに対して、これらのアクションは同時に (アトミックに) 発生するか、まったく発生しないように見えます。
参照: http://www2.mta.ac.il/~kirsh/download/MTA%20NoSQL%20Seminar/Lectures/GAE.pdf