ElasticSearch (ES)學習之路（四）ES 中個別專有名詞解釋，以及在Kibanna中使用Resful風格操作ES

（一）個別名詞解釋：

Cluster （集羣）

一個集羣包含一個或多個分配了相同的集羣名稱的節點。每個集羣都有一個主節點是集羣自動選擇產生,並且可以決定如果當前主節點失敗，哪些可以替換。其下載解壓後實質也是一個集羣，只有一個節點而已（一個人也是一支軍隊原則）

Document（文檔）

文檔是存儲在elasticsearch中的一個JSON文件。這是相當與關係數據庫中表的一行數據。每個文檔被存儲在索引中，並具有一個類型和一個id。一個文檔是一個JSON對象

Index（索引）

索引就是像關係數據庫中的“數據庫”。通過映射可以定義成多種類型。索引是一個邏輯命名空間映射到一個或多個主要的分片，可以有零個或多個副本分片。

Type(類型)

Type是相當於關係數據庫的“表”。每種類型都有一列字段，用來定義文檔的類型。映射定義了對在文檔中的每個字段如何進行分析。 es 8.x 的時候好像是會刪除此規則

Id（標識）

每個文檔ID標識了一個文檔。一個文檔的索引/類型/ ID必須是唯一的。如果沒有提供ID，將是自動生成。（還可以看到路由）

Field（字段）

文檔中包含的一組字段或鍵值對。字段的值可以是一個簡單的（標量）值（如字符串，整數，日期），或者一個嵌套的結構就像一個數組或對象。一個字段就是類似關係數據庫表中的一列。映射的每個字段有一個字段的類型“type”（不要與文檔類型混淆），表示那種類型的數據可以存儲在該字段裏，如：整數，字符串，對象。映射還允許你定義（除其他事項外）一個字段的值如何進行分析。

Mapping（映射）

映射是像關係數據庫中的”模式定義“。每個索引都有一個映射，它定義了每個索引的類型，再加上一些索引範圍的設置。映射可以被明確地定義，或者在一個文檔被索引的時候自動生成。

Node（節點）

節點是屬於elasticsearch羣集的運行實例。測試的時候，在一臺服務器可以啓動多個節點，但通常情況下應該在一臺服務器運行一個節點。在啓動時，節點將使用單播（或組播，但是必須指定）來發現使用相同的羣集名稱的羣集，並會嘗試加入該羣集。

Text(文本)

文本（或全文）是普通非結構化的文本，如本段。默認情況下，文本將被分析成術語，術語纔是實際存儲在索引中。文本字段在索引時需要進行分析，以便全文搜索，全文查詢的關鍵字在搜索時，必須分析產生（搜索）與索引時相同的術語。

（二）Kibana操作ES

說明：如果覺得枯燥難懂，看起來喫力的話，暫時可直接將索引名認定爲關係型數據庫的數據庫名 ,類型名認定爲表名，文檔則對應着某行文檔ID 某行主鍵。

（1）Restful 風格 ES 操作概覽

請求方式	請求地址	功能描述
PUT	localhost:9200/索引名/類型名/文檔ID	創建文檔且指明ID
POST	localhost:9200/索引名/類型名	創建文檔隨機生成ID
GET	localhost:9200/索引名/類型名/文檔ID	精確到獲取某一具體文檔（根據ID）
DELETE	localhost:/索引名/類型名/文檔ID	精確到刪除某一文檔（根據ID）
POST	localhost:9200/索引名/類型名/文檔ID/_update	修改某一文檔
GET	localhost:9200/索引名/類型名/_search	查找當前索引文檔下全部數據

（2）索引操作

創建索引

PUT /索引名/類型名/文檔ID
{"請求體"}
-----------
PUT /索引名/類型名
{"請求體"}

此類型名可省略不寫其默認就會存在_doc 類型名下在8.x的時候類型會被移除

示例：創建一個名爲’lei’的索引庫類型名爲 one 指定一個文檔ID 爲1 這裏實質就是創建索引，類型，並插入一條文檔文檔ID 爲1

PUT /lei/one/1
{
"name":"aa",
"age":1
}

可視化界面查看數據

可以發現此索引成功創建且插入了一條文檔

刪除索引

根據url 進行不同粒度的刪除

