原文發(fā)表于 2017-04-13個(gè)人博客
大家在使用 Elasticsearch 管理時(shí)序數(shù)據(jù)（比如 日志事件）時(shí)經(jīng)常習(xí)慣于將每一天的數(shù)據(jù)作為一個(gè) Index旬渠。根據(jù)日志事件的時(shí)間戳可以產(chǎn)生最近一天的新索引蛮艰，新Index的定義可以事先使用 index 模板.
這個(gè)是易懂和易于實(shí)現(xiàn)的形式顶考，但隱藏了索引管理的一些復(fù)雜性，比如：
- 要實(shí)現(xiàn)高的數(shù)據(jù)獲取率霞捡，您希望活躍索引的分片應(yīng)該分布到盡量多的節(jié)點(diǎn)上。
- 為了搜索優(yōu)化和低的資源消耗，您希望盡可能少的分片吱雏，但不要那么大的碎片，以防變得笨重瘾境。
- 每一天一個(gè)索引使得很容易過期舊數(shù)據(jù)歧杏，但是一天你需要幾個(gè)分片呢？
- 每天都是一樣的嗎迷守？還是有可能某一天產(chǎn)生太多分片犬绒，第二天可能又太少？
在這篇博文中兑凿，我將介紹新的Rollover Pattern和支持它的API凯力，這是一種更簡(jiǎn)單，更有效的管理基于時(shí)間的索引的方式急膀。
Rollover Pattern
滾動(dòng)模式的工作原理如下：
- 有一個(gè)索引別名沮协，它指向活躍索引。
- 另一個(gè)別名指向活躍和非活躍索引卓嫂，并用于搜索慷暂。
- 活躍索引可以具有與您的熱點(diǎn)節(jié)點(diǎn)一樣多的分片，以利用所有昂貴硬件的索引資源晨雳。
- 當(dāng)活躍索引太滿或太舊時(shí)行瑞，它將滾動(dòng) ：創(chuàng)建一個(gè)新索引，索引別名從舊索引到原始索引餐禁。
- 舊的索引被移動(dòng)到一個(gè)冷節(jié)點(diǎn)血久，并且被縮小到一個(gè)分片，這也可以被強(qiáng)制合并和壓縮帮非。
入門
假設(shè)我們有一個(gè)具有10個(gè) 熱節(jié)點(diǎn)和 1個(gè)冷節(jié)點(diǎn)（注：冷熱是通過設(shè)置機(jī)器實(shí)例的屬性區(qū)分的）集群氧吐。 理想情況下，活躍索引（接收所有寫操作的索引）應(yīng)該在每個(gè)熱節(jié)點(diǎn)上都有一個(gè)分片末盔，以便將索引負(fù)載分解成盡可能多的機(jī)器上筑舅。
我們希望每個(gè)主分片的有一個(gè)副本，以確保我們可以容忍某個(gè)節(jié)點(diǎn)的掛掉陨舱，而數(shù)據(jù)不丟翠拣。 這意味著我們的活躍索引應(yīng)該有5個(gè)主分片，共提供10個(gè)分片（每個(gè)熱節(jié)點(diǎn)一個(gè)）游盲。 我們還可以使用10個(gè)主分片（共20個(gè)分片误墓，包括副本）蛮粮，每個(gè)節(jié)點(diǎn)上有兩個(gè)分片。
首先谜慌，為活躍索引創(chuàng)建一個(gè)索引模板 ：
PUT _template/active-logs
{
"template": "active-logs-*",
"settings": {
"number_of_shards": 5,
"number_of_replicas": 1,
"routing.allocation.include.box_type": "hot",
"routing.allocation.total_shards_per_node": 2
},
"aliases": {
"active-logs": {},
"search-logs": {}
}
}
由此模板創(chuàng)建的索引將分配給帶有 "box_type: hot" 標(biāo)記的節(jié)點(diǎn)然想，并且 total_shards_per_node 設(shè)置將有助于確保分片盡可能擴(kuò)展到盡可能多的hot節(jié)點(diǎn)。 我把它設(shè)置為2而不是1 畦娄，所以如果一個(gè)節(jié)點(diǎn)失敗又沾，我們?nèi)匀豢梢苑峙渌槠?/p>
我們將使用 active-logs 索引別名映射當(dāng)前的活躍索引，并使用 search-logs 別名來搜索所有日志索引熙卡。
以下是我們的非活躍索引將使用的模板：
PUT _template/inactive-logs
{
"template": "inactive-logs-*",
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0,
"routing.allocation.include.box_type": "cold",
"codec": "best_compression"
}
}
歸檔索引應(yīng)分配給cold節(jié)點(diǎn)杖刷，并應(yīng)使用deflate壓縮來節(jié)省空間。 我會(huì)解釋為什么我稍后將replicas設(shè)置為0 驳癌。
現(xiàn)在我們可以創(chuàng)建第一個(gè)活躍索引：
PUT active-logs-1
名稱中 -1 的模式會(huì)被 rollover API 識(shí)別為計(jì)數(shù)器（能夠進(jìn)行累加）滑燃。
灌入數(shù)據(jù)
當(dāng)我們創(chuàng)建了 active-logs-1 索引時(shí)，我們還創(chuàng)建了 active-logs 別名颓鲜。 從此刻開始表窘，我們應(yīng)該僅使用別名進(jìn)行索引，我們輸入的文檔將被發(fā)送到當(dāng)前的活躍索引：
POST active-logs/log/_bulk
{ "create": {}}
{ "text": "Some log message", "@timestamp": "2016-07-01T01:00:00Z" }
{ "create": {}}
{ "text": "Some log message", "@timestamp": "2016-07-02T01:00:00Z" }
{ "create": {}}
{ "text": "Some log message", "@timestamp": "2016-07-03T01:00:00Z" }
{ "create": {}}
{ "text": "Some log message", "@timestamp": "2016-07-04T01:00:00Z" }
{ "create": {}}
{ "text": "Some log message", "@timestamp": "2016-07-05T01:00:00Z" }
Rolling over 索引
在某個(gè)階段甜滨，活躍索引會(huì)變得太大或太老乐严，您將需要用新的空索引替換它。 Rollover API 允許您指定索引可以有多大或有多老衣摩。
多大算太大了昂验？這取決于你所擁有的硬件，你執(zhí)行的搜索類型艾扮，你期待的性能既琴，你愿意等待分片恢復(fù)的時(shí)間等等。在實(shí)踐中泡嘴，你可以嘗試不同的分片大小甫恩，看看什么對(duì)你有用。剛開始時(shí)酌予，選擇一些任意數(shù)字磺箕，如1億或10億。 您可以根據(jù)搜索性能抛虫，數(shù)據(jù)保留期和可用空間來上下調(diào)整此數(shù)字松靡。
單個(gè)分片可以包含的文檔數(shù)量有限制：2,147,483,519。 如果您計(jì)劃將活躍索引收縮到單個(gè)分片莱褒，則您的活躍索引中的文檔必須少于21億。 如果您有更多的文檔涎劈，則可以將索引縮小到多個(gè)分片广凸，只要目標(biāo)數(shù)量的分片是原始的因數(shù)阅茶，例如 6→3 或 6→2。
按時(shí)間多久來滾動(dòng)索引可能很方便谅海，因?yàn)樗试S您按小時(shí)脸哀，天，周等方式存日志扭吁，但是通常根據(jù)索引中的文檔數(shù)量來進(jìn)行 rollover 更為有效撞蜂。 基于尺寸的翻轉(zhuǎn)的一個(gè)好處是，所有的分片都具有大致相同的重量侥袜，這使得它們更容易平衡蝌诡。
Rollover API 將由 cron job 定期調(diào)用，以檢查 max_docs或 max_age 約束是否已被打破(即滿足滾動(dòng)條件)枫吧。 一旦至少有一個(gè)約束被打破浦旱，索引就會(huì)滾動(dòng)。 由于我們僅在上述示例中模擬了5個(gè)文檔九杂，因此我們將指定一個(gè) max_docs 值為 5 颁湖，（為了完整）， max_age 為一周：
POST active-logs/_rollover
{
"conditions": {
"max_age": "7d",
"max_docs": 5
}
}
該請(qǐng)求告訴Elasticsearch翻轉(zhuǎn)active-logs別名指向的索引例隆，如果該索引至少在七天前創(chuàng)建甥捺，或至少包含5個(gè)文檔。 響應(yīng)如下所示：
{
"old_index": "active-logs-1",
"new_index": "active-logs-2",
"rolled_over": true,
"dry_run": false,
"conditions": {
"[max_docs: 5]": true,
"[max_age: 7d]": false
}
}
由于 max_docs: 5 約束被滿足镀层，所以 active-logs-1 索引已經(jīng)被滾動(dòng)到 active-logs-2 索引镰禾。 這意味著根據(jù) active-logs 模板創(chuàng)建了一個(gè)名為 active-logs-2 的新索引，并將 active-logs 別名從 active-logs-1 切換到 active-logs-2 鹿响。
順便說一下羡微，如果要覆蓋索引模板中的任何值，例如 settings或 mappings 惶我，您可以像使用 create index API 一樣將它們傳遞到 _rollover 請(qǐng)求正文妈倔。
為什么不支持 max_size 約束？
鑒于目的是生成均勻大小的分片绸贡，為什么除 max_docs 之外我們不支持 max_size 約束盯蝴？ 答案是，碎片大小是不太可靠的方式听怕，因?yàn)檎谶M(jìn)行的合并捧挺，可能會(huì)使分片大小產(chǎn)生明顯的臨時(shí)增長(zhǎng)，一旦合并完成又會(huì)消失尿瞭。 5個(gè)主碎片闽烙，每個(gè)在合并到一個(gè) 5GB 分片的過程中，會(huì)臨時(shí)將索引大小提高25GB！相比之下黑竞，文檔數(shù)量則是可預(yù)測(cè)地增長(zhǎng)捕发。
參考翻譯文章：https://www.elastic.co/blog/managing-time-based-indices-efficiently
