Elasticsearch结合search_after与PIT实现分页的性能及影响咨询

数百并发用户的场景下该方案的可扩展性完全达标。每个PIT实例仅持有对应时间点的Lucene段引用，本身的内存开销只有KB级，单节点可以轻松支撑数千个活跃PIT实例，只要你集群的搜索吞吐量能匹配用户的分页查询请求，PIT本身不会成为扩展瓶颈。

正常情况下不会产生可感知的影响：

• PIT查询和普通查询共享集群的搜索线程池资源，只要你没有出现PIT查询量异常暴增的情况，普通搜索请求的延迟和成功率不会受影响。
• PIT持有的是历史段快照，和普通查询访问的最新索引版本完全隔离，不会出现数据一致性的互相干扰。

• 数据写入的实时性、写入延迟不会受到PIT的影响，新写入的数据会正常生成新的Lucene段，刷新后对新的查询可见。
• 唯一的负面影响来自段合并的空间回收环节：Lucene段合并完成后，原本要被删除的旧小段如果还被任何活跃的PIT引用，就会暂存在磁盘上直到所有引用它的PIT超时释放。对于变更速度快的大型索引，会带来额外的临时磁盘占用，如果你预留的磁盘空间不足，可能触发磁盘水位告警。

针对你提到的索引规模大、变更速度快的场景，可以做以下优化降低负面影响：

• 严格控制PIT的keep_alive参数，按照你预估的用户最长思考时间加1~2分钟的冗余即可，比如用户最多停留5分钟就设为6m，不要设置超过10分钟的有效期，大幅降低旧段的留存时间。
• 提前预留额外的磁盘空间，按照你的索引写入速率和PIT最长保留时间计算，至少预留30%以上的磁盘冗余，避免旧段未释放导致的磁盘占满问题。
• 可以定期监控集群的活跃PIT数量，如果出现异常激增的情况可以手动清理过期的PIT实例。

整体来看search_after + PIT是官方推荐的深度分页方案，对比from/size或者滚动查询的方案更适配UI分页的场景，只要做好参数控制完全可以满足你的需求。

内容的提问来源于stack exchange，提问作者vjgorla