大家早上好!
业务场景:
OLAP(后续会有下钻的需求;用kylin的话,数仓改动太大);有大范围日期查询、聚合分组、排序
现有数据量:
现有3年数据,预估7T(含1副本)
按数据增长量来计算,未来可能会到10T+
集群节点情况:
es版本 --> 5.6
master --> (独立)3节点
client. --> (独立)3节点
data. --> (独立)10节点
现有老集群的索引情况:
按月划分 --> 每个索引不大:几百兆 、几十GB
基于多Type的天索引(所有天的数据在一个索引里面) --> 索引有10~50GB、100~300GB、600GB+
因为有“刷(历史)数据”的问题,如果将小索引合并,那么更新某几天、某个月的数据,效率不高,同时前端查询会受短暂影响
所以,我想全部做“独立索引”,对于这些小的索引,分片数建1~3不等。如果有【刷数据】的需求,就【新建索引】,通过别名切换。
但这样,集群的小分片量还是会比较多
业务场景:
OLAP(后续会有下钻的需求;用kylin的话,数仓改动太大);有大范围日期查询、聚合分组、排序
现有数据量:
现有3年数据,预估7T(含1副本)
按数据增长量来计算,未来可能会到10T+
集群节点情况:
es版本 --> 5.6
master --> (独立)3节点
client. --> (独立)3节点
data. --> (独立)10节点
现有老集群的索引情况:
按月划分 --> 每个索引不大:几百兆 、几十GB
基于多Type的天索引(所有天的数据在一个索引里面) --> 索引有10~50GB、100~300GB、600GB+
因为有“刷(历史)数据”的问题,如果将小索引合并,那么更新某几天、某个月的数据,效率不高,同时前端查询会受短暂影响
所以,我想全部做“独立索引”,对于这些小的索引,分片数建1~3不等。如果有【刷数据】的需求,就【新建索引】,通过别名切换。
但这样,集群的小分片量还是会比较多
1 个回复
zqc0512 - andy zhou
赞同来自:
5的话需要用curator.