# 通过数据冗余实现用户与博客的关联
第二种建模方式：用冗余数据，采用文档数据模型，进行数据建模，实现用户和博客的关联
冗余数据，就是说，将可能会进行搜索的条件和要搜索的数据，放在一个 doc 中
# 构造用户与博客数据
DELETE website PUT /website/users/1 { "name": "小鱼儿", "email": "xiaoyuer@sina.com", "birthday": "1980-01-01" } PUT /website/blogs/1 { "title": "我的第一篇博客", "content": "这是我的第一篇博客，开通啦！！！", "userInfo": { "userId": 1, "username": "小鱼儿" } }Copied!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# join 查询
搜索数据，需求：还是前面的需求，查找小鱼儿的所有博客
GET /website/blogs/_search { "query": { "constant_score": { "filter": { "term": { "userInfo.username.keyword": "小鱼儿" } } } } } { "took": 2, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 1, "max_score": 1.2, "hits": [ { "_index": "website", "_type": "blogs", "_id": "1", "_score": 1.2, "_source": { "title": "我的第一篇博客", "content": "这是我的第一篇博客，开通啦！！！", "userInfo": { "userId": 1, "username": "小鱼儿" } } } ] } }Copied!
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
37
38
39
40
41
42
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
37
38
39
40
41
42
现在就不需要走应用层的 join：先搜一个数据，找到 id，再去搜另一份数据， 直接走一个有冗余数据的 type 即可，指定要的搜索条件，即可搜索出自己想要的数据来
# 文档型模型的优缺点
优点：性能高，不需要执行两次搜索
缺点：数据冗余，维护成本高
每次如果你的 username 变化了，同时要更新 user type 和 blog type
一般来说，对于 es 这种 NoSQL 类型的数据存储来讲，都是冗余模式， 当然，你要去维护数据的关联关系，也是很有必要的，所以一旦出现冗余数据的修改，必须记得将所有关联的数据全部更新