0

在 Java 中的 Google App Engine Datastore HRD 中，

我们不能直接使用 Query 对象或 GQL 进行连接和查询多个表

我只想知道我的想法是否正确

如果我们像父级 - 子级 - 子级一样按节点构建索引

节点 - 键 - 索引属性 - 设置

如果我们想收集所有子孩子和孙子的。我们可以收集层次过滤条件中匹配的所有键，并提供键的结果

在 Memcache 中，我们可以保存每个键并指向数据库实体，如果缓存没有也可以在使用一组键的单个查询中获取，我们可以从数据库中获取所有记录。

优点

1) 快速检索 - Google 建议使用按键获取实体。

2）单个事务足以收集多个表数据。

3) Memcache 和 Persistent Datastore 将代表相同的形式。

4）它只会扫描用户或父节点等组的相关数据。

缺点

1）数据库大小的元数据将增加，因此数据库大小增加。

2）如果单亲的索引需要超过 1MB，那么我们必须在数据库中拆分并另存为 blob。

这种结构是不是好方法。

如果我们在层次结构中有更深的层次，这将解决运行大量查询操作以收集所有依赖于父项的项目。

如果有多个父级 - 收集所有索引并获取与查询相关的键。使用键列表收集单个事务中的所有数据。

如果有人发现更多优点或缺点，请添加它们并证明这种方法是否正确。

非常感谢

克里希南

4

1 回答 1

2

这里有很多事情需要考虑：

Datastore不是关系数据库。您绝对不应该从表和连接的角度来处理您的数据存储。这将导致混乱且很可能是低效的设置。

您似乎正在尝试重新构建对 Datastore 的使用，以提供对数据的完整事务性和高度一致的使用。Datastore 无法原生提供此功能的原因是，提供这些保证和高可用性的效率太低了。

使用 Datastore，您希望能够提供支持每秒对不同实体进行许多（数千、数十万、数百万等）写入的能力。Datastore 提供实体组概念的原因是它允许开发人员指定特定的一致性范围。

考虑一个示例 todo 跟踪服务。您可以定义一个 User 和一个 Todo 种类。您不会希望为所有 Todos 提供强一致性，因为每次用户添加新便笺时，底层系统都必须确保它与所有其他用户写便笺的事务性放在一起。另一方面，使用实体组，您可以说单个用户代表您的一致性单位。这意味着当用户编写新便笺时，必须使用对该用户便笺的任何其他修改进行事务性更新。这是一个更好的一致性单位，因为随着您的服务扩展到更多用户，它们不会相互冲突。

您正在谈论创建和管理自己的索引。从效率的角度来看，您几乎肯定不想这样做。此外，您必须非常小心，因为您似乎会对代表您的表的单个实体/实体范围进行大量写入。这是一个已知的Datastore 反模式。

Datastore 的难点之一是每个项目可能有非常不同的要求，因此数据布局也可能不同。对于如何构建数据，绝对没有一种适合所有人的方式，但这里有一些资源：

于 2014-04-23T17:05:08.160 回答