〈二〉ElasticSearch的認識:索引、類型、文檔

  • 2019 年 10 月 3 日
  • 筆記

發表日期:2019年9月19日


上節回顧

在學習新的內容之前,先回顧一下上節的內容,上節主要講述了以下的內容:

  1. ElasticSearch是什麼?什麼是搜索引擎?為什麼選擇ElasticSearch?
  2. 搜索是怎麼做到的:分詞、倒排索引?
  3. 環境的搭建
  4. 如何通過kibana操作elasticsearch
  5. hello world中講述了如何使用「寫數據->查指定數據」,"寫數據->通過關鍵字搜索數據"

本節前言

這節將涉及index、type、document的增刪查改相關的內容。
index就像sql中的庫,type就像sql中的表,document就像sql中的記錄。
這節認識index,type,document,會幫助我們認識ElasticSearch數據存儲的邏輯結構。就好像你學SQL要先學會了建庫、建表,才能插入記錄。而一些更深一點的內容,例如如何對document進行搜索、排序,這些將留到下一節再講。


索引index

索引index是存儲document文檔數據的結構,意義類似於關係型資料庫中的資料庫。

創建索引

在上一節的hello world中,我們並沒有講如何創建索引,那裡直接就插入了數據,那樣的話ElasticSearch會幫我們以默認的配置來自動創建索引。
下面講一下如何手動創建索引:

語法:

// 語法:  PUT /索引名  {      index的配置(primary shard的數量等)  }

例子:

// 例子(不帶配置資訊的話以默認配置創建)【請不要複製這個注釋!】:  PUT /product    // 例子(帶配置資訊的話以配置資訊創建)【請不要複製這個注釋!】  PUT /product  {      "settings":{          "index":{              "number_of_shards":3,              "number_of_replicas":1            }       }  }

在上述的例子中:number_of_shards是主分片的數量;number_of_replicas是副本分片的數量(這裡提一下,number_of_replicas副本分片的數量是面向主分片的,所以這個值為1時代表每一個主分片有一個副本分片)。

返回結果:

{    "acknowledged": true,    "shards_acknowledged": true,    "index": "product"  }

【在插入一個文檔的時候,如果index還沒有創建,那麼會自動創建,這時候index的一些配置會採用默認的配置,默認的主分片數量是5,副本分片數量是1

查看索引

查看單個索引

語法:GET /索引名
效果:返回指定索引的資訊
例子:GET /product
返回結果解析:

  • aliases:是索引的別名,由於我們沒有定義索引別名所以沒有數據(索引別名後面再講)
  • mappings:是索引中存儲的數據的結構資訊,由於上圖的索引product中並沒有存儲document,而且我們也沒有指定,所以也為空。mappings定義了文檔的欄位的數據類型和搜索策略等資訊。【後面的知識點】
  • settings:索引的配置資訊
    • creation_date是創建日期(毫秒級別的時間戳)
    • number_of_shards是主分片數量
    • number_of_replicas是副本分片的數量
    • uuid是索引的id
    • version是索引的版本資訊
    • provided_name是索引名
      一個包含了mappings的結果圖:

查看所有索引

命令:GET /_cat/indices?v
效果:查看所有索引,顯示索引的健康狀態等資訊。
【如果沒有v選項,那麼就不會有第一行關於該列意義的頭部】
返回結果解析:

  • health: 索引的健康狀態(受分片的運行狀態影響)【集群管理的知識點】
  • status: 索引是開啟的還是關閉的
  • index: index的名稱
  • uuid:索引的UUID
  • pri: primary shared的數量
  • rep: replicated shared的數量
  • docs.count: 文檔document的數量
  • docs.deleted: 被刪除的文檔document的數量
  • store.size:總數據的大小
  • pri.store.size:主分片上的數據的大小(這裡因為只運行了一個服務節點,所以沒有可運行的副本分片,所以總數據大小等於主分片的數據大小)

刪除索引

語法:DELETE /索引名【支援同時刪除多個索引,以逗號分割,如DELETE /testindex1,testindex2】
語法例子:DELETE /product
返回結果:【當acknowledged為true的時候代表刪除成功】

{    "acknowledged": true  }

修改索引

【修改索引主要是修改分片數量、mapping、分詞器,由於mapping和分詞器涉及很深,需要前置知識,所以留到後面講。】

修改副本分片數量

不講語法了,直接看例子:

PUT /product/_settings  {    "index":{      "number_of_replicas":2    }  }

關閉索引

關閉索引是為了避免修改索引的配置時他人進行文檔讀寫。關閉索引後,就只能獲取索引的配置資訊,而不能讀寫索引中的document。有時候也用於關閉一些無用的索引來減少資源消耗。
語法:

  • 關閉索引:POST /索引名/_close
  • 打開索引:POST /索引名/_open

