Elasticsearch中的index相當於RDBMS(關系型數據庫, 比如MySQL)中的DataBase.
本篇文章通過Kibana插件, 演示了ES的基礎語法: 對ES中的index進行CRUD(增刪改查)以及關閉、開啟操作.
閱讀須知:
在ES 6.x之前的版本中, 每個index中可以有多個type, 類似於MySQL中每個數據庫可以有多張表, 可在ES 6.0開始, 每個index都只能有1個type.
本篇文章寫作較早, 用的是ES 5.6版本, 因此有些操作可能出現不支持等問題, 還請讀者查閱解決:-)
1 創建index(配置mapping[映射])
(1) 創建語法:
PUT index
{
"settings": { ... some settings ... },
"mappings": {
// ES 6.x開始不再支持1個index中同時存在多個type
"type1": { ... some mappings ... },
"type2": { ... some mappings ... },
...
}
}
如果不指定settings和mappings, 直接插入數據時, ES會根據要插入數據的類型, 自動創建相關配置 —— 功能強大, 但擴展性不夠, 后續若有其他原因需要修改mappings, 會很困難.
—— 所以創建index時, 推薦手動指定settings和mappings的相關配置. 可以參考文章: ES XX - ES的mapping的設置.
(2) 創建示例:
PUT address // 關於地址(address)的索引
{
"settings": {
"number_of_shards": 1, // 默認分片數為5
"number_of_replicas": 0 // 默認副本數為1
},
"mappings": {
"province": { // type是province(省份)
"properties": {
"name": {
"type": "text" // 存儲類型是text
},
"area": {
"type": "float"
}
}
}
}
}
(3) 創建結果:
{
"acknowledged": true,
"shards_acknowledged": true,
"index": "address"
}
2 查看index
(1) 查看示例:
GET address
// 也可同時查看多個索引, 類似於刪除操作:
GET *
GET _all
GET *index*
GET address,shop
// 在6.0之前的版本中, 還可以指定返回某些指定項的結果:
GET address/_settings,_mappings
- 棄用提示:
查看索引時, 若通過","分隔要返回的結果, Elasticsearch將拋出如下警告:
#! Deprecation: Requesting comma-separated features is deprecated and will be removed in 6.0+, retrieve all features instead.意為: Elasticsearch不推薦使用逗號分隔功能, 將在6.0+中刪除. 建議不要使用",", 而是直接檢索全部數據, 或檢索某一項的結果.
在ES 6.6.0中將直接出現:
{ "error": "Incorrect HTTP method for uri [/address/_settings,_mappings?pretty] and method [GET], allowed: [POST]", "status": 405 }換做POST請求時, 必須攜帶請求體, 仍然不支持.
(2) 查看的結果:
{
"address": {
"aliases": {},
"mappings": {
"province": {
"properties": {
"area" : {
"type" : "float"
},
"name" : {
"type" : "text"
}
}
}
},
"settings": {
"index": {
"creation_date": "1542108754899",
"number_of_shards": "1",
"number_of_replicas": "0",
"uuid": "MMpLNHzZR8K1k48rJplWVw",
"version": {
"created": "6060099"
},
"provided_name": "address"
}
}
}
}
3 修改index
修改索引的示例:
PUT address/_settings
{
"number_of_replicas": 1 // 修改副本數為1
}
說明: Elasticsearch中的分片數(number_of_shards)只能在創建索引時設置, 無論是否添加過數據, 都不支持修改.
這與文檔的路由有關, 而Solr的
SPLITSHARD可以算作動態修改分片的另一種思路: 只對某一路由范圍內的進行拆分, 可以參考 管理SolrCloud集群 (創建集合、切割分片、更新配置) 第5節的內容.
關於修改ES的分片數, 應該有其他思路, 后期了解到再作研究整理.
4 刪除index
刪除索引需要指明索引名稱、別名或通配符.
Elasticsearch支持同時刪除多個索引, 或使用_all或通配符*刪除全部索引.
刪除示例:
DELETE address // 刪除指定索引
DELETE index1,index2 // 刪除多個索引
DELETE index_* // 按通配符刪除以'index_'開頭的索引
DELETE _all // 刪除全部索引
為避免_all操作誤刪除全部索引, 可在配置文件elasticsearch.yml中作如下配置:
# 要求操作索引時必須指定索引的名稱
action.destructive_requires_name: true
5 打開/關閉index
(1) 操作說明:
① 可以打開一個已經打開/關閉的索引, 以最后一次操作為准;
② 可以關閉一個已經關閉/打開的索引, 以最后一次操作為准;
③ 關閉的索引只能查看index的配置信息, 不能對內部的索引數據進行讀寫操作.
(2) 操作示例:
// 可以使用_all打開或關閉全部索引, 也可使用通配符(*)配合操作
POST address/_close
POST address/_open
說明事項:
① 使用
_all或通配符操作索引, 都會受到配置文件中action.destructive_requires_name=true的限制.
② 關閉的索引會繼續占用磁盤空間, 卻又不能使用 —— 造成磁盤空間的浪費.
③ 可以在配置文件中禁止使用關閉索引的功能:settingscluster.indices.close.enable=false, 默認為true(開啟).
6 常見問題及解決方法
(1) 查看不存在的索引時, 將拋出如下錯誤信息:
如果要查看的索引不存在, 比如GET addre, 就會拋出類似下面的異常信息:
{
"error" : {
"root_cause" : [
{
"type" : "index_not_found_exception",
"reason" : "no such index",
"resource.type" : "index_or_alias",
"resource.id" : "addre",
"index_uuid" : "_na_",
"index" : "addre"
}
],
"type" : "index_not_found_exception",
"reason" : "no such index",
"resource.type" : "index_or_alias",
"resource.id" : "addre",
"index_uuid" : "_na_",
"index" : "addre"
},
"status" : 404
}
(2) 在6.0之前的版本中, 如果修改已經關閉了的索引, 會拋出類似於下面的錯誤:
{
"error": {
"root_cause": [
{
"type": "illegal_argument_exception",
"reason": "Can't update [index.number_of_replicas] on closed indices [[address/MMpLNHzZR8K1k48rJplWVw]] - can leave index in an unopenable state"
}
],
"type": "illegal_argument_exception",
"reason": "Can't update [index.number_of_replicas] on closed indices [[address/MMpLNHzZR8K1k48rJplWVw]] - can leave index in an unopenable state"
},
"status": 400
}
在本篇博客演示所用的Elasticsearch 6.6.0版本中, 並不存在此異常信息.
版權聲明
出處: 博客園 馬瘦風的博客(https://www.cnblogs.com/shoufeng)
感謝閱讀, 如果文章有幫助或啟發到你, 點個[好文要頂👆] 或 [推薦👍] 吧😜
本文版權歸博主所有, 歡迎轉載, 但 [必須在文章頁面明顯位置標明原文鏈接], 否則博主保留追究相關人員法律責任的權利.
