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

時間 2019-11-06

原文原文鏈接

發表日期：2019年9月19日web

上節回顧

在學習新的內容以前，先回顧一下上節的內容，上節主要講述瞭如下的內容：sql

ElasticSearch是什麼？什麼是搜索引擎？爲何選擇ElasticSearch?
搜索是怎麼作到的：分詞、倒排索引？
環境的搭建
如何經過kibana操做elasticsearch
hello world中講述瞭如何使用「寫數據->查指定數據」,"寫數據->經過關鍵字搜索數據"

本節前言

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

索引index

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

建立索引

在上一節的hello world中，咱們並無講如何建立索引，那裏直接就插入了數據，那樣的話ElasticSearch會幫咱們以默認的配置來自動建立索引。
下面講一下如何手動建立索引：json

語法：數組

// 語法：
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時表明每個主分片有一個副本分片)。架構

返回結果：app

{
  "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用於刪除。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。