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

ES：PB级别的大索引如何设计

猜你喜欢