java - 在 NoSQL/BigTable (GAE) 中建模无限规模关系是否可能？

Question

我的团队正在使用 GAE (Java) 编写一个应用程序，这让我对 BigTable 等面向对象数据库中实体关系建模(特别是多对多)的可扩展性产生了疑问。

在 App Engine 数据存储区中对无主一对多和多对多关系进行建模的首选解决方案(请参阅 Entity Relationships in JDO )似乎是键列表。然而，谷歌警告:

"There are a few limitations to implementing many-to-many relationships this way. First, you must explicitly retrieve the values on the side of the collection where the list is stored since all you have available are Key objects. Another more important one is that you want to avoid storing overly large lists of keys..."

说到过大的键列表，如果您尝试以这种方式进行建模，并假设您为每个键存储一个 Long，那么每个实体的限制为 1MB，理论最大数量为每个实体的关系约为 130k。对于一个主要优势是可扩展性的平台来说，这实际上并没有那么多关系。因此，现在我们正在考虑可能需要超过 13 万个关系的分片实体。

文章 Modeling Entity Relationships 中概述了一种不同的方法(关系模型)作为 AppEngine 开发人员资源中掌握数据存储系列的一部分。然而，即使在这里，谷歌也对关系模型的性能发出了警告:

"However, you need to be very careful because traversing the connections of a collection will require more calls to the datastore. Use this kind of many-to-many relationship only when you really need to, and do so with care to the performance of your application."

所以现在您会问:“为什么每个实体需要超过 13 万个关系？” 嗯，我很高兴您提出这个问题。让我们以一个拥有 100 万用户的 CMS 应用程序为例(嘿，我可以做梦吧？!)

用户可以上传内容并与以下人员共享: 1. 公开 2. 个人 3. 团体 4.任意组合

现在有人登录并导航到仪表板，其中显示了他们在任何组中所连接的人员的新上传内容。此仪表板应包含公共(public)内容以及专门与该用户或该用户所属的组共享的内容。还不错吧？让我们深入研究一下。

public class Content {
  private Long id;
  private Long authorId;
  private List<Long> sharedWith; //can be individual ids or group ids
}

现在，我获取 id 允许查看的所有内容的查询可能如下所示:

List<Long> idsThatGiveMeAccess = new ArrayList<Long>();
idsThatGiveMeAccess.add(myId);
idsThatGiveMeAccess.add(publicId); //Let's say that sharing with 0L makes it public
for (Group g : groupsImIn)
    idsThatGiveMeAccess.add(g.getId());

List<Long> authorIdsThatIWantToSee = new ArrayList<Long>();
//Add a bunch of authorIds

Query q = new Query("Content")
            .addFilter("authorId", Query.FilterOperator.IN, authorIdsThatIWantToSee)
            .addFilter("sharedWith", Query.FilterOperator.IN, idsThatGiveMeAccess);

显然我已经违反了几条规则。也就是说，使用两个 IN 滤波器会爆炸。即使单个 IN 过滤器的任何尺寸接近我们所讨论的极限也会爆炸。除此之外，假设我想限制并翻阅结果......不不!如果使用 IN 过滤器则无法做到这一点。我想不出任何方法可以在单个查询中执行此操作 - 这意味着如果没有大量的读取时处理和管理多个游标，您就无法对其进行分页。

以下是我能想到的用于执行此操作的工具:非规范化、分片或关系实体。然而，即使有了这些概念，我也不知道如何以可扩展的方式对这些数据进行建模。显然这是可能的。谷歌和其他公司一直在这样做。我就是不明白怎么办。 任何人都可以阐明如何对此进行建模，或者向我指出任何基于 NoSQL DB 的 cms 样式访问控制的好资源吗？

Answer 1

将 id 列表存储为属性将无法扩展。为什么不简单地为每个新关系存储一个新对象？ (就像在sql中一样)。该对象将为您的 cms 存储两个属性:共享项目的 id 和用户 id。如果与 1000 个用户共享，您将拥有 1000 个用户。查询给定用户是很简单的。列出给定项目的权限或用户与其共享的内容的列表也很容易。