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

Question

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

以下是迄今为止设想的实体列表（根据所提到的主题改变上下文）：

• 组织（如acm）
• 会议（如acm多媒体）
• 会议议题（如acm多媒体13）
• 会议轨道（如nosql、机器学习、计算机视觉等）
• 作者（例如我自己）
• 纸张（例如“为ndb设计类似db的图形”）

如您所见，我可以访问并遍历图形的任何方向（或方面，从前端的角度来看）：

• 作者与合著者
• 会议曲目的作者
• 会议记录到报纸
• 。。。在

以此类推，你来填单子。在

我想把它说得直截了当，因为它会在发布时有大量的公关费用，而且在内容和用户数量上都需要不断地扩展。我想从头开始编写代码，从而设计我自己的模型，restfulapi来读/写这些数据，避免非rel-django，并将表示层保持为最小的模板机制。我需要和我工作的公司核实一下，但是我们也许可以用一个像样的开源许可证（理想情况下，是ndb模型的restful服务）来发布部分代码。在

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

谢谢！ 托马斯

[编辑：更正了与多对多关系相关的打字错误]

Answer 1

经过深入研究，发现：

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

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

Answer 2

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

1. 在实体A中，存储实体B1、B2、B3的键列表。在旧数据库中，可以使用数据库键. 在ndb中，您将使用带有repeated=True的KeyProperty。

2. 在实体B1、B2、B3中，将KeyProperty存储到实体a。

如果使用1：

• 当你有实体A时，你可以通过id获取B1，B2，B3，这可能比查询的结果更加一致。在
• 这可能稍微便宜一点，因为您在一个查询上保存了一个读取操作（假设您不计算获取实体a的成本）。编写B实例稍微便宜一点，因为它只需更新一个索引。在
• 根据A上的最大实体大小和索引属性的数量，您可以存储的B实例的数量是有限的。这对于像会议跟踪这样的事情来说是有意义的，因为通常轨道数量有限，不会达到数千个。在
• 如果您需要任意地对B1、B2、B3的顺序进行排序，那么将它们按顺序存储在列表中要比使用排序的索引属性排序要容易得多。在

如果使用2：

• 您只需要实体A的键就可以查询B1、B2、B3。实际上不需要获取实体A来获取列表。在
• 你可以拥有无限的B实体。在