问Objectify - AppEngine备选方案

EN

MongoDB的Morphia接口最初基于Objectify的早期版本。随着键/值存储的发展，MongoDB对GAE用户来说似乎相当熟悉。如果你正在寻找一个低痛苦的过渡，这可能是最好的选择。

请注意，有些事情(如即席查询和非最佳查询)在MongoDB中比较容易，但有些事情(如事务)则比较难。当然，还要确保它符合您的伸缩要求。

如果您继续使用App Engine，Java Datastore API页面建议使用Slim3，以及低级Datastore API和Objectify。

它还提到了JDO和JPA，但使用它们的原因是与相同接口的其他实现兼容，而这些实现是子集实现，所以兼容性是有限的。

Storing Data in Java页面列出了Google Cloud SQL和Google Cloud Storage的其他选项。这将需要对您的代码进行更大的更改。

一个不等式过滤器是App Engine的限制，而不是Objectify的限制，这对我们来说从来都不是问题，我们有一个非常大和复杂的应用程序，有近100种实体类型。关于如何绕过这一限制，有许多技巧。

我不知道为什么排序数据会有问题。只要对其编制了索引，您就可以基于任何标准进行排序-用户生成的或非生成的。也许您可以详细说明这一点，我们可以帮助您找到解决方案。

App Engine是一个非常不同的平台，对于那些只习惯于关系数据库的人来说，可能需要时间来学习和欣赏它的力量。您看到的限制实际上是一些特性-例如，一个不等式过滤器允许非常快(和一致)的查询时间，而不管实体的数量。我甚至可以说，应用程序越大，它从使用非关系(App Engine)数据存储中获得的好处就越多。

与迁移到完全不同的平台相比，学习如何使用App Engine可能需要更少的时间。

更新：

对于您的工厂问题，我建议使用以下方法(基于我掌握的关于您的数据模型和使用模式的有限信息)。

1. 如果用户可以向对象添加任意数量的自定义属性，则最终灵活的解决方案是将所有这些属性作为未索引的属性存储在数据存储中。然后，当用户发起查询时，您可以检索给定类型的所有实体，并在代码中对它们进行过滤，而不是依赖于数据存储索引。这看起来似乎是一种低效的方法，但添加和检索索引属性很少的实体比添加和检索索引属性多的实体要便宜得多。总体而言，即使您在每个自定义查询上过度阅读，但您的总成本最终可能会更低，除非您的用户添加了超过10k个同类实体。您甚至可以提前估计这一点，因为数据存储区在数据存储区查看器中显示每个实体上的写入操作数。

如果您在这些实体上有许多标准(非用户生成)的索引属性，则可以通过将每个实体拆分为一个标准部分来进一步优化此属性(例如，“工厂”)和具有最终用户生成属性的自定义部件("Plant_custom")。这样，对自定义部分的更新将更便宜，因为它不会触发对标准属性的索引重写。然后，如果查询涉及标准属性，则使用廉价的键查询检索与标准属性的搜索条件匹配的实体列表，然后使用廉价的get操作检索自定义实体(标准实体和自定义实体应该具有相同的ID)，最后根据自定义搜索条件进行过滤。

1. 一个完全不同的解决方案是为您的自定义属性使用App Engine Search API。它比数据存储区灵活得多，但您需要比较成本。尽管如此，与为数据存储中的每个自定义属性编制索引相比，这可能是一个更便宜的解决方案。