采用Elasticsearch辅助网站主数据库的方案是否可行？大分页问题咨询

一、主库+Elasticsearch的检索方案可行性 #

这个方案完全可行，而且是业内非常成熟的架构模式：

• 主数据库负责存储核心业务数据，处理增、删、改等写操作，保证数据的一致性和事务性；
• Elasticsearch作为专门的检索引擎，承接所有读请求（比如最新新闻列表展示、全文搜索），利用倒排索引特性，在数十万级数据的检索、排序场景下，性能远优于传统关系型数据库；
• 只需通过同步机制（比如CDC工具、Logstash或业务代码触发），将主库的增量/全量数据同步到ES即可，实现读写分离，极大减轻主库的查询压力。

二、关于展示数千页搜索结果的问题 #

技术上的可能性 #

从技术实现来说，通过from+size参数确实可以实现深分页（比如from=9990&size=10就能获取第1000页的10条数据），但官方明确不推荐这种做法，核心原因如下（基于Elasticsearch 7.17官方文档结论）：

Elasticsearch处理深分页请求时，需要在每个数据分片上先加载from+size条数据，再将所有分片的结果汇总到协调节点，进行全局排序、截断后，最终返回size条数据。

这种机制带来的关键问题：

• 内存占用过高：每个分片都要加载大量数据到内存，协调节点还要处理所有分片返回的海量数据，极易触发内存溢出，导致节点崩溃；
• 性能急剧恶化：随着from值增大，数据传输、排序的开销呈指数级上升，查询响应时间会变得无法接受，严重影响用户体验；
• 结果一致性差：如果分页过程中数据发生更新（比如新增、删除新闻），后续分页结果可能出现重复或遗漏，因为ES的分页基于请求时刻的数据快照，高并发场景下数据变化会导致分页逻辑混乱。

替代方案 #

如果需要支持大量数据的浏览，推荐使用以下方式：

• search_after API：以上一页最后一条文档的排序字段值作为游标，获取下一页数据，避免深分页的性能问题，适合前端无限滚动或分页场景；
• 限制最大分页页数：比如只允许用户翻到50页，超过则提示用户通过缩小搜索关键词范围、添加筛选条件来获取更精准的结果；
• 后台批量导出：如果是需要批量获取数据的场景（而非用户前端浏览），可以使用scroll API，但注意scroll会占用节点资源，使用后要及时清理。

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