Elasticsearch基礎但很是有用的功能之一：別名

時間 2020-12-09

標籤 html mysql linux git sql windows api 安全數據結構 app 欄目日誌分析简体版

原文原文鏈接

0、題記

本文是系列文章第一篇。介紹Elasticsearch的一些很是基礎但實戰開發確很是有用的技術點。瞭解這些技術點會幫助你設計更易於維護的數據索引，預先知道PB級大數據索引實戰中的坑，提高工做效率。html

本文從別名分類、索引別名實踐、索引別名的好處、索引別名常見問題及坑解讀、字段別名實踐一把五個方面進行詳細解讀。mysql

一、別名分類

別名在Elasticsearch中有兩種分類。linux

1.1 索引別名

官方釋義：索引別名能夠指向一個或多個索引，而且能夠在任何須要索引名稱的API中使用。別名爲咱們提供了極大的靈活性。它們容許咱們執行如下操做： git

1）在正在運行的集羣上的一個索引和另外一個索引之間透明切換； sql

2）對多個索引進行分組組合（例如，lastthreemonths的索引別名：是過去3個月索引 logstash201903, logstash201904, logstash_201905的組合）；windows

3）在索引中的文檔子集上建立「視圖」（結合業務場景，會提高檢索效率）。api

通俗解釋：索引別名相似：windows的快捷方式，linux的軟連接，mysql的視圖。安全

前提：Elasitcsearch建立索引後，索引名不容許改。不少業務場景下單一索引可能沒法知足要求。數據結構
場景1：PB級別增量數據，藉助rollover api實現，由基於日期的n個索引組成，顯然，對外提供服務使用別名會很便捷。app
場景2：試想，線上提供服務的某個索引出了問題，好比：某字段分詞定義不許確，如何保證對外提供服務不中止（不更改業務代碼）的前提下更換索引，顯然，別名更合適。

注意：實際業務場景使用別名會很方便、靈活、快捷、業務鬆耦合！！

1.2 字段別名

在Elasticsearch Mapping定義的6.4+版本纔有的字段類型。

通俗解釋：

試想一下有一種業務場景。好比在實際的業務開發中：須要對Facebook、twitter行採集,採集入庫的是兩個業務團隊。

他們對content，分別使用了兩個字段。其中一個是，content。另一個是cont。這時候存儲到elasticsearch會有兩個字段。

這樣若是咱們在檢索、寫業務代碼的時候，是否是要寫兩個不一樣的字段來處理呢？若是有可能寫成一個字段，代碼方面就很避開業務耦合，就很方便了。

我認爲這是字段別名的由來。

二、索引別名實踐

2.1 假設沒有別名，如何處理多索引檢索？

方式一：多索引逗號分隔檢索。

POST visitor_logs_2017,visitor_logs_2018/_search

方式二：通配符索引檢索。

POST visitor_logs_*/_search

2.2 有了別名後，操做變得簡單

實戰中，咱們不須要知道操做的實際索引名稱，咱們能夠透明地更改別名引用的索引而不會影響使用別名的用戶。

步驟1：別名關聯已有索引。

POST /_aliases?pretty
{
  "actions": [
    {
      "add": {
        "index": "visitor_logs_2017",
        "alias": "visitor_logs"
      }
    },
    {
      "add": {
        "index": "visitor_logs_2018",
        "alias": "visitor_logs"
      }
    }
  ]
}

步驟2：使用別名檢索

GET /visitor_logs/_search

三、索引別名的好處

3.1 大數據量的管理

場景：實戰中，可能須要基於時間的數據保留策略（利用rollover機制實現），並從系統中刪除舊數據。使用索引別名：

好處1：來簡化從Elasticsearch中刪除數據的過程。
好處2：在沒有任何停機時間的狀況下從Elasticsearch中刪除最舊的數據，不會出現任何查詢中斷，也不會進行任何客戶端更改。

基於時間索引的實現機制以下：

推薦閱讀：

https://gitbook.cn/books/5c52c6923417565017a61ce0/index.html

試想一下：若是不是基於時間的索引，而使用大索引，刪除歷史數據會發生什麼？

答案：

