Appengine Search API与数据存储区

我正在尝试决定是否应该将App-engine Search API或Datastore用于App-engine Connected Android Project。谷歌文档的唯一区别是

…索引搜索可以找到不超过10,000个匹配的文档。 App Engine数据存储可能更适合需要检索非常大的结果集的应用程序。

鉴于我已经非常熟悉数据存储区：假设我不需要10,000个结果，有人会帮助我吗？

使用Search API与使用数据存储区查询是否有任何好处（根据上面的引用，使用其中一个似乎是明智的）？在我的情况下，最终用户必须能够搜索，更新现有条目并创建新实体。例如，如果我的应用是书店，则用户必须能够添加新书，向现有书籍添加评论，搜索特定书籍。
我的数据结构使得内容将由最终用户提供。文档与数据存储实体：哪个更新更便宜？ $$等
它们可以相互补充：数据存储和搜索API吗？有什么好处？为什么有人会考虑将两者配对？捕获/成本是多少？

关键的区别在于，使用数据存储区，您无法在实体内部进行搜索。如果您有一本名为“战争与和平”的书，如果用户在搜索框中输入“战争和平”，则无法找到它。同样的评论等等。因此，它不是一个真正的选择。

其他一些信息：

数据存储区是一个事务系统，在许多用例中很重要。搜索API不是。例如，您不能在单个事务中的搜索索引中放置和删除文档。
数据存储区与像Cassandra这样的NoSql DB有很多共同之处，而搜索API实际上是一个文本搜索引擎，与Lucene非常相似。如果您了解反向索引的工作原理，您将更好地了解搜索API的工作原理。
将数据存储区API和搜索API的使用结合起来的一个很好的理由是，数据存储区很难做出搜索API非常容易处理的某些类型的查询（例如，自由文本查询，地理空间查询）。因此，您可以将主要实体存储在数据存储区中，但如果需要以数据存储区不允许的方式进行搜索，则可以使用搜索API。接下来，我认为如果数据存储区和搜索API更紧密地集成在一起会很好，例如让你对索引的文本字段进行自由文本搜索，其中app引擎会在幕后为你自动创建一个搜索文档索引。

Search API中最严重的内容是最终一致性，如下所述： https ： //developers.google.com/appengine/docs/java/search/#Java_Consistency

这意味着当您使用Search API添加或更新记录时，它可能不会立即反映更改。想象一下，用户上传书籍或更新其帐户设置的情况，没有任何变化，因为尚未更改所有服务器。

我认为Search API只对一件事有好处：搜索。它基本上充当数据存储区中数据的搜索引擎。

所以我的建议是将数据保存在用户期望立即产生结果的数据存储区中，并使用Search API搜索用户不希望立即产生结果的数据。

数据存储区仅提供一些查询运算符（=，！=，<，>），执行嵌套filter和多个不等式将成本高昂或不可能（超时），搜索结果可能会产生大量误报。您可以通过标记化来进行部分字符串搜索，但这会使您的实体膨胀。解决这些限制的最佳方法是使用结构化属性和/或祖先查询。

另一方面，搜索API在搜索文档上运行全文搜索，这比NDB查询更快，更准确，而不依赖于标记化数据。下行是依赖于保持最新的数据。

使用数据存储处理您的数据（创建，更新，删除），然后运行一个函数将这些数据作为文档和集群使用索引，然后使用搜索API运行搜索。