0

我需要为类似 Amazon S3 的应用程序设计一个数据模型。让我们将问题简化为 3 个关键概念——用户、存储桶和对象。有很多方法可以设计这个模型——我将列出两种。

  1. 三种类型 - 用户、存储桶和对象。每个 Object 都有一个 Bucket 作为其父对象。每个 Bucket 都有一个 User 作为其父级。用户是根。

  2. 动态种类 - 用户存储在用户种类中，存储桶存储在桶种类中 - 与 #1 相同。但是，存储桶中的对象存储在名为“<BucketID>_Object”的动态类型中。桶和对象实体之间不再有父/子关系。这种关系是由对象种类的名称建立的。

#1 当然是更直观和传统的模型。有人可以说#2 是激进的，而其他人可能会说荒谬。

我为什么要考虑#2？- 在我的应用程序中，对象上定义的属性可能因存储桶而异。这些属性由用户在创建存储桶时指定。此外，对象的所有属性都必须是可查询的。每个桶的动态对象类型允许我支持这些要求。此外，因为我的对象种类现在是根种类，我不再需要应用祖先过滤器，这意味着我可以免费获得每个对象属性的索引。在模型 #1 中，我被迫应用祖先过滤器，这意味着我需要为每个要查询的属性创建一个自定义索引。

对于令人费解的解释，我深表歉意。如果不清楚，我会尝试更好。

我的问题是 - #2 是一个完全离谱的模型吗？使用#2，我的种类可能会达到成千上万。那样行吗？我了解自定义索引的数量是有限制的。但是我没有在我的动态类型上创建自定义索引，而只是依赖于自动索引。

谢谢， 凯尔

4

1 回答 1

4

两者都有问题。#1 基本上没问题，除了使用引用属性而不是祖先，并使您的对象类型成为 Expando。

桶来自用户而对象来自桶的问题在于，这迫使用户创建的每个桶和对象都存在于同一个实体组中。这限制了性能和可扩展性，因为所有单个用户的数据都必须存储在同一个数据存储节点上。当您需要在同一事务中操作多个实体时，实体组很有用。如果您只需要对所有权进行建模，请使用ReferenceProperty.

在我的应用程序中，对象上定义的属性可能因存储桶而异。这些属性由用户在创建存储桶时指定。此外，对象的所有属性都必须是可查询的。

Expando为您提供了这两者。您的属性可以动态定义，并且它们会自动编制索引。

没有什么要求两个相同种类的实体具有相同的属性集。种类只是名称；他们不定义或强制执行任何类型的模式。即时创建一堆它们不会给你带来任何东西。

于 2010-07-23T02:26:17.050 回答