DELETE /索引名/類型名/文檔ID
DELETE /索引名

DELETE /lei   刪除整個 lei 索引庫
DELETE /lei/one/1  刪除lei 索引庫 下 類型名爲one ,文檔ID 爲1 的數據

創建索引且指定字段類型

上邊數據我們已經是成功插入了進去，但是發現一個問題，就是這個文檔列不用指定類型嗎？那我上一條插入的數據是什麼類型呢？ name? age?

查看一下發現es 給我們默認配置了類型

發現其默認的給我們設定的列 name ,age 指定了兩個數據類型，可能這兩種類型並不是我們在插入時想要設置的類型，那麼是否可以自定義設置插入的數據類型，且插入的數據的類型嚴格按照我們的要求來呢？？

答案，當然是可以的！

下表爲es 中支持的數據類型

那麼，接下來，咱們自定義一個索引庫，且設置字段屬性約束

使用 mappings properties 進行設置字段類型然後查看

POST /lei/one
{
	"mappings":{
			"properties":{
				"name":{
					"type":"text"
				},
				"age":{
					"type":"integer"
				},
				"birthday":{
					"type":"date",
					"format":"yyyy-MM-dd HH:mm:ss"
				}
			}
	}
}

（3）文檔操作

創建文檔

PUT /索引名/類型名/文檔ID
{"請求體"}
--------------------
POST /索引名/類型名
{"請求體"}

注意哈 /lei 索引庫我們給字段是添加了約束的索引請求體格式也必須安裝其要求來喲！

PUT方式

PUT /lei/one/1
{
  "name":"小明",
  "age":12,
  "birthday":"1998-06-07 14:03:55"
}

POST方式

POST /lei/one/
{
  "name":"小麗",
  "age":22,
  "birthday":"2000-06-07 14:03:55"
}

修改文檔

PUT 方式

這種方式直接修改對應字段的值然後進行覆蓋

   PUT /索引名/類型名/文檔ID 
   {"請求體"}

POST 方式

POST /索引名/類型名/文檔ID/_update
{
    "doc":{
		"要修改的列":"值"
    }
}

可能有人在納悶，爲啥我POST 修改還要搞個doc 呢，，我直接POST 提交要修改的列可以不可以呢？咱們來試一下

果然，不替換url 直接覆蓋字段值，看起來是修改成功了

但是，除開修改的Name 字段其餘全部沒有了，這說明不用_update doc 其會修改，但是，某些未被修改的列會被移除，其文檔結構已被破壞，所以爲了數據結構穩定還是使用 _update doc 吧

獲取文檔

GET 索引名/類型名/文檔ID

GET 方式獲取所有索引類型下的所有文檔

GET 索引名/類型名/_search

查找_id 爲1的文檔

_search ？後邊爲要查詢的條件 q query 的意思例如查詢__id 爲1 則 q=_id:1 查詢名字爲小明 q=name:小明

GET /lei/one/_search?q=_id:1

查詢條件拼接

比如我要查name 爲小紅且_id 爲2的文檔

我們首先新增一條數據

POST /lei/one/2
{
  "name":"小麗2",
  "age":222,
  "birthday":"2000-06-07 14:03:55"
}

按道理來說，我查詢小麗應該只有一條數據啊，爲什麼這裏小麗2也出來了，其實可以看到他有個socre 分值

小麗分值是比小麗2高的，說白了一個匹配度的問題搜索條件小麗結果兩條數據的匹配度比一樣的，且做了個排序，分值（匹配度）高的在前參考百度搜索匹配度越高越在前（百度恰飯的真諦）拿錢讓你上榜一。。

刪除文檔

根據url 精度進行刪除可以直接刪索引庫也可以細分到刪除某一文檔

DELETE 索引名/類型名/文檔ID

添加字段

POST /文檔名/類型名
{
    "properties": {
       "添加的字段名": {
           "type": "字段的類型"
       }
   }
}

POST /lei/one/2/_update
{
 "doc":{
   "hobby":["籃球","擊劍"]
 }
}
POST /lei/one/7ErnHHMBjoLvVc_LTjx_/_update
{
 "doc":{
   "hobby":["足球","爬山"]
 }
}

ElasticSearch (ES)學習之路（四）ES 中個別專有名詞解釋，以及在Kibanna中使用Resful風格操作ES