如何优雅的为高版本Elasticsearch自动映射map

在项目中使用SpringBoot可以快速集成各种中间件，遵循依赖优于配置原则，我们只需要选择合适的SpringBoot版本就可以轻松集成中间件，并且可以快速上手；

但是由于Elasticsearch版本更新快等各方面原因，在目前的SpringBoot还只能支持到5.0版本以下的Elasticsearch；根据Github上Elasticsearch文档中给出的版本对应关系可以看得出来，目前SpringBoot版本1.4及以上版本最高适配的Elasticsearch版本为2.0.0~5.0.0；

Github地址：https://github.com/spring-projects/spring-data-elasticsearch/wiki/Spring-Data-Elasticsearch---Spring-Boot---version-matrix

我们再来看一下Elasticsearch官网，https://www.elastic.co/cn/downloads/elasticsearch可以看到，目前Elasticsearch已经更新到7.3.0版本了；

那么，假如我们需要整合高版本的Elasticsearch到SpringBoot框架中，这时候我们就需要手动来指定索引的mapping结构(类似于数据库表结构)了；

在我们使用Spring Data创建Elasticsearch(后面简称ES)的mappings结构时，我们只需要在实体类上使用@Document注解标记当前实体需要创建的索引名称及索引类型名称即可，当我们将实体类交由ES的API时，API会自动根据实体类属性类型分配响应的结构类型；同时，我们还可以使用@Field注解在对应的属性上描述属性的特性，其他的交由API处理即可生成不错的mappings结构；

但是对于目前而言，ES版本高于5.0.0.*的，Spring并未对此做过多的集成，此时的mappings结构的描述只能交由我们自己来控制；

假设有一个实体类GwAdvice.java，其结构如下：

这时候，我们需要需要将此实体类保存到ES中，我们就需要手动创建mappings结构，创建索引代码如下：

上述代码中的结构和上述实体类结构是对应的关系，并且当有新的字段需要添加到ES中时，我们就需要在这里改动mappings代码了；这样的代码很难进行维护，特别是当表数据特别多时，编写代码工作量会特别大，并且每一个字段都需要都需要而根据字段的实际情况进行分配结构；我曾写过一千多行的mappings结构映射代码；

更头疼的时，每一个实体类都需要编写一套属于当前实体类的mappings结构代码，完全没有可扩展性而言；

另外还有一个问题就是手动创建mappings结构不能很好的描述实体类结构，比如实体类中包含有另外一个实体类，再或者，实体类里面包含一个集合对象结构；这种情况下手动创建mappings着实让人头疼；

那么有什么好的办法可以解决这个难题吗？

观察上述代码，我们会发现在代码中有很多相似的地方是可以进行抽取的；上述代码中为每一个字段都分类了一个类型，有的类型还做了一些其他的处理比如分词等操作；我们可以参考SpringBoot集成低版本ES那样在实体类上做手脚来完成实体类在ES中存储的mappings关系的映射；

我们只需要通过某种方式对实体类中的每个字段进行描述应该怎样创建mappings即可；那么，这时候用注解就再合适不过了；

首先我们先来定义一个注解FieldInfo，其代码如下所示：

上述代码中，我们指定了一个type，一个participle，还指定了一个ignoreAbove(可略)；type用来描述当前字段的类型，participle可以用来指定分词器的类型，ignoreAbove描述字段的范围；

这样，我们只需要在实体类上使用注解就可以描述每个字段的结构了；我们再创建一个对象用来存储每一个字段的结构关系

上述实体类，用来存储每一个字段及其这个字段的生成mappings方式；看到这里，相信很多小伙伴已经猜到了下一步是需要将每一个字段放到这个实体类中存储，然后使用一个集合来存储每一个实体类；

我们定义一个ElasticSearchUtils类，代码如下：

上述代码中，根据传入的Class字节码对象获取当前对象的所有属性，遍历属性，判断属性上是否包含自定义注解@FieldInfo，如果有包含则说明是需要创建到mappings结构中的字段；

判断当前字段上的注解中类型字段是否是object，如果不是则将字段的结构关系保存到FieldMapping后存储到一个大的List集合中；如果是object则进一步是否是基本数据类型及List等数据类型，通过递归将所有涉及到的实体类字段都存储到集合中；为下一步创建mappings做准备；

当我们拿到了List fieldMappingList集合后，我们通过遍历获取每一个字段，对string类型进行分词规则的处理，对时间类型进行不同的处理(数据库中字段的datetime和timestamp类型在建立mappings是需要分开处理，否则创建mappings时会报错)；在这个遍历的过程中，我们就可以生成和上面那种手写mappings达到一样的效果了；将重复的工作进行抽取出来；从而实现mappings的自动映射；

在这里我这边演示的ES版本为6.3.2，生成的索引部分数据如下：

上述结构在实体类中的的描述是一个帖子对应帖子评论的关系的一个简图，去除了很多的字段使结构更清晰；一个帖子对应多个帖子评论，使用自定义注解就很轻松的实现了这种一对多的关系了；

这样，所有的实体类都可以使用这一组代码来完成mappings的创建，而不再需要为每一个实体类建立一个自己的mappings生成代码了，从而极大的降低了开发成本，并且使程序结构更加清晰；

上述代码中需要留意的就是时间类型，在Elasticsearch中的时间默认采用的是"strict_date_optional_time||epoch_millis"，也就是默认采用的是timestamp时间类型；

通常我们在数据库建表时，对于时间字段会采用datetime类型，但是有很多的朋友会更偏向于timestamp这种时间类型，因为timestamp类型可以根据时区自动转换时间，详情可自行百度；

但是这样的话就会造成一个新的问题，那就是时间存储到es后，我们通过head插件或者kibana插件来查看数据时，数据的时间会比实际时间少8个小时；

而造成这个问题的关键就在于我们将数据存储到Elasticsearch中其实就是将一串JSON数据存储到ES中，而JSON没有日期数据类型。

我们来看一下Elasticsearch官网中对存储时间类型的简介

地址：https://www.elastic.co/guide/en/elasticsearch/reference/current/date.html

以及：https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html

在实际代码演示中，我发现当数据库中的时间类型是timestamp类型时，是不能使用

这种形式来描述mappings结构，在创建索引时会抛出异常；对于数据库中是timestamp类型时间字段，暂时只能使用

这种方式来解决；还不知道在代码层面对date类型做数据转换能不能解决这个问题，在后面在尝试；

我们只需留意在时间类型上需要额外处理即可；

在这里，创建Elasticsearch自动mappings的代码演示就到这里了，希望对大家能有所帮助；

2019年8月12日 23:22:49