search_after 在弹性搜索中如何工作？

Question

我一直在尝试在我们的应用程序中使用 Elasticsearch，但分页限制为 10k 对我们来说实际上是一个问题，并且由于必须超时问题，滚动 API 也不是推荐的选择。

\n

我发现 Elasticsearch 有一个叫做 search_after 的东西，它是支持深度分页的理想解决方案。我一直试图从文档中理解它，但它有点令人困惑，并且无法清楚地理解它是如何工作的。

\n

假设我的文档中有三列，id, first_name, last_name其中 ID 是唯一的主键。

\n

{\n    "size": 10,\n    "query": {\n        "match" : {\n            "title" : "elasticsearch"\n        }\n    },\n    "sort": [\n        {"id": "asc"}      \n    ]\n}\n

\n

我可以使用上面的查询来使用 search_after 功能吗？我在他们的文档中读到，我们必须在排序中使用多个唯一值，而不仅仅是一个 ( ID)，但正如你所知，在我的数据集中，我只有 ID 是唯一的。我可以做什么来将 search_after 用于我的数据集示例？

\n

我无法理解所述问题，如果我使用一个独特的决胜局进行排序？有人可以帮忙用外行人的话解释一下吗？

\n

https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-request-search-after.html

\n

\n

每个文档具有唯一值的字段应用作排序规范的\ntiebreaker。否则，具有相同排序值的文档的排序顺序将是未定义的，并可能导致结果丢失或重复。每个文档的 _id 字段都有唯一的值，但不建议直接将其用作决胜局。请注意，search_after 会查找第一个完全或部分匹配 tiebreaker\xe2\x80\x99s 提供的值的文档。因此，如果某个文档的决胜局值为“654323”，而您在“654”之后搜索，它仍会匹配该文档并返回在该文档之后找到的结果。文档值在此字段上被禁用，因此对其进行排序\n需要在内存中加载大量数据。相反，建议\n在另一个启用了文档值的字段中复制（客户端或使用设置的摄取处理器）\n_id 字段的内容，并使用\n这个新字段作为排序的决胜局。

\n

\n

Answer 1

在您的情况下，如果您的id字段包含唯一值并且具有类型keyword（或数字），那么您绝对没问题，可以使用它来分页search_after。

因此，第一个电话将是您问题中的电话：

{
    "size": 10,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
    "sort": [
        {"id": "asc"},
        {"score": "desc"}      
    ]
}

在您的响应中，您需要查看最后一次点击并sort从最后一次点击中获取值：

{
    "_index" : "myindex",
    "_type" : "_doc",
    "_id" : "100000012",
    "_score" : null,
    "_source": { ... },
    "sort" : [
      "100000012",                                <--- take this
      "98"                                        <--- take this
    ]
}

然后在下一次搜索调用中，您将在中指定该值search_after

{
    "size": 10,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    },
    "search_after": [ "100000012", "98" ],        <--- add this
    "sort": [
        {"id": "asc"}      
    ]
}

下一个结果集的第一个命中将是id: 100000013。就是这样。没有更多的事情了。

如果您始终使用完整id值进行排序，那么您所指出的问题与您无关。它的工作原理是您始终使用id先前结果中的最后一个值。如果您要添加"search_after": ["1000"]，那么您就会遇到他们提到的问题，但您没有理由这样做。