0%

Elasticsearch关联关系数据建模(一)应用层联接 Elasticsearch关联关系数据建模(二)嵌套对象

parent-child关系,类似于nested模型,区别在于,nested objects文档中,所有对象都在同一个文档中,而parent-child关系文档中,父对象和子
对象都是完全独立的文档。

使用场景:子文档数量较多,并且子文档创建和修改的频率高时。

与nested objects相比,parent-child关系的优势有:

更新父文档时,不会重新索引子文档。
创建,修改或删除子文档时,不会影响父文档或其他子文档。
子文档可以作为搜索结果独立返回。

对父-子文档关系有个限制条件:父文档和其所有子文档,都必须要存储在同一个分片中。

Parent-Child关系文档映射

建立父-子文档映射关系时只需要指定某一个文档 type 是另一个文档 type 的父亲。 该关系可以在如下两个时间点设置:1)创建索引时;2)在子文档 type 创建之前更新父文档的 mapping。

举例说明,有一个公司在多个城市有分公司,并且每一个分公司下面都有很多员工。

在创建员工 employee 文档 type 时,指定分公司 branch 的文档 type 为其父亲。

1
2
3
4
5
6
7
8
9
10
11
PUT /company
{
"mappings": {
"branch": {},
"employee": {
"_parent": {
"type": "branch"
}
}
}
}

employee 文档 是 branch 文档的子文档。

构建Parent-Child文档索引

为父文档创建索引与为普通文档创建索引没有区别。父文档并不需要知道它有哪些子文档。

1
2
3
4
5
6
7
POST /company/branch/_bulk
{ "index": { "_id": "london" }}
{ "name": "London Westminster", "city": "London", "country": "UK" }
{ "index": { "_id": "liverpool" }}
{ "name": "Liverpool Central", "city": "Liverpool", "country": "UK" }
{ "index": { "_id": "paris" }}
{ "name": "Champs Élysées", "city": "Paris", "country": "France" }

创建子文档时,用户必须要通过 parent 参数来指定该子文档的父文档 ID:

1
2
3
4
5
6
PUT /company/employee/1?parent=london 
{
"name": "Alice Smith",
"dob": "1970-10-24",
"hobby": "hiking"
}

当前 employee 文档的父文档 ID 是 london 。如此保证了父文档和子文档都在同一个分片上。

分片路由的计算公式如下:

shard = hash(routing) % number_of_primary_shards

如果指定了父文档的 ID,那么就会使用父文档的 ID 进行路由,而不会使用当前文档 _id。也就是说,如果父文档和子文档都使用相同的值进行路由,那么父文档和子文档都会确定分布在同一个分片上。

在执行单文档的请求时需要指定父文档的 ID,单文档请求包括:通过 GET 请求获取一个子文档;创建、更新或删除一个子文档。而执行搜索请求时是不需要指定父文档的ID,这是因为搜索请求是向一个索引中的所有分片发起请求,而单文档的操作是只会向存储该文档的分片发送请求。因此,如果操作单个子文档时不指定父文档的 ID,那么很有可能会把请求发送到错误的分片上。

1
2
3
4
5
6
7
POST /company/employee/_bulk
{ "index": { "_id": 2, "parent": "london" }}
{ "name": "Mark Thomas", "dob": "1982-05-16", "hobby": "diving" }
{ "index": { "_id": 3, "parent": "liverpool" }}
{ "name": "Barry Smith", "dob": "1979-04-01", "hobby": "hiking" }
{ "index": { "_id": 4, "parent": "paris" }}
{ "name": "Adrien Grand", "dob": "1987-05-11", "hobby": "horses" }

如果你想要改变一个子文档的 parent 值,仅通过更新这个子文档是不够的,因为新的父文档有可能在另外一个分片上。因此,你必须要先把子文档删除,然后再重新索引这个子文档。

Elasticsearch关联关系数据建模(一)应用层联接 Elasticsearch关联关系数据建模(三)父子关系文档

案例:一篇博客对应多个评论。

字段类型由object改为nested即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PUT /my_index
{
"mappings": {
"blogpost": {
"properties": {
"comments": {
"type": "nested",
"properties": {
"name": { "type": "string" },
"comment": { "type": "string" },
"age": { "type": "short" },
"stars": { "type": "short" },
"date": { "type": "date" }
}
}
}
}
}
}

嵌套对象的查询

嵌套对象被索引在独立隐藏的文档中,所以必须使用nested查询去获取数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
GET /my_index/blogpost/_search
{
"query": {
"bool": {
"must": [
{
"match": {
"title": "eggs"
}
},
{
"nested": {
"path": "comments",
"query": {
"bool": {
"must": [
{
"match": {
"comments.name": "john"
}
},
{
"match": {
"comments.age": 28
}
}
]
}
}
}
}
]
}
}
}

