Elasticsearch基礎知識彙總

時間 2019-11-07

原文原文鏈接

背景
爲何出現這項技術
行業其它相似技術的情況
自身特色
可以作什麼

一、怎麼用

1.1 分片擴展

主分片的數量在建立索引時已經肯定，實際上，這個數量定義了能存儲到索引裏數據的最大數量（實際的數量取決於你的數據、硬件和應用場景），然而，主分片或者複製分片均可以處理讀請求——搜索或文檔檢索，因此數據的冗餘越多，咱們能處理的搜索吞吐量就越大。複製分片的數量能夠在運行中的集羣中動態地變動，這容許咱們能夠根據需求擴大或者縮小規模。讓咱們把複製分片的數量從原來的 1 增長到 2 ：前端

PUT /blogs/_settings  
{
    "number_of_replicas" : 2
}
複製代碼

固然，在一樣數量的節點上增長更多的複製分片並不能提升性能，由於這樣作的話平均每一個分片的所佔有的硬件資源就減小了（注：大部分請求都彙集到了分片少的節點，致使一個節點吞吐量太大，反而下降性能），你須要增長硬件來提升吞吐量。
不過這些額外的複製節點使咱們有更多的冗餘：經過以上對節點的設置，咱們可以承受兩個節點故障而不丟失數據。node

1.2 索引的屬性詳解

_source、_all、store和index屬性

如今有一份原始文檔，內容以下：json

{
    "title":"我是中國人"，
    "content":"熱愛祖國"
}
複製代碼

_source

把數據寫入到ES中，默認狀況下，Elasticsearch裏面有2分內容，一份是原始文檔，也就是_source字段裏的內容。另外一份是倒排索引，倒排索引中的數據結構是倒排記錄表，記錄了詞項和文檔之間的對應關係，好比關鍵詞」中國人」包含在文檔ID爲1的文檔中，倒排記錄表中存儲的就是這種對應關係，固然也包括詞頻等更多信息。segmentfault

index

那麼文檔索引到Elasticsearch的時候，默認狀況下是對全部字段建立倒排索引的(動態mapping解析出來爲數字類型、布爾類型的字段除外)，某個字段是否生成倒排索引是由字段的index屬性控制的，在Elasticsearch 5以前，index屬性的取值有三個:api

analyzed:
字段被索引，會作分詞，可搜索。反過來，若是須要根據某個字段進搜索，index屬性就應該設置爲analyzed。
not_analyzed：
字段值不分詞，會被原樣寫入索引。反過來，若是某些字段須要徹底匹配，好比人名、地名，index屬性設置爲not_analyzed爲佳。
no:
字段不寫入索引，固然也就不能搜索。反過來，有些業務要求某些字段不能被搜索，那麼index屬性設置爲no便可。

_all

_all字段包含了一個文檔裏面的全部信息，是一個超級字段。以上面文檔爲例，若是開啓_all字段，那麼title+content會組成一個超級字段，這個字段包含了其餘字段的全部內容，固然也能夠設置只存儲某幾個字段到_all屬性裏面或者排除某些字段。數組

store

作一個說明：
用戶查詢時輸入「中國人」，這時還沒分詞進行查詢時，「中國人」稱爲query，而後ES從倒排索引列表中查找哪些文檔包含了的「中國人」，,注意變化，分詞以前" 中國人"是用戶查詢(query)，分詞以後在倒排索引中"中國人"是詞項(term)。Elasticsearch根據文檔ID(一般是文檔ID的集合)返回文檔內容給用戶。安全

根據結果高亮的場景來分析理解store屬性，高亮實質上是根據倒排記錄中的詞項偏移位置，找到關鍵詞，加上前端的高亮代碼。這裏就要說到store屬性，store屬性用於指定是否將原始字段寫入索引，默認取值爲no。若是在Lucene中，高亮功能和store屬性是否存儲息息相關，由於須要根據偏移位置到原始文檔中找到關鍵字才能加上高亮的片斷。在Elasticsearch，由於_source中已經存儲了一份原始文檔，能夠根據_source中的原始文檔實現高亮，在索引中再存儲原始文檔就多餘了，因此Elasticsearch默認是把store屬性設置爲no。bash

注意:若是想要對某個字段實現高亮功能，_source和store至少保留一個。下面會給出測試代碼。數據結構

1.3 API使用

1.3.1 經常使用API總結

1.3.1.1 集羣狀態方面

_cat命令 GET /_catapp
如何安全重啓索引

第一步：先暫停集羣的shard自動均衡。
```
curl -XPUT http://192.168.1.2:9200/_cluster/settings -d' { "transient" : { "cluster.routing.allocation.enable" : "none" } }'
複製代碼
```
第二步：shutdown你要升級的節點
```
curl -XPOST http://192.168.1.3:9200/_cluster/nodes/_local/_shutdown
複製代碼
```
第三步：升級重啓該節點，並確認該節點從新加入到了集羣中

第四步：重複2-3步，升級重啓其它要升級的節點。

第五步：重啓啓動集羣的shard均衡
```
curl -XPUT http://192.168.1.2/_cluster/settings -d' { "transient" : { "cluster.routing.allocation.enable" : "all" } }'
複製代碼
```
到此整個集羣安全升級而且重啓結束。

