使用Java中的Google App Engine数据存储区HRD
我们无法使用Query对象或GQL直接进行连接和查询多个表
我只是想知道我的想法是否正确
如果我们按照父级的子级顺序构建索引 - 子级 - 按节点划分的大孩子
节点 - 钥匙 - IndexedProperty - 设置
如果我们想要收集所有子孩子＆amp;大孩子。我们可以收集在层次结构过滤条件中匹配的所有键，并提供键的结果
并且在Memcache中我们可以保存每个密钥并指向数据库实体，如果缓存在单个查询中没有使用密钥集，我们可以从数据库中获取所有记录。
优点
1）快速检索 - Google建议按键使用获取实体。
2）单一交易足以收集多个表格数据。
3）Memcache和Persistent Datastore将代表相同的形式。
4）它只扫描相关数据到组，如用户或父节点。
缺点
1）数据库大小的元数据将增加，因此数据库大小会增加。
2）如果单亲的索引占用超过1MB，那么我们必须在数据库中拆分并另存为blob。
这种结构是不错的方法。
如果我们在层次结构中有更深层次，这将解决运行大量查询操作以收集所有依赖于父项的项目。
如果有多个父母 - 收集所有索引并获取与查询相关的密钥。 使用密钥列表收集单个事务中的所有数据。
如果有人发现更多优点或缺点请添加并证明这种方法是否正确。
非常感谢
克里希南
答案 0 :(得分：2)
这里有很多事情需要考虑：
数据存储区为not a relational database。您绝对不应该从表和连接角度接近数据存储。它将导致混乱且极可能效率低下的设置。
您似乎正在尝试重新构建数据存储区的使用，以提供完整的事务性和强烈一致的数据使用。数据存储无法原生提供的原因是提供这些保证以及高可用性效率太低。
使用数据存储区，您希望能够支持每秒向不同实体提供许多（数千，数十万，数百万等）写入。数据存储区提供实体组概念的原因是它允许开发人员指定特定的一致性范围。
考虑一个示例todo跟踪服务。您可以定义User和Todo类型。您不希望为所有Todos提供强一致性，因为每次用户添加新笔记时，底层系统都必须确保它与所有其他用户编写笔记进行交易。另一方面，使用实体组，您可以说单个用户代表您的一致性单位。这意味着当用户编写新笔记时，必须通过对该用户笔记的任何其他修改进行交易更新。这是一个更好的一致性单位，因为当您的服务扩展到更多用户时，他们不会互相冲突。
您正在谈论创建和管理自己的索引。从效率的角度来看，你几乎肯定不想这样做。此外，您必须非常小心，因为您似乎会对表示您的表的单个实体/实体范围进行大量写入。这是一个已知的Datastore anti-pattern。
数据存储区的一个难点是每个项目可能有不同的要求，因此数据布局也不同。对于如何构建数据，绝对没有一种尺寸适合所有，但这里有一些资源：