文章目錄

• 概述
• 關系型與document類型數據模型對比
• • 關系型數據庫
  • 應用Model
  • es文檔數據模型
• 建模方式一：通過應用層join實現用戶與博客的關聯
• • 構造用戶與博客數據
  • 搜索某個用戶發表的所有博客
  • 優缺點
• 建模方式二：通過數據冗余實現用戶與博客的關聯
• • 構造用戶與博客數據
  • 搜索某個用戶發表的所有博客
  • 優點和缺點

---

概述

繼續跟中華石杉老師學習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類型的數據存儲來講，都是冗余模式…

當然，我們要去維護數據的關聯關系，也是很有必要的，所以一旦出現冗余數據的修改，必須記得將所有關聯的數據全部更新。

總結

以上是生活随笔為你收集整理的白话Elasticsearch54-数据建模之通过【应用层join】或者【数据冗余】实现实现用户与博客的关联的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。