网站开发流程ppt,产品外观设计报价,中网可信网站查询,中美关系最新消息2021文章目录前言常见的 Elasticsearch 分页设计方案1. from size 分页 (浅分页)2. scroll 分页 (游标分页/深分页)3. search_after 分页 (搜索后分页)4. 基于 PIT (Point In Time) 的 search_after 分页方案总结与对比核心建议资料获取前言
博主介绍#xff1a;✌目前全网粉丝4…文章目录前言常见的 Elasticsearch 分页设计方案1. from size 分页 (浅分页)2. scroll 分页 (游标分页/深分页)3. search_after 分页 (搜索后分页)4. 基于 PIT (Point In Time) 的 search_after 分页方案总结与对比核心建议资料获取前言博主介绍✌目前全网粉丝4Wcsdn博客专家、Java领域优质创作者博客之星、阿里云平台优质作者、专注于Java后端技术领域。涵盖技术内容Java后端、大数据、算法、分布式微服务、中间件、前端、运维等。博主所有博客文件目录索引博客目录索引(持续更新)CSDN搜索长路视频平台b站-Coder长路常见的 Elasticsearch 分页设计方案1.from size分页 (浅分页)这是最直观、最常见的分页方式类似于 MySQL 的LIMIT offset, size。工作原理from指定了跳过的初始文档数量size指定了返回的最大文档数量。例子查询第 6-10 条数据即第 2 页每页 5 条。GET/my_index/_search{query:{match_all:{}},from:5,// 跳过前5条size:5// 返回5条}2.scroll分页 (游标分页/深分页)专为一次性处理大量数据如数据导出、全量重建索引而设计不适合实时用户请求。工作原理首次查询创建一个快照和游标后续请求使用这个游标来获取剩余结果。搜索上下文会在指定时间如1m内保持活跃。例子导出所有符合条件的数据。a. 初始化 scroll 请求GET/my_index/_search?scroll1m// 保持搜索上下文1分钟{query:{match:{title:elasticsearch}},size:100// 每次滚动返回100条}响应中会包含一个_scroll_id。b. 后续获取请求POST/_search/scroll{scroll:1m,scroll_id:DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAC...很长的字符串}3.search_after分页 (搜索后分页)ES 5.0 引入是进行深分页的最佳实践适用于需要实时、有序地翻看大量数据的场景。工作原理使用上一页结果中的排序值作为“锚点”来获取下一页的结果。它避免了from size深度分页的性能问题。要求必须指定一个或多个唯一的、不重复的排序字段通常包括_id。例子按时间戳和 ID 进行深度分页。a. 获取第一页GET/my_index/_search{query:{match_all:{}},size:10,sort:[{create_time:desc},// 主排序字段{_id:asc}// 确保排序唯一性]}b. 获取第二页及以后使用第一页最后一条记录的排序值。GET/my_index/_search{query:{match_all:{}},size:10,sort:[{create_time:desc},{_id:asc}],search_after:[2023-10-27T08:00:00.000Z,// 上一页最后一条记录的 create_timeabc123// 上一页最后一条记录的 _id]}4. 基于PIT(Point In Time) 的search_after分页search_after的增强版解决了在分页过程中索引可能发生变化如数据删除、更新导致的结果不一致问题。工作原理先创建一个“时间点”PIT这个时间点会冻结索引的视图保证在整个分页过程中看到的数据是一致的。然后结合search_after进行分页。例子保证在长时间翻页过程中数据的一致性。a. 创建 PITPOST/my_index/_pit?keep_alive1m返回一个id。b. 使用 PIT 和 search_after 进行查询GET/_search{pit:{id:46ToAwMDaWR5BXV1aWQyKwZub2RlXzMAAAAAAAAAACoBYwADaWR4BXV1aWQxAgZub2RlXzEAAAAAAAAAAAEBYQADaWR5BXV1aWQyKgZub2RlXzIAAAAAAAAAAAwBYgACBXV1aWQyAAAFdXVpZDEAAQltYXRjaF9hbGw_gAAAAA,keep_alive:1m},sort:[{timestamp:asc},{_id:asc}],size:100,search_after:[1698390400000,o1W6_osB8-dyz-MuPqQ3]}方案总结与对比方案适用场景优点缺点from size浅分页用户界面的前几十或几百页数据。例如网站的商品列表、新闻列表的前几页。1. 使用简单易于理解。 2. 支持随机跳页。1.深度分页性能极差。from值越大协调节点需要排序和汇总的结果越多消耗的内存和CPU也越多。 2. 默认index.max_result_window为 10000限制了其使用深度。scroll离线处理需要从索引中导出全部数据或批量处理所有符合条件的数据。例如数据迁移、日志分析、全量备份。1. 适合处理海量数据。 2. 高效因为后续请求不需要重复查询和排序。1.不适用于实时用户请求。 2. 搜索上下文保持需要开销占用资源。 3. 数据非实时是基于第一次查询时的快照。search_after深度分页的实时查询用户需要有序地、实时地翻阅大量数据。例如微博/新闻流的无限下拉、后台系统的审计日志查看。1.解决深度分页性能问题性能恒定。 2. 查询结果是实时的。 3. 不占用大量资源。1.不支持随机跳页只能一页一页顺序翻。 2. 需要至少一个唯一性排序字段通常加上_id。 3. 页面结构相对固定依赖于上一页的结果。PIT search_after对一致性要求高的深度分页在分页过程中不允许因数据变更导致结果重复或丢失。例如金融交易记录的翻页查询、严格的数据核对任务。1. 具备search_after的所有优点。 2.提供跨页的一致性视图避免因数据更新导致的分页混乱。1. 相比纯search_after稍复杂需要管理 PIT ID。 2.同样不支持随机跳页。 3. PIT 会占用一定的服务器资源。核心建议Top N 或浅层分页毫不犹豫地使用from size。数据导出或离线处理使用scroll。深度分页最常见使用search_after。这是现代 ES 应用中处理深度分页的标准答案。深度分页 强一致性要求使用PIT search_after。记住一个黄金法则永远不要在生产环境中使用from size来获取超过 10000 条以后的数据。资料获取大家点赞、收藏、关注、评论啦~精彩专栏推荐订阅在下方专栏长路-文章目录汇总算法、后端Java、前端、运维技术导航博主所有博客导航索引汇总开源项目Studio-Vue—校园工作室管理系统(含前后台SpringBootVue)博主个人独立项目包含详细部署上线视频已开源学习与生活-专栏可以了解博主的学习历程算法专栏算法收录更多博客与资料可查看获取联系方式文末获取开发资源及更多资源博客获取