59_通過應用層join實現使用者與部落格的關聯

一、概述

1、構造使用者與部落格資料

在構造資料模型的時候，還是將有關聯關係的資料，然後分割為不同的實體，類似於關係型資料庫中的模型

案例背景：部落格網站， 我們會模擬各種使用者發表各種部落格，然後針對使用者和部落格之間的關係進行資料建模，同時針對建模好的資料執行各種搜尋/聚合的操作

PUT /website/users/1 
{
  "name":     "喬峰",
  "email":    "[email protected]",
  "birthday":      "1980-01-01"
}

PUT /website/blogs/1
{
  "title":    "我的第一篇部落格",
  "content":     "這是我的第一篇部落格，開通啦！！！"
  "userId":     1 
}

 

一個使用者對應多個部落格，一對多的關係，做了建模

建模方式，分割實體，類似三正規化的方式，用主外來鍵關聯關係，將多個實體關聯起來

2、搜尋喬峰發表的所有部落格

GET /website/users/_search 
{
  "query": {
    "term": {
      "name.keyword": {
        "value": "喬峰"
      }
    }
  }
}

{
  "took": 91,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 0.2876821,
    "hits": [
      {
        "_index": "website",
        "_type": "users",
        "_id": "1",
        "_score": 0.2876821,
        "_source": {
          "name": "喬峰",
          "email": "
 
[email protected]",
          "birthday": "1980-01-01"
        }
      }
    ]
  }
}

比如這裡搜尋的是，1萬個使用者的部落格，可能第一次搜尋，會得到1萬個userId

GET /website/blogs/_search 
{
  "query": {
    "constant_score": {
      "filter": {
        "terms": {
          "userId": [
            1
          ]
        }
      }
    }
  }
}
 

第二次搜尋的時候，要放入terms中1萬個userId，才能進行搜尋，這個時候效能比較差了

{
  "took": 4,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 1,
    "hits": [
      {
        "_index": "website",
        "_type": "blogs",
        "_id": "1",
        "_score": 1,
        "_source": {
          "title": "喬峰的第一篇部落格",
          "content": "大家好，我是喬峰，這是我寫的第一篇部落格！",
          "userId": 1
        }
      }
    ]
  }
}

上面的操作，就屬於應用層的join，在應用層先查出一份資料，然後再查出一份資料，進行關聯

3、優點和缺點

• 優點：資料不冗餘，維護方便

• 缺點：應用層join，如果關聯資料過多，導致查詢過大，效能很差

相關文章