索引別名

索引別名是一個「別名」,但能夠像索引名那樣使用,它的使用場景一方面是「使用更簡潔的索引名來獲取數據」,另一個方面是「通過索引別名來指向索引(別名B指向索引A),方便修改指向的索引,用於解決可能的更換索引的場景(比如你需要統一修改原有索引的資訊,那你可以新建索引C,C存儲了修改後的數據,更改指向原本索引A的索引別名B指向C)。」

增加索引別名:

語法:

POST /_aliases  {      "actions":[          {              "add":{                  "index":"索引名",                  "alias":"索引別名"              }          }      ]  }

例子:

POST /_aliases  {    "actions":[      {        "add":{          "index":"product",          "alias":"pdt"        }      }      ]  }

查看索引別名:

  • 方法一:通過查看索引來查看索引別名:GET /product
  • 方式二:通過命令GET /product/_alias
  • 【索引別名有了就會生效,不信你在GET /product的時候直接用上別名】

刪除索引別名:

語法:

POST /_aliases  {      "actions":[          {              "remove":{                  "index":"索引名",                  "alias":"索引別名"              }          }      ]  }

例子:

POST /_aliases  {    "actions":[      {        "remove":{          "index":"product",          "alias":"pdt"        }      }      ]  }

【你應該看到了,actions裡面是一個數組,所以你是可以同時進行多個操作的。】

補充

  • 有很多關於index的配置。由於也是一個比較大的知識點(需要一些前置知識,單獨在這裡講的話會很空白),將會單獨列出來。
  • index有個mapping配置,mapping定義整體的index的document的結構,和影響分詞策略。由於會影響搜索,所以把這個歸為搜索的分支知識點,將留到搜索篇再談。

小節總結:

本小節講了如何創建索引,如何查看索引、如何刪除索引、如何修改索引(修改副本分片數量)、如何關閉/開啟索引、如何定義索引別名。
目的在於介紹如何創建存儲document的邏輯結構–索引,雖然我們有時候是不需要手動顯示創建索引的,但手動創建是個必須了解的知識,因為mapping和分詞器有時候需要手動來指定。


類型type

類型type也是用於存儲document的邏輯結構,相對於index來說,type是index的下級,所以通常在面向有實際意義的數據時,index作為大類的劃分,type作為小類的劃分。比如如果把book書作為一個大類來建立index的話,那麼書的類型(小說類、文學類、IT技術類等)就可以作為type。

你可能以為下面要講如何CRUD類型type了吧。但其實這裡並不需要講這些,因為type其實並不真的用來劃分邏輯結構,它只是意義上的!ElasticSearch使用了Lucene的底層架構,而Lucene是沒有type。

上面說了,index就像sql中的庫,type就像sql中的表,document就像sql中的記錄。
但事實上,ElasticSearch「真正用於分隔數據的結構「只有index,而沒有type,type實際上作為了一個元數據(類似SQL中的id,作為額外的標識數據)來實現邏輯劃分。【如果你不懂的話,可以從SQL方面想,就好像一個職員表,一條記錄中的某一個欄位說明了他屬於哪個部門】。當然了,這是一些偏原理的內容了。這些都將留到原理篇來闡述。這裡僅僅是淺嘗即止。
不過由於沒有type沒有真實地用於分隔數據,所以要注意結構類型偏差太大的數據還是不要放在一個index好。

之前說了,index用來劃分大類,type用來劃分小類。而可能有些人會把這個大類定的過大,比如電影和書籍這兩個小類(type)的數據大多是不一樣的,但他們都可以屬於娛樂這一個大類(index),由於type並沒有真實地用於分隔數據地用於存儲數據,所以數據存儲的時候針對的還是index。

ElaticSearch並不是完全無結構的,不要與某些NoSQL資料庫混為一談,雖然它的結構非常靈活(面向json,可以隨意增加欄位)。在index中還有一個mapping,mapping管理了整個index的各個欄位的屬性,也就是定義了整個index中document的結構。我們在index下不同type中定義的document的欄位都會在mapping中。所以說,如果你定義的多個type的結構偏差太大,那麼會導致mapping需要存儲的欄位的數據過多,同時也影響index的物理存儲結構,因為index會按照mapping來存儲數據。【換到SQL中的話,也就是比如你有一個商品表,商品表下面有各種商品(書籍、食物),而它們的數據是很不一樣的,比如書籍有出版日期,食物有保質期,如果把它們都放到一個表中的話,那麼就會導致這個表的欄位過多。】