nested子句作用于嵌套字段comments。comments.name和comments.age子句操作在同一个嵌套文档中。

nested查询还可以多层嵌套。

默认情况下,根文档的分数是这些嵌套文档分数的平均值。可以通过设置 score_mode 参数来控制这个得分策略,相关策略有 avg (平均值), max (最大值), sum (加和) 和 none (直接返回 1.0 常数值分数)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
GET /my_index/blogpost/_search
{
"query": {
"bool": {
"must": [
{
"match": {
"title": "eggs"
}
},
{
"nested": {
"path": "comments",
"score_mode": "max",
"query": {
"bool": {
"must": [
{
"match": {
"comments.name": "john"
}
},
{
"match": {
"comments.age": 28
}
}
]
}
}
}
}
]
}
}
}

如果nested查询放在filter子句中,则score_mode参数不再生效,因为filter不是打分查询。

使用嵌套字段排序

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
PUT /my_index/blogpost/2
{
"title": "Investment secrets",
"body": "What they don't tell you ...",
"tags": [ "shares", "equities" ],
"comments": [
{
"name": "Mary Brown",
"comment": "Lies, lies, lies",
"age": 42,
"stars": 1,
"date": "2014-10-18"
},
{
"name": "John Smith",
"comment": "You're making it up!",
"age": 28,
"stars": 2,
"date": "2014-10-16"
}
]
}

查询某个时间范围内,有评论的文章,并按stars升序排序。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
GET /_search
{
"query": {
"nested": {
"path": "comments",
"filter": {
"range": {
"comments.date": {
"gte": "2014-10-01",
"lt": "2014-11-01"
}
}
}
}
},
"sort": {
"comments.stars": {
"order": "asc",
"mode": "min",
"nested_path": "comments",
"nested_filter": {
"range": {
"comments.date": {
"gte": "2014-10-01",
"lt": "2014-11-01"
}
}
}
}
}
}

sort排序子句中的nested_path和nested_filter的查询条件和上面的path、filter重复。原因在于,排序发生在查询执行之后。我们是按某一时间范围
的stars数排序,而不是按所有时间的stars排序。比如blog1的在10月stars:1, blog2在10月stars:2,但blog1的所有stars:20,blog2的所有stars:10。
他们最后的结果是不一样的。

嵌套聚合

https://www.elastic.co/guide/cn/elasticsearch/guide/current/nested-aggregation.html

从关系型数据库迁移数据到Elasticsearch时,总要处理很多关联数据,如何进行数据建模,下面给出了四种方案可供大家参考。

其中最简单的一种就是数据冗余扁平化,这个不做过多讲解。

Elasticsearch关联关系数据建模(二)嵌套对象 Elasticsearch关联关系数据建模(三)父子关系文档

应用层联接有点类型关系型数据库的子查询。第一次查询的结果作为第二次查询的条件。

1
2
3
4
5
6
7
8
9
10
11
12
13
PUT /my_index/user/1 
{
"name": "John Smith",
"email": "john@smith.com",
"dob": "1970/10/24"
}

PUT /my_index/blogpost/2
{
"title": "Relationships",
"body": "It's complicated...",
"user": 1
}

blogpost 通过用户的 id 链接到用户。

通过用户的 ID 1 可以很容易的找到博客帖子。

1
2
3
4
5
6
7
8
9
10
GET /my_index/blogpost/_search
{
"query": {
"filtered": {
"filter": {
"term": { "user": 1 }
}
}
}
}

为了找到用户叫做 John 的博客帖子,我们需要运行两次查询。先查询名字包含 John 的所有用户的 id 集合,再像上面一样根据 id 查询 blogpost。

执行第一个查询得到的结果将填充到 terms 过滤器中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
GET /my_index/user/_search
{
"query": {
"match": {
"name": "John"
}
}
}

GET /my_index/blogpost/_search
{
"query": {
"filtered": {
"filter": {
"terms": { "user": [1, 3, 7] }
}
}
}
}

总结:应用层联接的主要优点是可以对数据进行标准化处理。缺点就是需要2次查询,有时间消耗。
如果说叫 John 的用户有很多,比如百万以上,那查询是非常没有效率的。
这种方法适合于 user 只有少量文档的情况,并且最好它们很少改变,这将允许应用程序对结果进行缓存,避免经常运行第一次查询。

eg. 搜索用户名称和博客标题,展示用户及其最相关的博客列表。

需要按用户名称进行分组,根据score进行排序选TOPN。

https://www.elastic.co/guide/cn/elasticsearch/guide/current/top-hits.html

eg. 文件目录的搜索,可以参考如下链接。

https://www.elastic.co/guide/cn/elasticsearch/guide/current/denormalization-concurrency.html

eg. 并发问题

https://www.elastic.co/guide/cn/elasticsearch/guide/current/concurrency-solutions.html