如何解决ElasticSearch |高效分页,可处理1万多个文档
我有一个将Elasticsearch作为后端存储的微服务。现在,我有多个索引,这些索引中插入了成千上万的文档。
现在,我需要公开那些索引的GET API。 GET /employees/get
。
我已经使用scroll和search_after经历了ES分页。但是他们两个都需要诸如scroll_id和search_after(key)之类的元信息才能进行分页。
现在,令人担忧的是我的微服务不应公开这些scroll_ids或search_after。使用当前方法,我最多可以列出1万个文档,但此后不能列出。而且我不希望微服务的用户了解后端存储或有关它的任何信息。那么如何在Elasticservice中实现这一目标?
我想到以下方法:
-
将scroll_id存储在内存中,并根据该结果检索结果以用于后续查询。获取查询如下:
GET /employees/get?page=1
默认情况下,每页将包含1万个文档。 -
在内部通过GET API实施滚动API,并将所有匹配的文档返回给用户。但这增加了延迟和内存。因为有时我可能会在一次调用中向用户返回10万份文档。
-
使用搜索字符串公开GET API。默认情况下,返回10k文档,并且进一步,结果将使用searchstring刷新,如下所述:
让我们说GET /employees/get
返回10k文档。并接受query_string以使用n gram丰富10k的自动建议。然后,我们每次都会显示最有效的10k文档。我知道这不是实际的分页,但是以某种方式也可以解决问题。这是我的计划B。
编辑:
这是我的用例:
返回公司员工名单。员工超过10万。因此,我必须在页面中返回结果。 GET /employees/get?from=0&size=1000
和GET /employees/get?from=1001&size=1000
但是一旦我从+ size到达10k,ES就会拒绝查询。
请提出在以ES作为后端存储的微服务中实现分页的理想方法,而不是让用户了解ES内部的情况。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。