google-app-engine - GAE データストアの視覚的な理解

Question

Google App Engine (GAE) データストアの設計方法と使用方法を理解しようとしています。入門ページの説明から構造を視覚化するのに少し苦労しています。

視覚に敏感な私たちのために、誰かが図を使ってデータストアを説明できますか? または、視覚学習を念頭に置いた優れたチュートリアルをもう一度指摘しますか?

特に、GAEの使用方法を説明する図/図を含む回答を探しています。

Answer 1

2008 年の IO セッション「Under the Covers of the Google App Engine Datastore」では、データストアの視覚的な概要がわかりやすく説明されています。

https://sites.google.com/site/io/under-the-covers-of-the-google-app-engine-datastore

http://snarfed.org/datastore_talk.html

その他の IO トークについては、 https ://developers.google.com/appengine/docs/videoresources をご覧ください。

Answer 2

非常に単純化して、GAE はハッシュマップのハッシュマップとして表示できることを理解しました。

つまり、次のように表示できます。

Answer 3

マインドモデルが違うだけで、ここに正解はないと思います。あなたのプログラミングのバックグラウンドに応じて、私の知識が啓発的であるか、不安であるか、またはその両方であると感じるかもしれません。私は、データストアを、任意の名前空間内の任意の種類のすべてのエンティティ データと、すべてのユーザーのすべての GAE アプリで構成される、単一の巨大な分散型のキー値コレクションであると考えています。1 つのバケットはエンティティ グループと呼ばれます。これには、appID、名前空間、種類、エンティティ ID、または名前で構成されるルート キーがあります。エンティティ グループには、ルート キーを拡張するキーを持つ 1 つ以上のエンティティが存在します。ルート キー自体に属するエンティティは、存在する場合と存在しない場合があります。1 つのエンティティ グループ内の操作はアトミック (トランザクション) です。エンティティは単純な地図のようなデータ構造です。2 つの組み込みインデックス (昇順および降順) は、インデックス エントリの 2 つの巨大な並べ替えられたコレクションです。各インデックス エントリは、appID、名前空間、種類、プロパティ名、プロパティ タイプ、プロパティ値、エンティティ キーのデータ構造です。各エンティティの各プロパティの (自動) インデックス付けされた値ごとに、そのようなインデックス エントリが 2 つ作成されます。エンティティ キーのみを含む別のインデックスがあります。ただし、カスタム インデックスは、appID、名前空間、インデックス タイプ、結合されたインデックス値、エンティティ キーを含むエントリを持つ、さらに別の並べ替えられたコレクションに移動します。これは、メタデータを使用するデータストア全体の唯一の部分です。これは、結合されたインデックス値がエンティティからどのように形成されるかをストアに伝えるインデックス定義を格納します。これは私の心に焼き付いている図であり、データストアを満足させる方法を知っています。名前空間、種類、プロパティ名、プロパティ タイプ、プロパティ値、エンティティ キー - この順序で。各エンティティの各プロパティの (自動) インデックス付けされた値ごとに、そのようなインデックス エントリが 2 つ作成されます。エンティティ キーのみを含む別のインデックスがあります。ただし、カスタム インデックスは、appID、名前空間、インデックス タイプ、結合されたインデックス値、エンティティ キーを含むエントリを持つ、さらに別の並べ替えられたコレクションに移動します。これは、メタデータを使用するデータストア全体の唯一の部分です。これは、結合されたインデックス値がエンティティからどのように形成されるかをストアに伝えるインデックス定義を格納します。これは私の心に焼き付いている図であり、データストアを満足させる方法を知っています。名前空間、種類、プロパティ名、プロパティ タイプ、プロパティ値、エンティティ キー - この順序で。各エンティティの各プロパティの (自動) インデックス付けされた値ごとに、そのようなインデックス エントリが 2 つ作成されます。エンティティ キーのみを含む別のインデックスがあります。ただし、カスタム インデックスは、appID、名前空間、インデックス タイプ、結合されたインデックス値、エンティティ キーを含むエントリを持つ、さらに別の並べ替えられたコレクションに移動します。これは、メタデータを使用するデータストア全体の唯一の部分です。これは、結合されたインデックス値がエンティティからどのように形成されるかをストアに伝えるインデックス定義を格納します。これは私の心に焼き付いている図であり、データストアを満足させる方法を知っています。エンティティ キーのみを含む別のインデックス。ただし、カスタム インデックスは、appID、名前空間、インデックス タイプ、結合されたインデックス値、エンティティ キーを含むエントリを持つ、さらに別の並べ替えられたコレクションに移動します。これは、メタデータを使用するデータストア全体の唯一の部分です。これは、結合されたインデックス値がエンティティからどのように形成されるかをストアに伝えるインデックス定義を格納します。これは私の心に焼き付いている図であり、データストアを満足させる方法を知っています。エンティティ キーのみを含む別のインデックス。ただし、カスタム インデックスは、appID、名前空間、インデックス タイプ、結合されたインデックス値、エンティティ キーを含むエントリを持つ、さらに別の並べ替えられたコレクションに移動します。これは、メタデータを使用するデータストア全体の唯一の部分です。これは、結合されたインデックス値がエンティティからどのように形成されるかをストアに伝えるインデックス定義を格納します。これは私の心に焼き付いている図であり、データストアを満足させる方法を知っています。