google-app-engine - 寻找 Google App Engine 的非规范化建议

Question

我正在开发一个将在 GAE 上运行的系统，该系统将有多个相关实体，我不确定存储数据的最佳方式。这篇文章是向可能有类似经历的其他人征求意见....

系统将有用户、配置文件数据和图像。这些用户将能够创建“事件”并向其中添加日记条目。出于系统的目的，“事件”中可能会有 1 或 2 个日记条目，超过 10 个的任何事情都可能永远不会发生。其他用户也将能够向用户的条目添加评论，其中流行的条目可能有数百甚至数千条评论。当随机访问者使用该系统时，他们应该能够看到最新事件(最新事件，由其中包含最新日志条目的事件定义)、按标签搜索以及执行基本文本搜索。然后在选择要查看的事件后，它应该与所有日记条目和所有用户评论一起显示，用户图像和评论一起显示。用户还应该有一种 self 管理页面，以查看/修改/删除他们的事件以及查看/修改/删除他们对其他事件所做的评论。因此，在普通 RDBMS 上执行所有这些操作只会查询跨多个表的一些大连接。在 GAE 上，它显然需要以不同的方式工作。以下是我对实体设计的初步想法:

• 事件实体 - id、名称、时间戳、列表 标签的属性，查看次数， 创建者的用户名，创建者的个人资料 图片id，日记条目数 它包含评论总数 它包含，对包含的日记条目的最后更新的时间戳，用于搜索的索引词的列表属性(从包含的日记条目的文本构建/更新)
• JournalEntry 实体 - 时间戳， 日志文本，事件名称， 创建者的用户名，创建者的个人资料 图片id，评论列表属性 (包含评论者用户名和 图片编号)
• 用户实体 - 用户名、密码哈希、电子邮件、订阅事件的列表属性、创建日期的时间戳、图像 ID、发布的评论数、创建的事件数、创建的日记条目数、上次日记事件的时间戳<
• UserComment 实体 - 用户名、被评论事件的 id、被评论事件的标题
• TagData 实体 - 标签名称、带有标签的事件数

所以，我想听听这里的人们对设计的看法以及应该进行哪些更改以帮助它更好地扩展。谢谢!

Answer 1

• 与其将 Event.id 存储为属性，不如使用自动嵌入到每个实体的 key 中的 ID , 或设置唯一 key names在实体上创建实体。
• 你有很多选择来模拟 Event 和 JournalEntry 之间的关系:你可以使用 ReferenceProperty，你可以父级 JournalEntries 到 Events 并使用祖先查询检索它们，或者您可以在 Event 上存储 JournalEntry 键 ID 或名称的列表，并且使用键查询批量检索它们。使用真实分布的虚拟数据尝试一些事情，并使用 appstats看看什么最有效。
• UserComment 引用了一个Event，而JournalEntry 引用了一个UserComments 列表，这有点令人困惑。 UserComment 和JournalEntry 之间有关系吗？或者就在 UserComment 和 Event 之间？
• 坚持这么多的计数是昂贵的。当我发表评论时，您将编写一个新的 UserComment 实体并更新我的 User 实体和一个 JournalEntry 实体以及一个 事件实体。您期望每个 Event 的 UserComments 数量使得将所有内容都包含在同一个实体组中是不明智的，这意味着您不能以事务方式执行这些写入，因此您将执行它们是串行的，并且实体可能存储在不同的网络节点上，使整个操作变慢；而且你也会对一致性问题持开放态度。您可以不使用其中一些计数并考虑将其他计数存储在内存缓存中吗？
• 当您从数据存储中获取一个Event 时，您实际上并不关心它的搜索索引词列表，并且从 Protocol Buffer 中检索和反序列化它们是有代价的。您可以通过将每个 Event 的搜索索引词拆分为单独的子 EventIndex 实体来解决这个问题。然后您可以在您的搜索词上查询 EventIndex，只获取与您的搜索匹配的 EventIndexes 的 EventIndex 键，派生相应的 Events ' 键与 key.parent()，并通过键获取 Events，无需为搜索索引词列表的检索或反序列化付费。 Brett Slatkin 解释了这个策略 here在 14:35。
• 更新 Event.viewCount 将失败，如果您对任何 Event 快速连续有大量 View ，因此您应该尝试计数器 sharding .

祝你好运，并告诉我们你通过尝试所学到的东西。