文章插图
当然也可以直接使用临时索引作为交互索引，避免一次迁移动作，这种动态的识别需要在服务中嵌入，在整个
reindex过程中要避免手动干预 ， 个人还是更相信程序的安全性和准确性；四、刷新策略在向ES索引中写数据时，存在三种不同的数据刷新机制，查看
6.8版本的设置中，参数refresh_interval设置的是1s时间 ， 即执行写入动作1秒后数据才可以被搜索到，避免频繁写入消耗过多的资源；NONE：默认的刷新策略，请求提交之后不会等待数据刷新 ， 降低资源消耗但数据实时性低；
IMMEDIATE：请求提交后立即刷新索引 ， 数据的实时性很高但是资源消耗过大，API文档中建议测试使用；
WAIT_UNTIL：请求提交之后会等待索引刷新完成才会结束 ， 相对来说是一种比较平衡的策略；
刷新机制对于索引的数据维护来说，主要在增删改的动作中，对即时查询有直接的影响，至于如何选择还是要结合具体的场景 ， 尤其与同步方案关联密切 ， 也可以在索引交互中动态维护策略，来应对不时之需；
五、深度分页对于数据查询来说，几乎都存在分页的需求，在常见的应用中 ， 不断下拉的功能都是存在最大的极限值；
ES中常用From/Size进行分页查询，但是存在一个限制，在索引的设置中存在
max_result_window分页深度的限制，6.8版本默认值是10000条，即10000之后的数据无法使用From/Size翻页；先从实际应用场景来分析，大多数的翻页需求最多也就前10页左右，所以从这个角度考虑，ES的翻页限制在合理区间，在实践中也存在对部分索引调高的情况，暂未出现明显问题；
再从技术角度来思考一下，如果翻页的参数过大意味着更多的数据过滤，那计算资源的占用也会升高，ES引擎的强大在于搜索能力，检索出符合要求的数据即可；
文章插图
不管是ES还是其它类似的分布式存储组件，甚至是MySQL分库分表模式 ， 其本质都是数据分布在不同服务节点的不同数据片上；常规的执行原理都是给请求分配一个主节点 ， 协调各个节点执行相同的查询 ， 并完成结果汇总和响应，深度分页时计算资源的占用自然非常高；
如果一定需要深度分页，在
6.8的版本中提供了Scroll或Search-After两种其他的方式，用法参考相关文档即可 。六、参考源码
编程文档：https://gitee.com/cicadasmile/butte-java-note应用仓库：https://gitee.com/cicadasmile/butte-flyer-parent
推荐阅读
- 使用 StringUtils.split 的坑
- 京东云开发者｜ElasticSearch降本增效常见的方法
- 探望坐月子的礼物排行榜，送宝宝和产妇这些最有心意
- 记录在linux上单机elasticsearch8和kibana8
- 分享几个关于Camera的坑
- Elasticsearch rest-high-level-client 基本操作
- Redis Cluster 原理说的头头是道，这些配置不懂就是纸上谈兵
- .NET性能系列文章一：.NET7的性能改进
- Hyperf使用ElasticSearch记录
- Vue3.x+element-plus+ts踩坑笔记