概述

继续跟中华石杉老师学习ES，第54篇

课程地址： https://www.roncoo.com/view/55

关系型与document类型数据模型对比

举个例子： 部门和员工 ，1个部门下可以有N多个员工 ，部门：员工 = 1：N 1对多的关系。

关系型数据库

部门Department 表

dept_id  name  desc

员工Employee 表 （通过dept_id关联到所属的部门）

emp_id name age gender  dept_id

数据库的设计还是遵循了三范式：将每个数据实体拆分为一个独立的数据表，同时使用主外键关联关系将多个数据表关联起来 , 确保没有任何冗余的数据 .

一份数据，只会放在一个数据表中,比如dept name，部门名称，就只会放在department表中，不会在employee表中也放一个dept name，如果说你要查看某个员工的部门名称，那么必须通过员工表中的外键，dept_id，找到在部门表中对应的记录，然后找到部门名称 。

应用Model

/**
* 部门
**/
public class Department {
	
	private Integer deptId;
	private String name;
	private String desc;
	// 部门中存放一个 员工的集合 
	private List<Employee> employees;

}


/**
* 员工
**/
public class Employee {
	
	private Integer empId;
	private String name;
	private Integer age;
	private String gender;
	// 所在部门
	private Department dept;

}

es文档数据模型

{
	"deptId": "1",
	"name": "研发部门",
	"desc": "负责公司的所有研发项目",
	"employees": [
		{
			"empId": "1",
			"name": "张三",
			"age": 28,
			"gender": "男"
		},
		{
			"empId": "2",
			"name": "王兰",
			"age": 25,
			"gender": "女"
		},
		{
			"empId": "3",
			"name": "李四",
			"age": 34,
			"gender": "男"
		}
	]
}

es更加类似于面向对象的数据模型，将所有由关联关系的数据，放在一个doc json类型数据中，整个数据的关系，还有完整的数据，都放在了一起.

建模方式一：通过应用层join实现用户与博客的关联

构造用户与博客数据

# 让ES自动创建 users索引，并写入一条数据
PUT /users/users/1 
{
  "name":     "小工匠",
  "email":    "artisan@artisan.com",
  "birthday":      "2000-01-01"
}

#让ES自动创建 blogs ,并写入一条数据
PUT /blogs/blogs/1
{
  "title":    "跟石杉老师学ES",
  "content":     "数据建模之通过【应用层join】或者【数据冗余】实现实现用户与博客的关联",
  "userId":     1 
}

搜索某个用户发表的所有博客

# 第一次搜索  查询name为 小工匠的用户 （这里需要name.keyword 不分词查询）
GET /users/users/_search
{
  "query": {
    "term": {
      "name.keyword": {
        "value": "小工匠"
      }
    }
  }
}

# 第二次搜索，要放入terms中userId
GET /blogs/blogs/_search
{
  "query": {
    "bool": {
      "filter": {
        "terms": {
          "userId": [
            1
          ]
        }
      }
    }
  }
}

假设搜索的是，1万个用户的博客，可能第一次搜索，会得到1万个userId ， 第二次搜索的时候，要放入terms中1万个userId，才能进行搜索，这个时候性能比较差了 。

优缺点

• 优点：数据不冗余，维护方便
• 缺点：应用层join，如果关联数据过多，导致查询过大，性能很差

建模方式二：通过数据冗余实现用户与博客的关联

第二种建模方式：用冗余数据，采用文档数据模型，进行数据建模，实现用户和博客的关联, 在ES的应用中，推荐这种方式建模。

构造用户与博客数据

# 让ES自动创建 users2索引，并写入一条数据
PUT /users2/users2/1
{
  "name": "小工匠",
  "email": "artisan@artisan.com",
  "birthday": "2000-01-01"
}

#让ES自动创建 blogs2 ,并写入一条数据
PUT /blogs2/blogs2/1
{
  "title": "跟石杉老师学ES",
  "content": "数据建模之通过【应用层join】或者【数据冗余】实现实现用户与博客的关联",
  "userInfo": {
    "userId": 1,
    "username": "小工匠"
  }
}

冗余数据就是说将可能会进行搜索的条件和要搜索的数据，放在一个doc中

搜索某个用户发表的所有博客

GET /blogs2/blogs2/_search 
{
  "query": {
    "term": {
      "userInfo.username.keyword": {
        "value": "小工匠"
      }
    }
  }
}

可以看到不需要走应用层的join，先搜一个数据，找到id，再去搜另一份数据，直接走一个有冗余数据的type即可，指定要的搜索条件，即可搜索出自己想要的数据来。

优点和缺点

• 优点：性能高，不需要执行两次搜索
• 缺点：数据冗余，维护成本高 ，每次username变化了，同时要更新user type和blog type

一般来说，对于es这种NoSQL类型的数据存储来讲，都是冗余模式…

当然，我们要去维护数据的关联关系，也是很有必要的，所以一旦出现冗余数据的修改，必须记得将所有关联的数据全部更新。