ElasticSearch这些坑记得避开原创
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两种其他的方式，用法参考相关文档即可。
