乾貨 | Elasticsearch基礎但非常有用的功能之一：別名

0、題記

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

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

1、別名分類

別名在Elasticsearch中有兩種分類。

1.1 索引別名。

官方釋義：
索引別名可以指向一個或多個索引，並且可以在任何需要索引名稱的API中使用。
別名爲我們提供了極大的靈活性。它們允許我們執行以下操作：
1）在正在運行的集羣上的一個索引和另一個索引之間透明切換；
2）對多個索引進行分組組合（例如，last_three_months的索引別名：是過去3個月索引logstash_201903, logstash_201904, logstash_201905的組合）；
3）在索引中的文檔子集上創建“視圖”（結合業務場景，會提升檢索效率）。

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

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

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

1.2 字段別名

在Elasticsearch Mapping定義的6.4+版本纔有的字段類型。
通俗解釋：
試想一下有一種業務場景。比如在實際的業務開發中：需要對Facebook、twitter行採集,採集入庫的是兩個業務團隊。他們對content，分別使用了兩個字段。其中一個是，content。另外一個是cont。
這時候存儲到elasticsearch會有兩個字段。這樣如果我們在檢索、寫業務代碼的時候，是不是要寫兩個不同的字段來處理呢？
如果有可能寫成一個字段，代碼方面就很避開業務耦合，很方便了。
我認爲這是字段別名的由來。

2、索引別名實踐

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、索引別名的好處

3.1 大數據量的管理

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

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

推薦閱讀：https://gitbook.cn/books/5c52c6923417565017a61ce0/index.html

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

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

3.2 用戶無感知的重建索引

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

1）ik_smart改成ik_max_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、無法保證查詢的連續性；
2、無法保證線上業務查詢的可靠性（需要告知用戶，業務中斷一段時間）。

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

問題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" } }
            }
        }
    ]
}

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

5、字段別名實踐一把

星友的問題：“Alias datatype，這個數據類型，在現實工作中的使用場景是什麼？看官方文檔，沒有很好理解？”

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

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

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

6、小結

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

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

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

銘毅天下——Elasticsearch基礎、進階、實戰第一公衆號