elasticsearch - 弹性搜索 | 超过 10k 个文档的高效分页

我有一个以弹性搜索作为后端存储的微服务。现在我有多个索引，其中插入了数十万个文档。

现在我需要为这些索引公开 GET API。GET /employees/get. 我已经使用滚动和 search_after 完成了 ES 分页。但是它们都需要像 scroll_id 和 search_after(key) 这样的元信息来进行分页。

现在担心的是我的微服务不应该公开这些scroll_ids 或search_after。使用当前的方法，我最多可以列出 10k 个文档，但之后就不行了。而且我不希望微服务的用户知道后端存储或任何有关它的信息。那么如何在弹性服务中实现这一点？

我有以下方法：

将 scroll_id 存储在内存中，并根据该结果检索结果以用于后续查询。获取查询如下： GET /employees/get?page=1默认情况下，每个页面将有 10k 个文档。
通过 GET API 在内部实现滚动 API，并将所有匹配的文档返回给用户。但这会增加延迟和内存。因为有时我最终可能会在一次调用中将 100k 文档返回给用户。
使用搜索字符串公开 GET API。默认情况下返回 10k 个文档，并且结果将使用 searchstring 刷新，如下所述：

可以说GET /employees/get返回 10k 个文档。并接受 query_string 以丰富 10k like 使用 n gram 的自动建议。然后我们每次都显示最有效的 10k 文档。我知道这不是实际的分页，但不知何故这也以一种骇人听闻的方式解决了问题。这是我的 B 计划。

编辑：这是我的用例：返回公司员工列表。有超过10万名员工。所以我必须在页面中返回结果。但是一旦我从+size 达到 10k，ES 就会拒绝查询GET /employees/get?from=0&size=1000。GET /employees/get?from=1001&size=1000

请建议以 ES 作为后端存储在微服务中实现分页并且不让用户了解 ES 内部的理想方法。

标签： elasticsearchlucenenosqlmicroservices