Index 用不好，麻烦事不会少；
一、治理形式
ElasticSearch 作为最罕用的搜索引擎组件，在零碎架构中施展极其重要的能力，能够极大的晋升数据的加载和检索效率；但不可否认的是，在长期的利用实际中，也发现很多不好解决的流程和场景；
从直观感觉上说，业务中对索引的应用次要波及如图的几个流程，其外围也就是索引的构造保护与数据的流动治理两个模块；
如果数据结构比较简单且体量小，那么应用起来可能很棘手；如果数据主体简单且会动静扩大，并且体量偏大，那么就很容易踩中一些比拟坑的点；
比方：索引中字段一旦有误，调整的流程十分复杂；数据流向索引中的形式，须要依据场景灵便抉择；以及数据查问时的深度分页问题；上面将围绕这些问题来总结下应答策略；
顺带补充一句，其实很多组件在利用的时候都有不太合乎预期的中央，所以在集成时能够思考编写自定义的管理程序，来解决应用时可能存在的问题；
二、构造保护
对于 ES 索引的构造保护，数据主体如果绝对简略的话，能够思考手动治理，但实际上应用索引时，通常主体构造都比较复杂，字段个数超过三五十都很常见，所以基于流程化的治理很有必要；
构造映射：将须要构建索引的主体构造，在字段库中对立保护，值得注意的是字段名称和类型，字段能够与关系型数据库的查问统一，然而不同组件类型的形容不一样，尤其对 ES 来说，如果字段类型不合理，会影响搜寻的应用；
索引构造：在理论的业务场景中，字段的信息是会动态变化的，这就会给索引构造的保护带来很多麻烦，字段的增减都好治理，然而如果波及类型的变动，则存在索引重建的过程，会导致数据屡次从新调度，这也是危险较高的操作；
程序保护：这种构造保护的机制，其外围目标是把整个流程进行程序化治理，防止人工进行干涉，以此来确保索引构造的稳固扩大；
不得不提的一个经验教训，已经在治理业务日志的索引构造时，呈现过一次误删动作，好在能够从新构建和数据备份复原，然而仍旧给心里留下了几厘米的暗影，尔后也将保护流程彻底程序化，防止失误动作产生；
三、数据调度
1、同步计划
数据的调度治理，其本质就是将数据从一个容器向另一个容器搬运或者拷贝，其外围操作就是读和写两个动作，然而为了让流程具备容错和稳定性，通常须要做策略和计划的设计；
同步双写：对数据的实时性要求极高，通常在一个事务中实现数据的双写动作，保证数据层面的强一致性；
异步解耦：在实现数据库的写动作之后，基于 MQ 音讯解耦索引的写入，流程存在轻微的提早，如果生产失败会导致数据缺失；
定时工作：通过任务调度的形式，以指定的工夫周期执行新增数据的同步机制，存在显著的时效问题；
组件同步：采纳适合的同步组件，比方官网提供的组件或者一些第三方开源的组件，在原理上与工作同步相似；
数据同步的选型计划有多种，如何抉择齐全看具体的场景，在过往的应用过程中，对于外围业务会采纳同步双写，对于外部的流动类业务会采纳异步的形式，对于业务日志会采纳任务调度，对于零碎的监控或执行日志则多是依赖同步组件；
2、中断和复原
无论采纳何种形式将数据同步到索引中，都不得不面对一个灵魂问题，如果流程忽然异常中断，复原后如何保障索引数据不失落？这个问题适应于很多简单的流程；
容错性是掂量一个简单流程的外围指标，比方在索引数据同步的过程，须要短暂性的暂停，或者流程被迫中断时，都应该具备复原后主动修复索引中数据缺失的能力；
ES 实际中一个十分经典的问题，批改索引的构造时须要进行索引重建，此时要将以后索引迁入长期索引中，在实现索引结构调整之后，须要从长期索引中迁回数据，在此过程中，能够对服务交互的索引名称动静调整；
当然也能够间接应用长期索引作为交互索引，防止一次迁徙动作，这种动静的辨认须要在服务中嵌入，在整个 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