概述
Elasticsearch索引字段中定义了一些特殊数据类型,用于反映某些特殊的数据关系或数据表示方法。由于这些数据类型都与一组DSL查询和聚集查询相关联,所以本书在第2章2.3节中并没有介绍它们,而是集中在本章统一介绍。这些特殊数据类型主要包括join类型、nested类型和地理坐标,本章将在8.1~8.3节中分别介绍它们。
除了DSL和聚集查询以外,Elasticsearch在Basic授权中还提供了一种基于SQL语法的查询语言,这种查询语言可以以类似SQL语言的形式执行文档检索。由于这种SQL语言在Kibana画布功能中需要使用,所以本章在最后一小节会对它做简要介绍。
8.1 父子关系
Elasticsearch中的父子关系是单个索引内部文档与文档之间的一种关系,父文档与子文档同属一个索引并通过父文档_id建立联系,类似于关系型数据库中单表内部行与行之间的自关联。
8.1.1 join类型
在Elasticsearch中并没有外键的概念,文档之间的父子关系通过给索引定义join类型字段实现。例如创建一个员工索引employees,定义一个join类型的management字段用于确定员工之间的管理与被管理关系:示例8-1 创建join 类型字段
PUT employees
{
"mappings":{
"properties":{
"management":{
"type":"join",
"relations":{
"manager":"member"
}
}
}
}
}
在示例8-1中,management字段的数据类型被定义为join,同时在该字段的relations参数中定义父子关系为manager与member,其中manager为父而member为子,它们的名称可由用户自定义。文档在父子关系中的地位,是在添加文档时通过join类型字段指定的。还是以employees索引为例,在向employees索引中添加父文档时,应该将management字段设置为manager;而添加子文档时则应该设置为member。具体如下:8-2 父子关系添加文档
PUT /employees/_doc/1
{
"name":"tom",
"management":{
"name":"manager"
}
}
PUT /employees/_doc/2?routing=1
{
"name":"smith",
"management":{
"name":"member",
"parent":1
}
}
PUT /employees/_doc/3?routing=1
{
"name":"john",
"management":{
"name":"member",
"parent":1
}
}
在示例8-2中,编号为1的文档其management字段通过name参数设置为manager,即在索引定义父子关系中处于父文档的地位;而编号为2和3的文档其management字段则通过name参数设置为member,并通过parent参数指定了它的父文档为编号1的文档。在使用父子关系时,要求父子文档必须要映射到同一分片中,所以在添加子文档时routing参数是必须要设置的。显然父子文档在同一分片可以提升在检索时的性能,可在父子关系中使用的查询方法有has_child、has_parent和parent_id查询,还有parent和children两种聚集。
8.1.2 has_child查询
has_child查询是根据子文档检索父文档的一种方法,它先根据查询条件将满足条件的子文档检索出来,在最终的结果中会返回具有这些子文档的父文档。例如,如果想检索smith的经理是谁,可以按示例8-3请求:
在示例8-3中,has_child查询的type参数需要设置为父子关系中子文档的名称member,这样has_child查询父子关系时就限定在这种类型中检索;query参数则设置了查询子文档的条件,即名称为smith。最终结果会根据smith所在文档,通过member对应的父子关系检索它的父文档。
8.1.3 has_parent查询
has_parent查询与has_child查询正好相反,是通过父文档检索子文档的一种方法。在执行流程上,has_parent查询先将满足查询条件的父文档检索出来,但在最终返回的结果中展示的是具有这些父文档的子文档。例如,如果想查看tom的所有下属,可以按示例8-4请求:
has_parent查询在结构上与has_child查询基本相同,只是在指定父子关系时使用的参数是parent_type而不是type。
8.1.4 parent_id查询
parent_id查询与has_parent查询的作用相似,都是根据父文档检索子文档。不同的是,has_parent可以通过query参数设置不同的查询条件;而parent_id查询则只能通过父文档_id做检索。例如,查询_id为1的子文档:
以上三种查询都属于DSL,基本逻辑都是通过子文档检索父文档,或是通过父文档检索子文档。接下来再来看看针对父子关系的聚集查询。
8.1.5 children聚集
如果想通过父文档检索与其关联的所有子文档就可以使用children聚集。同样以employess索引为例,如果想要查看tom的所有下属就可以按示例8-6的方式检索:
在示例8-6中,query参数设置了父文档的查询条件,即名称字段name为tom的文档;而聚集查询members中则使用了children聚集将它的子文档检索出来,同时还使用了一个嵌套聚集member_name将子文档name字段的词项全部展示出来了。
8.1.6 parent聚集
parent聚集与children聚集正好相反,它是根据子文档查找父文档,parent聚集在Elasticsearch版本6.6以后才支持。例如通过name字段为smith的文档,查找该文档的父文档:
8.2 嵌套类型
本书第2.3节介绍的对象类型虽然可按JSON对象格式保存结构化的对象数据,但由于Lucene并不支持对象类型,所以Elasticsearch在存储这种类型的字段时会将它们平铺为单个属性。例如:
在示例8-8中的colleges文档,address字段会被平铺为address.country和address.city两个字段存储。这种平铺存储的方案在存储单个对象时没有什么问题,但如果在存储数组时会丢失单个对象内部字段的匹配关系。例如:
示例8-9中的colleges文档在实际存储时,会被拆解为“"address.country":["CN","US"]”和“"address.city":["BJ","NY"]”两个数组字段。这样一来,单个对象内部country字段和city字段之间的匹配关系就丢失了。换句话说,使用CN与NY作为共同条件检索文档时,上述文档也会被检索出来,这在逻辑上就出现了错误:
在示例8-10中使用了bool组合查询,要求country字段为CN而city字段为NY。这样的文档显然并不存在,但由于数组中的对象被平铺为两个独立的数组字段,文档1仍然会被检索出来。
8.2.1 nested类型
为了解决对象类型在数组中丢失内部字段之间匹配关系的问题,Elasticsearch提供了一种特殊的对象类型nested。这种类型会为数组中的每一个对象创建一个单独的文档,以保存对象的字段信息并使它们可检索。由于这类文档并不直接可见,而是藏匿在父文档之中,所以本书后续章节将称这类文档为隐式文档或嵌入文档。还是以colleges索引为例,将它的address字段设置为nested类型:
当字段被设置为nested类型后,再使用示例8-10中的bool组合查询就不能检索出来了。这是因为对nested类型字段的检索实际上是对隐式文档的检索,在检索时必须要将检索路由到隐式文档上,所以必须使用专门的检索方法。也就是说,现在即使将示例8-10中的查询条件设置为CN和BJ也不会检索出结果。nested类型字段可使用的检索方法包括DSL的nested查询,还有聚集查询中的nested和reverse_nested两种聚集。
8.2.2 nested查询
nested查询只能针对nested类型字段,需要通过path参数指定nested类型字段的路径,而在query参数中则包含了针对隐式文档的具体查询条件。例如:
在示例8-12中再次使用CN与NY共同作为查询条件,但由于使用nested类型后会将数组中的对象转换成隐式文档,所以在nested查询中将不会有文档返回了。读者可以自行将上面条件更换为CN和BJ,看是否有文档返回。
除了path和query两个参数以外,nested查询还包括score_mode和ignore_unmapped两个参数。前者用于指定嵌入对象如何影响相关度,可选值包括avg、max、min、sum和none,其中avg为默认值。ignore_unmapped用于控制在path参数指向出错时的行为,默认情况下为false,即在出错时会抛出异常。
8.2.3 nested聚集
nested聚集是一个单桶聚集,也是通过path参数指定nested字段的路径,包含在path指定路径中的隐式文档都将落入桶中。所以nested字段保存数组的长度就是单个文档落入桶中的文档数量,而整个文档落入桶中的数量就是所有文档nested字段数组长度的总和。有了nested聚集,就可以针对nested数组中的对象做各种聚集运算,例如:
在示例8-13中,nested_address是一个nested聚集的名称,它会将address字段的隐式文档归入一个桶中。而嵌套在nested_address聚集中的city_names聚集则会在这个桶中再做terms聚集运算,这样就将对象中city字段所有的词项枚举出来了。
8.2.4 reverse_nested聚集
reverse_nested聚集用于在隐式文档中对父文档做聚集,所以这种聚集必须作为nested聚集的嵌套聚集使用。例如:
在示例8-14中,city_names聚集也是将隐式文档中city字段的词项全部聚集出来。不同的是在这个聚集中还嵌套了一个名为avg_age_in_city的聚集,这个聚集就是一个reverse_nested聚集。它会在隐式文档中将city字段具有相同词项的文档归入一个桶中,而avg_age_in_city聚集嵌套的另外一个名为avg_age的聚集,它会把落入这个桶中文档的age字段的平均值计算出来。所以从总体上来看,这个聚集的作用就是将在同一城市中大学的平均校龄计算出来。
8.3 地理信息
8.4 使用SQL语言
Elasticsearch在Basic授权中支持以SQL语句的形式检索文档,SQL语句在执行时会被翻译为DSL执行。从语法的角度来看,Elasticsearch中的SQL语句与RDBMS中的SQL语句基本一致,所以对于有数据库编程基础的人来说大大降低了使用Elasticsearch的学习成本。除此之外,由于在Kibana新提供的画布功能中不支持使用Elasticsearch聚集查询功能,所以如果需要使用聚集查询时就必须要使用Elasticsearch SQL定义。
Elasticsearch提供了多种执行SQL语句的方法,可使用类似_search一样的REST接口执行也可以通过命令行执行。它甚至还提供了JDBC和ODBC驱动来执行SQL语句,但JDBC和ODBC属于Platinum(白金版)授权需要付费,所以本小节将只介绍_sql接口。
8.4.1 _sql接口
在早期版本中,Elasticsearch执行SQL的REST接口为_xpack/sql,但在版本7以后这个接口已经被废止而推荐使用_sql接口。例如:
在示例8-27中,_sql接口通过query参数接收SQL语句,而SQL语句也包含有select、from、where、order by等子句。_sql接口的URL请求参数format定义了返回结果格式,也可以通过在调用_sql接口时设置Accept请求报头设置返回结果格式。比如在示例8-27中定义了返回结果格式为txt,而将该请求报头Accept设置为text/plain也可以实现相似的效果。除了txt以外,_sql接口还支持csv、json、tsv、txt、yaml、cbor、smile格式。其中,cbor和smile是两种二进制格式,适用于通过程序解析的应用场景。有关这些格式的说明,请参考表8-5。