如何測試document文檔的數據結構是面向index?【這個測試你可以不做,現在僅僅記住上面的知識點,測試後面再做,因為這個涉及到一些後面的知識】
1.定義一個document的一個欄位為date類型;然後在另一個type中添加為text類型的同名欄位。
當我們直接插入document的時候,如果不指定document的數據結構,那麼ElastciSearch會基於dynamic mapping來自動幫我們聲明每一個欄位的數據類型,比如"content":"hello world!"會被聲明成字元串類型,"post_date":"2017-07-07"會被認為是date類型。如果我們首先在一個type中聲明了content為字元串類型,再在另外一個type中聲明成日期類型,這會報錯,因為對於index來說,這個content已經被聲明成字元串類型了。

2.查看mapping:
在查看mapping的時候,我們是通過查看索引來查看的,其實也反向證明了mapping是面向index的。

補充:

  • 上面說了index的mapping會存儲完整的多個type的欄位資訊,如果type的欄位差別太大,那麼就會導致mapping需要存儲的欄位過多。ElasticSearch維護組織後面發現這多個type的情況確實有點煩人。於是他們準備讓一個index只放一個type了,在6.x版本中,一個索引下只有一個type,如果聲明多個type,會被標記為過期,但是仍可以使用。7.0之後的版本將完全移除ElasticSearch移除多個type

小節總結:

  • 本節重新解釋了type的意義,type實際上是作為document中的一個固定欄位存在的,文檔的數據結構是面向index的,所以不能把欄位差異性較大的數據存儲在一個index中。

文檔document

文檔的格式是json式的。
對於文檔,有幾個主要的標識資訊:_index(插入到哪個索引中),_type(插入到哪個類型中),_id(文檔的id是多少),在插入一個文檔的時候,這幾個資訊也是必須的。

  • 在考慮web開發的大多都知道json的基本格式,所以我這裡只會編寫一個簡單的json數據作為例子,json數據裡面的數據類型問題留到後面再進行補充。

插入文檔

語法:

PUT /index/type/id  json格式的數據

例子:

PUT /douban/book/4  {      "book_id":4,      "book_name":"Other Voices, Other Rooms",      "book_author":"Truman Capote",      "book_pages":240,      "book_express":"Vintage",      "publish_date":"1994-02-01",      "book_summary":"""    Truman Capote』s first novel is a story of almost supernatural intensity and inventiveness, an audacious foray into the mind of a sensitive boy as he seeks out the grown-up enigmas of love and death in the ghostly landscape of the deep South.      At the age of twelve, Joel Knox is summoned to meet the father who abandoned him at birth. But when Joel arrives at the decaying mansion in Skully』s Landing, his father is nowhere in sight. What he finds instead is a sullen stepmother who delights in killing birds; an uncle with the face—and heart—of a debauched child; and a fearsome little girl named Idabel who may offer him the closest thing he has ever known to love."""  }

結果解析:

  • _index:插入到哪個index中。
  • _type:插入到哪個type中。
  • _id:插入的文檔的id是多少。
  • _version:版本,對這個ID的文檔的操作次數
  • result:操作結果,第一次操作時created,上圖中因為我忘記截圖了,所以重新插入了一次,所以時updated
  • _shards:
    • total:總共有多少個shard
    • successful:成功多少個,【由於寫操作只會發生在primary shard中,所以這裡為1,另一個shard時replica shard,不發生寫操作】
    • failed:失敗多少個

查詢指定文檔

語法:

GET /index/type/id

例子:

GET /douban/book/1

結果解析:

更新文檔

語法:

// 全替換(覆蓋)式更新:會使用新的json數據直接覆蓋原有的【請不要複製注釋】  PUT /index/type/id  json數據    // 部分替換式更新:只會覆蓋指定數據  POST /index/type/id/_update  {    "doc": {      "需要修改的欄位": "修改值"      [,"需要修改的欄位": "修改值"]    }  }

例子:

【全替換語句與插入差不多,所以不舉例了】    POST /douban/book/4/_update  {    "doc": {      "book_pages":241,      "publish_date":"1994-02-02"    }  }

結果解析:
返回結果與插入時大概一致,不同的時result變成了updated

刪除文檔

語法:

DELETE /index/type/id

例子:
【刪除後可以重新執行插入語句恢複數據】

DELETE /douban/book/4

結果解析:
返回結果與插入時大概一致,不同的時result變成了deleted.

查詢所有文檔

語法:

GET /index/type/_search    GET /index/type/_search  {    "query":{      "match_all": {}    }  }

例子:

GET /douban/book/_search    GET /douban/book/_search  {    "query":{      "match_all": {}    }  }

補充:

上面介紹了關於文檔的CRUD基操,但還有很多東西沒講,這些將留到後面講,包括:文檔的欄位的數據類型、文檔的搜索、文檔的元數據(_index,_type,_id等)

小節總結

這節講了如何對文檔進行CRUD操作,PUT用於插入,GET用於查詢,PUT和POST用於修改,DELETE用於刪除。