ES：PB級別的大索引如何設計

一、單個大索引的缺陷

如果每天億萬+的實時增量數據呢，基於以下幾點原因，單個索引是無法滿足要求的；

1、存儲大小限制維度

單個分片（Shard）實際是 Lucene 的索引，單分片能存儲的最大文檔數是：2,147,483,519 (= Integer.MAX_VALUE - 128)。如下命令能查看全部索引的分隔分片的文檔大小：

GET _cat/shards
app_index                       2 p STARTED      9443   2.8mb 127.0.0.1 Hk9wFwU
app_index                       2 r UNASSIGNED                          
app_index                       3 p STARTED      9462   2.7mb 127.0.0.1 Hk9wFwU
app_index                       3 r UNASSIGNED                          
app_index                       4 p STARTED      9520   3.5mb 127.0.0.1 Hk9wFwU
app_index                       4 r UNASSIGNED                          
app_index                       1 p STARTED      9453   2.4mb 127.0.0.1 Hk9wFwU
app_index                       1 r UNASSIGNED                          
app_index                       0 p STARTED      9365   2.3mb 127.0.0.1 Hk9wFwU
app_index                       0 r UNASSIGNED

2、性能維度

當然一個索引很大的話，數據寫入和查詢性能都會變差，而高效檢索體現在：基於日期的檢索可以直接檢索對應日期的索引，無形中縮減了很大的數據規模。

比如檢索：“2019-02-01”號的數據，之前的檢索會是在一個月甚至更大體量的索引中進行，現在直接檢索"index_2019-02-01"的索引,效率提升好幾倍。

3、風險維度

一旦一個大索引出現故障，相關的數據都會受到影響。而分成滾動索引的話，相當於做了物理隔離。

 

二、具體實現

綜上，結合實踐經驗，大索引設計建議：使用模板+Rollover+Curator動態創建索引。動態索引使用效果如下：

index_2019-01-01-000001
index_2019-01-02-000002
index_2019-01-03-000003
index_2019-01-04-000004
index_2019-01-05-000005

1、使用模板統一配置索引；

2、使用 Rollver 增量管理索引；

目的：按照日期、文檔數、文檔存儲大小三個維度進行更新索引。使用舉例：

POST /logs_write/_rollover 
{
  "conditions": {
    "max_age":   "7d",
    "max_docs":  1000,
    "max_size":  "5gb"
  }
}

3、索引增量更新

1.索引更新的時機是：當原始索引滿足設置條件的三個中的一個的時候，就會更新為新的索引。為保證業務的全索引檢索，一般采用別名機制；

2.在索引模板設計階段，模板定義一個全局別名：用途是全局檢索，如圖所示的別名：indexall。每次更新到新的索引后，新索引指向一個用於實時新數據寫入的別名，如圖所示的別名：indexlatest。同時將舊索引的別名 index_latest 移除。

別名刪除和新增操作舉例：

POST /_aliases
{
  "actions" : [
      { "remove" : { "index" : "index_2019-01-01-000001", "alias" : "index_latest" } },
      { "add" : { "index" : "index_2019-01-02-000002", "alias" : "index_latest" } }
  ]
}