1.3.1.2 index設置方面

一、settings

使用 curl設置舉例

curl -XPUT http://192.168.12.165:9200/testindex -H "Content-Type:application/json" -d' "settings" : { "number_of_shards" : "3", "number_of_replicas" : "0" } '
複製代碼

二、mapping

三、開啓和關閉index

使用head插件關閉與開啓某個index
狀態說明：在close時，該索引所佔用的相關內存，（包括各類query cache，前綴索引等等）都會被釋放，而後該索引達到不可查的狀態，open時會前綴索引再從新加載到內存
調用api

1.3.1.3 數據分析方面

analyzer測試

測試分詞器分詞後的效果，使用中文分詞器ik的ik_smart模式分詞下面的句子

GET /_analyze
{
   "text" : "this二我的爲何OKOK",
  "analyzer":"ik_smart"
}
複製代碼

結果：

{
  "tokens" : [
    {
      "token" : "二我的",
      "start_offset" : 4,
      "end_offset" : 7,
      "type" : "CN_WORD",
      "position" : 0
    },
    {
      "token" : "爲何",
      "start_offset" : 7,
      "end_offset" : 10,
      "type" : "CN_WORD",
      "position" : 1
    },
    {
      "token" : "okok",
      "start_offset" : 10,
      "end_offset" : 14,
      "type" : "ENGLISH",
      "position" : 2
    }
  ]
}
複製代碼

1.3.1.4 數據的增刪改查方面

term和match的區別
term是表明徹底匹配，即不進行分詞器分析，文檔中必須包含整個搜索的詞彙
match和term的區別是,match查詢的時候,elasticsearch會根據你給定的字段提供合適的分析器,而term查詢不會有分析器分析的過程，match查詢至關於模糊匹配,只包含其中一部分關鍵詞就行
車牌號模糊與時間範圍檢索舉例

GET /multobj/x_model/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "plateNumber": "京BA"
          }
        },
        {
          "range": {
            "ctime": {
              "lt": "2019-10-31T01:00:00",
              "gte": "2019-10-31T00:00:00"
            }
          }
        }
      ]
    }
  },
  "size": 1000,
  "sort": {
    "ctime": "asc"
  },
  "_source": [
    "plateNumber",
    "brand",
    "ctime"
  ]
}
複製代碼

多屬性查詢

#多屬性查詢
GET multobj004/_doc/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "range": {
            "ctime": {
              "gte": "2019-01-01T00:00:00",
              "lt": "2020-01-01T00:00:00"
            }
          }
        },
        {
          "match": {
            "targetType": "car"
          }
        },
        {
          "match": {
            "sourceType": "zipFile"
          }
        },
        {
          "match": {
            "color": "white"
          }
        },
        {
          "match": {
            "plateNumber": {
              "query": "23",
              "analyzer": "whitespace"
            }
          }
        }
      ]
    }
  },
  "_source": [
    "plateNumber",
    "UUID",
    "ctime",
    "targetType",
    "sourceType"
  ],
  "from": 0,
  "size": 1000,
  "sort": {
    "ctime": "desc"
  }
}

複製代碼

查詢接口返回結果字段說明

took— Elasticsearch執行搜索的時間（以毫秒爲單位）  
timed_out — 告訴咱們搜索是否超時  
_shards — 告訴咱們搜索了多少個碎片，以及搜索成功/失敗碎片的計數  
hits — 搜索結果  
hits.total — 符合咱們搜索條件的文檔總數  
hits.hits — 實際的搜索結果數組（默認爲前10個文檔）  
hits.sort — 對結果進行排序（若是按分數排序則丟失）  
hits._score和max_score — 暫時忽略這些字段
複製代碼

提升精度(Improving Precision)
match查詢接受一個operator參數，該參數的默認值是"or"。你能夠將它改變爲"and"來要求全部的詞條都須要被匹配：

GET /my_index/my_type/_search  
{  
    "query": {  
        "match": {  
            "title": {      
                "query":    "BROWN DOG!",  
                "operator": "and"  
            }  
        }  
    }  
} 
複製代碼

控制精度(Controlling Precision)

在all和any中選擇有種非黑即白的感受。若是用戶指定了5個查詢詞條，而一份文檔只包含了其中的4個呢？將"operator"設置成"and"會將它排除在外。有時候這正是你想要的，可是對於大多數全文搜索的使用場景，你會但願將相關度高的文檔包含在結果中，將相關度低的排除在外。換言之，咱們須要一種介於二者中間的方案。
match查詢支持minimum_should_match參數，它可以讓你指定有多少詞條必須被匹配纔會讓該文檔被當作一個相關的文檔。儘管你可以指定一個詞條的絕對數量，可是一般指定一個百分比會更有意義，由於你沒法控制用戶會輸入多少個詞條：

GET /my_index/my_type/_search
{
  "query": {
    "match": {
      "title": {
        "query": "quick brown dog",
        "minimum_should_match": "75%"
      }
    }
  }
}  
複製代碼

當以百分比的形式指定時，minimum_should_match會完成剩下的工做：在上面擁有3個詞條的例子中，75%會被向下舍入到66.6%，即3個詞條中的2個。不管你輸入的是什麼，至少有2個詞條被匹配時，該文檔纔會被算做最終結果中的一員。