[11]elasticsearch源码深入分析——文档(document)的落地

本篇为elasticsearch源码分析系列文章的第十一篇,本篇开始进入索引有关操作的讲解。以后的若干篇我们会连续讨论文档的创建,检索,更新,删除,版本控制等一系列内容。

文档

ElasticSearch存储系统中的实体叫做文档,document。如果用关系型数据库来类比的话,一个文档相当于数据库中的一行记录。ElasticSearch中的文档有个特点,相同字段必须是相同的类型,也就是说所有包含title字段的文档,title字段类型都必须一样,要么同为string,要么同为int。

文档由多个字段组成,每个字段的类型可以是,文本,数值,日期,还可以是字符串数组这种复杂的类型。字段类型在ElasticSearch中非常重要,它涉及到各种分析和排序操作如何被执行的信息。Elastic官方推荐我们使用Mapping映射来干预字段的类型。与关系型数据库不同,ElasticSearch不需要有固定的结构,每个文档可以有不同的字段,此外,在程序开发期间,不必确定有哪些字段。

文档的类型

在ElasticSearch中,文档类型可以让程序员轻松的区分单个索引中的不同对象。每个文档可以有不同的结构,但在实际生产环境中我们还是推荐将文档中的类型详细化,这样对以后的开发会有很大的帮助。

文档类型的映射

上面提到的映射,指的是ElasticSearch在映射中存储有关字段的信息,这种类型信息就是映射Mapping。每个文档类型都有自己的映射,即使在初始化时没有提前定义。在涉及到全文搜索和倒排索引的内容中,会有对文档分析的过程,在这个过程中每个字段都必须根据不同类型作相应的分析。举例来说,对数值字段和文本字段的分析肯定是不同的分析过程,数字的分析就不应该是按照字母的排序来分析。

使用ElasticSearch的ResultAPI来新建文档

在ElasticSearch中,所有文档都是数据,所有数据都有定义好的索引和类型。现在我们通过一个比较常见的例子来建立文档:

创建文档

上面操作的意思是,我们建立了一个名为article的索引和名为computer的类型,文档的标示符为1

如果一切正常,那么这种使用RESTfulAPI的创建方式会返回一个JSON响应,与如下输出类似:

文档创建成功

前面的相应包含了操作状态的信息,显示了创建的文档放在什么地方,还包含了文档的唯一标示符_id和当前版本_version的信息。每次ElasticSearch的更新版本都会自动递增。

而且ElasticSearch在创建文档时,如果没指定文档标示符,那么这个文档的标示符会被自动创建。

自动创建文档标示符

这都是怎么做到的呢?我们会在下一节从源码的角度解释。

ElasticSearch源码如何新建文档

在以前文章中强调的Node实例化的过程中,加载了ActionModule这个模块,这个模块是接收客户端发送的RESTful请求的的模块,ActionModule的加载如下:

ActionModule actionModule = new ActionModule(false, settings, clusterModule.getIndexNameExpressionResolver(), settingsModule.getIndexScopedSettings(), settingsModule.getClusterSettings(), settingsModule.getSettingsFilter(), threadPool, pluginsService.filterPlugins(ActionPlugin.class), client, circuitBreakerService, usageService);

在加载完了ActionModule后,会通过ActionModule的方法initRestHandlers()来初始化HTTP处理程序,这个handler就能解析客户端通过http协议发送到ElasticSearch集群中的RESTful请求。

加载RestIndexActionindex处理器,

registerHandler.accept(new RestIndexAction(settings, restController))

如下图所示,注册不同的REST处理程序路径,以用来不同的匹配请求。

不同的索引请求

可以看到控制器匹配路径中,有index,type和id,如果不指定id,则id会被自动创建,而且不指定id必须用POST方法来发送请求。

因为ElasticSearch中的Controller底层都是Netty实现的。所以在端口绑定后,Netty4HttpChannel会去监听端口收到的http请求。在ElasticSearch的Controller接收到Netty4HttpChannel转发的请求后,会调用RestIndexAction中的方法prepareRequest()。该方法返回RestChannelConsumer类型的实例,该实例是虚拟类BaseRestHandler中的Functional接口。阅读这个接口的定义的方法,可以知道ElasticSearch中的REST请求是通过准备一个表示通道的请求执行的通道消费者(a channel consumer)来处理的。

接收到请求后开始构建IndexRequest,这个实例作用是将JSON类型的文档转换为一个特定的和可搜索的索引。

IndexRequest回首先取得RestRequest中的三个构造实例必须的参数:

  • index:文档的索引
  • type:文档的类型
  • id:文档指定的标识

然后在依次取得一些附加参数:

  • routing:控制分片的路由请求。使用这个值来哈希的分片,而不是id。
  • parent:设置document的父id。
  • pipeline:在执行索引document前,设置摄取管道(ingest pipeline)
  • source:设置document索引的字节形式。
  • timeout:超时时间
  • refresh:解析刷新策略
  • version_type:设置版本类型
  • op_type:字符串,用来表示是索引数据还是新建数据

参数详情如下图:

image.png

这参数都是NodeClient在索引文档时候需要用到的数据,NodeClient在Node初始化时候就加载完成,他是用来在本地节点上执行操作的模拟客户端。

方法prepareRequest最后返回channel -> client.index(indexRequest, new RestStatusToXContentListener<>(channel, r -> r.getLocation(indexRequest.routing()))),因为该方法需要返回RestChannelConsumer类型的返回值,所以改写成jdk7版本易于理解的代码版本如下图所示:

返回代码

该段代码中最重要的就是NodeClient的index()方法,此方法的关键是新建了一个Task,这个Task包含了id,type,action,description,parentTask,startTime等信息。

该task在老版本会被TransportIndexAction处理,但是6.0版本后TransportBulkAction已经取代了TransportIndexAction。task会被当做参数送入TransportBulkAction的doExecute方法中,另外两个参数是BulkRequest和ActionListener

void doExecute(Task task, BulkRequest bulkRequest, ActionListener<BulkResponse> listener)

BulkRequest中包含了该文档存储的信息,而ActionListener则用来监听action的响应或失败,用以做回调操作。

doExecute方法主要做了以下操作:

  • 收集请求中的所有索引
  • 过滤掉不存在的索引,同时建立一个我们无法创建的索引图。判断不存在的索引和无法创建的索引主要是看索引是否有别名
  • 如果有遗漏的索引,则创建缺少的所有索引。注意在所有的创建完成后开始批量处理数据

然后执行TransportBulkAction类的executeBulk方法,完成数据的落地。

推荐阅读更多精彩内容