在业务开发中使用ElasticSearch的指导手册

本篇博文分享自己在实践中使用ElasticSearch进行业务开发的一些心得。只讨论应用程序和ElasticSearch交互，至于其他组件，例如Kafak和ElasticSearch的集成则不在本篇博文讨论范围之内。

在业务中使用ElasticSearch中时建议将下列事项作为检查清单，根据实际情况来增减，确保自己在开发过程中思考了下列事项并结合实际情况来完成最终的设计、开发。

该业务为什么需要ElasticSearch? / 该业务需要ElasticSearch的核心功能是哪些？

在使用ES时，我们要问自己的第一个问题是，我为什么拿ES来解决当前业务中的问题？对于该业务的技术问题，团队内的现有技术栈和ES相比有哪些不足？一定要有充足的理由。

正确示例

1. 业务需要一个推荐系统，可以利用ES的分词能力来做这件事
2. 对于海量数据的模糊查询，已经对数据库索引和代码进行了优化，查询起来还是很慢。所以将数据库的数据同步至ES中，利用ES强大的缓存能力来帮助我们提高模糊查询的性能。

错误示例

1. 我看ES好像能干这事，而且网上很多解决方案也是这个。那我们就用。（没有结合当前情况进行思考，直接进行照搬的）

在使用ElasticSearch一些高级功能时，确保该功能是否需要付费的许可证？

该功能是否收费，具体可以在官方订阅说明中找到

如何快速验证分词是否能够满足业务需求？

大部分使用ES场景还是和其分词功能有关。

一个常见的错误开发流程是，上来就开干，直接写代码，周边代码撸完了，结果到最后发现分词有各种各样的问题。所以对于这种关键的问题，我们一开始就要对其验证，只有核心分词没问题且能满足我们的业务需求了，再写代码也不迟。

可以根据业务需求找到合适的内置分词器。找到分词器之后，用一些示例文本在Kibana > Dev Tool中测一下分词效果，见如何测试分词器，例如，我想测一下标准分词器对我们业务的一些文本的分词结果

POST _analyze
{
  "analyzer": "standard",
  "text": "The 2 QUICK Brown-Foxes jumped over the lazy dog's bone."
}

这种方式你能在几个小时之内快速知道哪些分词器能满足当前业务场景并及时反馈给产品团队进行沟通，在需求前期就能快速辨别该需求能不能做，而不是拍着胸脯说，没问题，然后撸了一堆代码，发现业务核心根本没办法实现，自己给自己挖了一个坑。

分词不满足，如何自定义分词？

有很多场景使用内置的分词器可能不满足，例如：使用ES完全达到和数据库like的效果。

自定义分词只需要看官方文档下面几个内容

1. 创建自定义分词器
2. 为某个字段指定分词器

创建完自定义分词器切记不要忘了上面一条，要先测试过确保没问题，才可进行下一步

业务数据的字段类型映射是否合理？

确定核心分词字段没问题了之后，接下来就要为整个index建立完整的mapping字段。关于字段类型可直接参考官方文档field data types部分，根据实际业务数据类型选择合适的字段类型。同时结合官方文档中的优化索引速度和优化搜索速度中有关index的建议，设计出合理，高效的结构。

实践中如何使用IndexTemplate，Index Alias？

1. 建议使用IndexTemplate并按照业务的数据特点对index进行分区。例如，我们需要把每年的订单数据导入到ES中以便快速检索，我们只提供近5年的数据搜索。我们会将index按照年分区，可根据查询区间直接搜索相关的年的index而不是所有index；删除的时候直接将该index删除即可。
2. 无论现在用不用Index Alias，我都建议为index设置alias。

业务数据是否可修改？

如果你的业务数据不涉及到更新，写进去就是之后就是查询，类日志数据，强烈建议使用datastream

业务数据需要保留多长时间？/ 如何配置生命周期管理？

index结构创建好了之后，一个关键的问题是该数据需要在ES中保留多长时间，因为机器资源是有限的，不可能不加任何限制的存储数据。

这个问题需要产品团队给出明确的答案。有了明确的期限之后，我们要根据实际情况为index设置生命周期策略。虽然这些活编程式也能干，但是ES既然提供了这个工具，干嘛不用它的呢。有关生命周期的各配置细节解释和具体配置可参考这篇博文

业务数据的增长情况估算？容量估算？

在业务上线之前，需要预估该业务上线后ES中数据容量情况，以便确定当前ES的机器资源是否满足需要，如果不满足应该扩充多少？预估容量也有助于避免由于数据量突增导致ES压力增大，影响到其他使用到ES的业务。

如何正确的计算ES所需要的机器资源呢？我一开始的想法是，计算每条document在ES中的存储大小，然后根据产品给出的预估量，简单计算所需总存储大小是多少。后来发现，社区问过类似的问题，回答是这样没办法做也不建议这样做。因为ES存储会做各种优化、压缩。不可能通过这种方式计算出来，即使算出来也是不准确的。

唯一的可行方法是，预估上线之后数据量有多大，然后按照这个数据量灌到ES里去，观察ES的压力情况，根据实际情况做调整

最后

上述所有项都是在业务开发中值得注意的地方。我并没有把每一步的解决方案都详细的写出来，是因为解决方案里链接了大量的官方文档，跟着官方做就可以实现。

真正写代码往往是上述大部分问题都已经确定了之后才开始。

如有更好的开发实践，欢迎留言讨论