appengine ndb上类似图形的实体的最佳实践

Question

我正在为一个大型国际品牌设计一个g +应用程序。我需要创建的实体几乎是图形的形式，因此很多连接节点的多对多关系（弧）可以在两个方向上遍历。我正在网上阅读所有可读的文档，但到目前为止我还没有找到任何特定于ndb设计最佳实践和指南的内容。不幸的是，我在nda之下，并且无法透露应用程序的详细信息，但它几乎可以与科学会议的背景，作业，论文和主题相匹配。

在目前设想的实体列表下方（上下文移位以匹配上述主题）：

• 组织（例如acm）
• 会议（例如acm multimedia）
• 会议问题（例如acm multimedia 13）
• 会议轨道（例如，nosql，机器学习，计算机视觉等）
• 作者（例如我自己）
• paper（例如“设计图像db for ndb”）

正如你所看到的，我可以通过任何方向（或从前端的角度来看）访问和遍历图表：

• 作者与合着者
• 作者参加会议曲目
• 会议跟踪论文
• ...

等等，你填写清单。

我想让它变得笔直且坚固，因为它会以很多p.r.启动。并且需要在内容和用户数量方面持续加班。我想从头编写它，因此设计我自己的模型，restful api来读/写这些数据，避免非rel django并保持表示层到最小的模板机制。我需要查看我工作的公司，但我们可能能够使用合适的开源许可证发布部分代码（理想情况下，为ndb模型提供一个安静的服务）。

如果有人能指出我正确的方向，那就太棒了。

谢谢！ 托马斯

[编辑：纠正与多对多关系相关的拼写错误]

Answer 1

在App Engine中实现一对多关系有两种方法。

1. 在实体A内部，存储实体B1，B2，B3的密钥列表。在旧数据库中，您将使用db.Key的ListProperty。在ndb中，你使用KeyProperty，重复= True。

2. 在实体B1，B2，B3内部，将KeyProperty存储到实体A.

如果您使用1：

• 当你有实体A时，你可以通过id获取B1，B2，B3。这可能比查询结果更加一致。
• 由于您在查询上保存了1个读取操作（假设您不计算获取实体A的成本），因此可能会稍微便宜一些。编写B实例稍微便宜一点，因为它只需要更新一个索引。
• 您可以通过A上的最大实体大小和索引属性数量来存储B实例的数量。这对于会议跟踪这样的事情是有意义的，因为通常只有有限数量的曲目没有去成千上万。
• 如果您需要任意排序B1，B2，B3的顺序，则在列表中按顺序存储它们比使用某些已排序的索引属性对它们进行排序更容易。

如果您使用2：

• 您只需要实体A的密钥即可查询B1，B2，B3。您实际上不需要获取实体A来获取列表。
• 你可以拥有几乎无限的B个实体。

Answer 2

经过深入研究，发现了什么：

• 没有一个设计模式可以遵循，这当然取决于具体的应用和数据建模（足够公平）
• 应采取措施以避免达到bottom of this page中列出的大小限制，主要针对单个实体大小（1mb），交易规模（10mb）和index limits
• 避免可能的实体规范化（例如，只有用于创建一组弧的实体），尽管googleplus开发人员在他们的演示应用中似乎使用了simple social graph

欢迎任何其他更详细的答案