使用 GAE 数据存储关系与平面类型设计答案

【问题标题】：Using GAE datastore relationship vs flat kind design使用 GAE 数据存储关系与平面类型设计
【发布时间】：2016-10-22 19:46:49
【问题描述】：

我们需要在 GAE 数据存储中实施。有一组文档（以百万计），每个文档都有一个所有者、一些 cmets 和与之相关的修订。

如果文档的所有者要离开组织，那么我们需要将文档的所有权更改为上次修订的人。我们还需要保留每个文档的修订和 cmets。这种所有权变更将由一个作业来实现，该作业将一个一个地处理每个文档。

在实体 Document、Comment 和 Revision 之间建立父子关系是否正确，例如 Document 是父级，Comment 和 Revision 作为其子级？或者以典型的 NoSql 方式，我们需要展平表格并制作单个实体？

典型的 NoSQL 实现只需要插入和读取，不需要更新。这是谷歌数据存储的工作方式吗？请澄清。

我们的研究表明我们可以建立关系，但这看起来更像是 RDBMS。

【问题讨论】：

这个问题太宽泛了。您应该尝试建模和原型制作。回来时会提出一些具体的实施问题。如果您将拥有可以更改的自有关系不要使用键中定义的父级来定义它。这意味着您无法更改所有权，但您必须复制并创建新实体。树和关系很好，重要的是查看您的访问模式并优化活动的实体。如果您的查询通常意味着连接，那么存储您需要的所有内容的中间实体就变得很重要。
我们可以看看你的文档格式，编辑成问题吗？就我个人而言，我认为 NoSQL 提倡的无模式格式导致的问题多于它解决的问题 - 因此，除非您需要 NoSQL 的原始速度，否则请使用传统的 RDBMS 并使用表对其进行建模。
@halfer 除非我不会将数据存储区归类为无模式
很公平@Tim，谢谢 - 不是我的领域。我同意这太宽泛了，希望 OP 回来修改它！

【解决方案1】：

要选择适当的架构设计，您应该明确计划如何处理数据并牢记数据存储限制。简而言之：

NoSql 方法（单个实体）
- 每个实体组每秒更新一次
- 您每次都读取和写入整个实体（投影查询除外）
父子关系（祖先关系）
- 以后无法更改
- 形成单个实体组，以便在读取查询时实现强一致性
- 每个实体组每秒更新一次！（因此，如果您的案例中有很多实时 cmets，这将不适合您）
RDBMS 方法（表和关系）
- 数据存储在多个表上没有连接（因此只在您不打算一起查询的表中拆分数据）
- 最终一致的读取

【讨论】：

这是一个很好的答案，但由于添加了 txtspk 而被破坏了。请不要这样做 - 第一语言不是英语的读者会很难过，而第一语言是英语的读者可能会厌烦阅读它。我无法想象输入you 而不是u 可以节省多少毫秒。谢谢！
@Ramiel，感谢您的回复，我怀疑我们是否在 No Sql 领域，我们应该展平表格，那么为什么 GAE 数据存储区的谷歌文档谈论关系和层次结构，即使这也可以变平。 link
因为扁平化有局限性（正如我提到的每种方法都有优点和缺点）：每秒一次更新（想象一下帖子的点赞或smth快速增长）、数据重复等。