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

Question

我正在为一个大的国际品牌设计一个g+应用程序。我需要创建的实体基本上是以图的形式出现的，因此很多连接节点的关系(弧)都可以在两个方向上进行遍历。我正在在线阅读所有可读的文档，但到目前为止，我还没有发现任何特定于ndb设计最佳实践和指南的内容。不幸的是，我在nda之下，不能透露应用程序的细节，但它可以将科学会议的背景与会议记录、作者、论文和主题进行一对一的匹配。

以下是迄今设想的实体清单(将上下文移到与所述主题相匹配的位置)：

• 组织(如acm)
• 会议(例如acm多媒体)
• 会议议题(例如acm多媒体13)
• 会议轨道(如nosql、机器学习、计算机视觉等)
• 作者(如本人)
• 纸(例如，“设计图，如数据库用于ndb")

如您所见，我可以通过任何方向(或面，从正面的角度)访问和遍历该图形：

• 作者与合著者
• 作者到会议轨道
• 会议轨道到论文
• ..。

以此类推，你把名单填上。

我想把它弄直和坚固，因为它将以大量的p.r启动。在内容和用户数量上，都需要不断地扩大加班。我想从头开始编写它，从而设计我自己的模型，restful来读取/写入这些数据，避免非rel django，并将表示层保持在最低限度的模板机制。我需要与我工作的公司联系，但我们可能能够以一个体面的开源许可证发布部分代码(理想情况下，ndb模型的restful服务)。

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

谢谢!托马斯

编辑:更正与多到多关系有关的错误。

Answer 1

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

1. 在实体A中，存储实体B1、B2、B3的密钥列表。在旧DB中，您将使用ListProperty of db.Key。在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

经过深入研究，这一发现：

• 没有单一的设计模式可遵循，这当然取决于具体的应用程序和数据建模(足够公平)
• 应采取措施避免达到本页底部中列出的大小限制，主要是针对单个实体大小(1mb)、事务大小(10mb)和指数极限。
• 避免可能的实体规范化(例如，实体只用于创建一组弧)，尽管googleplus开发人员似乎在他们的简单社会图演示应用程序中使用了

欢迎其他更详细的答案。