将 GAE Search API 与 Datatstore 集成答案

【问题标题】：Integrating GAE Search API with Datatstore将 GAE Search API 与 Datatstore 集成
【发布时间】：2017-04-10 07:06:45
【问题描述】：

当一个文档同时存储到云数据存储和搜索索引中时，是否可以从搜索索引查询，而不是返回搜索索引文档，而是从云数据存储返回每个对应的实体？换句话说，我本质上希望我的搜索查询返回数据存储查询将返回的内容。

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

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

【问题讨论】：

【解决方案1】：

对此没有一流的支持，最好的办法是使文档 ID 与数据存储键匹配，并通过单个 DAO/存储库层路由所有 put/get/search 请求，以确保某种程度的一致性。

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

【讨论】：

【解决方案2】：

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

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

【讨论】：

您能否详细说明您将如何存储数据存储键等对象？ Search API 似乎不支持这种数据类型。我只是问，因为数据存储区中的某些值是 ndb KeyProperties，它们引用其他实体，因此将这些类型的数据传输到 Search API 似乎不是一个可行的选择。
我更喜欢存储实体 ID 而不是键，因为它们占用的空间更少，但如果您更喜欢/需要存储键，任何数据存储键都可以转换为字符串然后返回 - 有标准此类转换的方法。
这仅适用于某些数据 - 回想一下，搜索服务仅支持日期，而不是时间，并且数字的精度和比例限制会阻止您存储许多数字，例如长整数。搜索 API 确实不适合用作数据存储，除非在特定情况下 - 这可能适合您，也可能不适合
@Nick - 您也可以将时间转换为 ISO 字符串，搜索 API 本身使用“创建时间”作为文档的默认排名。我当然不建议使用 Search API 来代替 Datastore，但有时在文档中存储几个字段可能会很有用。我更喜欢使用 Datastore 进行搜索，因为它允许我实现部分单词搜索。