一、刪除索引數據只能使用：deletebyquery，相比刪除索引，deletebyquery刪除數據只是邏輯刪除；
二、真正的刪除實際是段合併後的物理刪除分段，也就是deletebyquery後，有一段時間磁盤空間不降反升。此時的檢索效率會很是低。

3.2 用戶無感知的重建索引

實戰中，索引的設計可能不是一步到位。隨着業務的擴展，可能會在開發的中後期，調整索引Mapping結構，好比：

1）iksmart改爲ikmax_word分詞以高效分詞，
2）long類型改爲keyword以提高檢索效率，
3）修改索引分片數以便於機器橫向擴展，
4）索引分紅更小粒度的索引等以提高性能。

一般的作法，都須要藉助：reindex操做完成索引的遷移。若是要確保線上環境的可靠運行且用戶無感知（即無需告知用戶，不影響用戶的業務），使用別名指向更改前和更改後的索引是絕佳方案。

實戰舉例:

POST /_aliases?pretty
{
  "actions": [
    {
      "remove": {
        "index": "visitor_logs_2018",
        "alias": "visitor_logs"
      }
    },
    {
      "add": {
        "index": "visitor_logs_2018_01",
        "alias": "visitor_logs"
      }
    }
  ]
}

試想一下，若是沒有索引別名呢？

答案：

一、沒法保證查詢的連續性；
二、沒法保證線上業務查詢的可靠性（須要告知用戶，業務中斷一段時間）。

四、索引別名常見問題及坑解讀

問題1：ES批量插入可使用別名插入嗎？

會報錯：

no write index is defined for alias[xxx]....

注意：索引別名不是在任何地方都通用。寫入或更新數據的時候須要指明物理索引，不要向別名寫入數據。

問題2：ES怎麼獲取全部別名信息 alias?

或者問題：如何經過索引別名查找實際索引名稱？

GET _cat/aliases

返回信息：

visitor_logs visitor_logs_2017 - - -
.kibana      .kibana_1         - - -
visitor_logs visitor_logs_2018 - - 
`

問題3：使用別名和基於索引效率同樣嗎？

是一致的。

前提：索引和別名指向相同的數據，相同的檢索條件。

原理：索引別名只是物理索引的軟連接名稱而已。

問題4：如何使用別名提高檢索效率？

方式一：基於時間建立索引，指定多索引別名。好比分爲：近1年索引別名，近3個月索引別名，近1個月索引別名，近1周索引別名，近3天索引別名。檢索的時候，先敲定時間範圍，而後在指定範圍的別名下檢索。

核心原理：物理上基於時間作了分隔，再加上冷熱數據分離機制，會極大縮小了檢索樣本。

方式二：使用filter 別名或者路由別名機制，提高效率。 filter Alias上代碼，實際業務中極易被忽視，但會極大提高效率。

POST /_aliases
{
    "actions" : [
        {
            "add" : {
                 "index" : "test1",
                 "alias" : "alias2",
                 "filter" : { "term" : { "user" : "kimchy" } }
            }
        }
    ]
}

路由機制參考官方文檔便可。

五、字段別名實踐一把

星友的問題：

「Aliasdatatype，這個數據類型，在現實工做中的使用場景是什麼？看官方文檔，沒有很好理解？」

字段別名原理第一部分已詳細解釋，再也不贅述。這裏實踐一把，加深理解。

PUT trips
{
  "mappings": {
    "_doc": {
      "properties": {
        "distance": {
          "type": "long"
        },
        "route_length_miles": {
          "type": "alias",
          "path": "distance"
        },
        "transit_mode": {
          "type": "keyword"
        }
      }
    }
  }
}

注意：當用戶使用檢索時，實際可使用routelengthmile字段替代distance作檢索，以達到distance同樣的效果。

六、小結

實戰中，通常在開發中後期才發現索引別名的妙處。正如文中分析：一、高效索引管理；二、用戶無感知維護數據修改更新。
建議：相同索引別名的物理索引有一致的Mapping和數據結構，以提高檢索效率。
注意：發揮索引別名在檢索方面的優點，在寫入和更新還得使用物理索引。

你的實際Elasticsearch業務場景，有哪些很是基礎但實戰開發很是有用的技術點呢？歡迎留言留下你的思考，讓咱們一塊兒精進！

參考：

https://cambium.consulting/articles/2018/2/22/our-favorite-elasticsearch-features-part-2-index-aliases