0

Amazon S3 のようなアプリケーションのデータ モデルを設計する必要があります。この問題を、ユーザー、バケット、オブジェクトという 3 つの主要な概念に単純化してみましょう。このモデルを設計するには多くの方法がありますが、ここでは 2 つ挙げます。

  1. 3 種類 - ユーザー、バケット、オブジェクト。各オブジェクトには、その親としてバケットがあります。各バケットには、その親としてユーザーがあります。ユーザーはルートです。

  2. 動的種類 - ユーザーはユーザーの種類に保存され、バケットはバケットの種類に保存されます - #1 と同じです。ただし、バケット内のオブジェクトは、「<BucketID>_Object」という名前の動的な種類に格納されます。バケットとオブジェクト エンティティの間に親子関係はなくなりました。この関係は、オブジェクトの種類の名前によって確立されます。

#1 はもちろん、より直感的で伝統的なモデルです。#2 は急進的であると主張する人もいれば、ばかげていると言う人もいるかもしれません。

なぜ私は＃2について考えているのですか？- 私のアプリケーションでは、オブジェクトに定義されたプロパティがバケットごとに異なる場合があります。これらのプロパティは、バケットの作成時にユーザーによって指定されます。また、オブジェクトのすべてのプロパティはクエリ可能である必要があります。バケットごとの動的なオブジェクトの種類により、これらの要件をサポートできます。さらに、オブジェクトの種類がルートの種類になったため、先祖フィルターを適用する必要がなくなりました。つまり、各オブジェクト プロパティのインデックスを無料で取得できます。モデル #1 では、祖先フィルターを適用する必要があります。つまり、クエリを実行するすべてのプロパティに対してカスタム インデックスが必要です。

雑な説明で申し訳ありません。わからなかったらもっと頑張ります。

私の質問は - #2 は完全に法外なモデルですか? ＃2では、私の種類は潜在的に数万に及ぶ可能性があります. それは大丈夫ですか？カスタム インデックスの数に制限があることは理解しています。しかし、動的な種類にカスタム インデックスを作成するのではなく、自動インデックスのみに依存しています。

ありがとう、キール

4

1 に答える 1

4

どちらにも問題があります。＃1は基本的に問題ありませんが、祖先の代わりに参照プロパティを使用し、オブジェクトの種類をExpandoにします。

バケットがユーザーから派生し、オブジェクトがバケットから派生する問題は、ユーザーが作成するすべてのバケットとオブジェクトが同じエンティティ グループに存在することを強制することです。個々のユーザーのデータはすべて同じデータストア ノードに格納する必要があるため、パフォーマンスとスケーラビリティが制限されます。エンティティ グループは、同じトランザクションで複数のエンティティを操作する必要がある場合に役立ちます。所有権のモデル化だけが必要な場合は、ReferenceProperty.

私のアプリケーションでは、オブジェクトに定義されたプロパティはバケットごとに異なる場合があります。これらのプロパティは、バケットの作成時にユーザーによって指定されます。また、オブジェクトのすべてのプロパティはクエリ可能である必要があります。

Expandoは、これらの両方を提供します。プロパティはその場で定義でき、自動的にインデックスが作成されます。

同じ種類の 2 つのエンティティが同じプロパティ セットを持つ必要はありません。種類は単なる名前です。いかなる種類のスキーマも定義または強制しません。その場でそれらの束を作成しても、何も得られません。

于 2010-07-23T02:26:17.050 に答える