1、別名分類
別名在Elasticsearch中有兩種分類。
1.1 索引別名
官方釋義： 索引別名可以指向一個或多個索引，並且可以在任何需要索引名稱的API中使用。 別名為我們提供了極大的靈活性。它們允許我們執行以下操作：
1）在正在運行的集群上的一個索引和另一個索引之間透明切換；
2）對多個索引進行分組組合（例如，lastthreemonths的索引別名：是過去3個月索引 logstash201903, logstash201904, 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、刪除索引數據只能使用：deletebyquery，相比刪除索引，deletebyquery刪除數據只是邏輯刪除；
2、真正的刪除實際是段合並后的物理刪除分段，也就是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、無法保證查詢的連續性；
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、字段別名實踐一把
星友的問題：
“Aliasdatatype，這個數據類型，在現實工作中的使用場景是什么？看官方文檔，沒有很好理解？”
字段別名原理第一部分已詳細解釋，不再贅述。 這里實踐一把，加深理解。
PUT trips
{
"mappings": {
"_doc": {
"properties": {
"distance": {
"type": "long"
},
"route_length_miles": {
"type": "alias",
"path": "distance"
},
"transit_mode": {
"type": "keyword"
}
}
}
}
}
注意： 當用戶使用檢索時，實際可以使用routelengthmile字段替代distance做檢索，以達到distance一樣的效果。
6、小結
實戰中，一般在開發 中后期才發現索引別名的妙處。正如文中分析：1、高效索引管理；2、用戶無感知維護數據修改更新。
建議：相同索引別名的物理索引有 一致的Mapping和數據結構，以提升檢索效率。
注意：發揮索引別名在檢索方面的優勢，在寫入和更新還得使用 物理索引。
