目錄
- 上節回顧
- 本節前言
- 索引index
- 創建索引
- 查看索引
- 查看單個索引
- 查看所有索引
- 洗掉索引
- 修改索引
- 修改副本分片數量
- 關閉索引
- 索引別名
- 增加索引別名:
- 查看索引別名:
- 洗掉索引別名:
- 補充
- 小節總結:
- 型別type
- 補充:
- 小節總結:
- 檔案document
- 插入檔案
- 查詢指定檔案
- 更新檔案
- 洗掉檔案
- 查詢所有檔案
- 補充:
- 小節總結
發表日期:2019年9月19日
上節回顧
在學習新的內容之前,先回顧一下上節的內容,上節主要講述了以下的內容:
- ElasticSearch是什么?什么是搜索引擎?為什么選擇ElasticSearch?
- 搜索是怎么做到的:分詞、倒排索引?
- 環境的搭建
- 如何通過kibana操作elasticsearch
- 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用于洗掉,
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/7352.html
標籤:其它
下一篇:資料庫系統原理(第一章概述)
