0

将文档同时存储到云数据存储和搜索索引时,是否有可能在从搜索索引查询而不是返回搜索索引文档时,从云数据存储返回每个相应实体代替?换句话说,我基本上希望我的搜索查询返回数据存储查询将返回的内容。将GAE搜索API与数据存储集成

更多背景:当我在数据存储中创建实体时,我传递实体标识,名称和描述参数。建立一个搜索文档,使其doc ID与相应的实体ID相同。目标是创建一个前端搜索实现,该实现将利用全文搜索API根据文本查询检索所有相关文档。但是,我想返回存储在数据存储实体中的该文档的所有详细信息。

要做到这一点的唯一方法是为查询返回的每个搜索doc_id创建一个键,然后使用get_multi(keys)来检索所有相关的数据存储实体?

+0

我猜想转换为纯搜索文档的替代方法是仅依赖数据存储查询并通过构建多个索引来重新创建全文搜索类型功能。希望有人比这些选择更有见地的想法。 – yoonjesung

+0

您需要对您的问题更具体,目前尚不清楚您想要回答什么。 – danielx

回答

1

对此没有一流的支持,最好的选择是使文档ID匹配数据存储区密钥,并通过单个DAO /存储库层路由所有put/get/search请求以确保一定程度的一致性。

您可以使用并行异步写入来延迟等待时间,但对于不参与事务的搜索,您无能为力。它也没有定义的一致性,所以假设它是最终的,并且可能比数据存储索引传播慢得多。

+0

如果我想拥有强大一致的数据,那么我将不得不求助于仅使用数据存储进行事务处理吗?如果是这样,那么我是否必须创建自己的基于文本的搜索到数据存储查询的实现? – yoonjesung

+0

如果您想要强烈一致的查询,则必须在数据存储中使用祖先查询。您可以自行干预并分词,并将它们存储在数据存储区中,这几乎与搜索服务所做的一样。 – Nick

0

除了文本内容之外,您还可以在Search API文档中存储您需要的任何信息。

这将允许您在一次调用中检索所有数据,但可能会在Search API文档和数据存储实体中存储一些重复信息。显然,重复数据并不理想,但它对于很少更改数据(例如文档时间戳,作者ID,标题等)可能是一个很好的选择,因为它可以显着提高性能。

+0

您能否详细介绍一下如何去存储数据存储键等对象? Search API似乎不支持这种数据类型。我只问,因为数据存储中的某些值是引用其他实体的ndb KeyProperties,因此将这些类型的数据传输到Search API似乎不是一个可行的选项。 – yoonjesung

+0

我更喜欢存储实体ID而不是密钥,因为它们占用的空间少得多,但如果您希望/需要存储密钥,则任何数据存储区密钥都可以转换为字符串,然后返回 - 这些转换有标准方法。 –

+0

这仅适用于某些数据 - 请记住,搜索服务仅支持日期,而不支持时间,并且数字上存在精确度和比例限制,以防止存储许多数字,例如long。 Search API真的不适合作为数据存储,除非在特定情况下 - 这可能对您有用,否则它可能不会 – Nick