今天在想一个问题,es适合存储多长时间的数据?看es的设计,感觉多久都行,很容易方便水平扩展,存储不是问题。
我的问题:es的定位是搜索,一般存在es的数据,也都是基于时间序列的,一般只会用最近1个月、3个月、半年,最多也就1年的查询、统计。那么,比较久远的数据是不是应该压缩存入hdfs?这样的话才节省存储空间,而且也不浪费es的性能?
比如:如果我的es存了3年的数据,那么每次我使用query查询的时候、其实我只查最近1个月的数据,请求都要转发到每个分片上,包括了去年、前年的分片(索引),岂不是浪费感情?
如果想避免这个问题,那么在我搜索的时候,在url里配置的索引模式,要明确索引范围,比如我数据是按月索引的,log-2019-01、log-2019-02、log-2019-03依次类推,如果我只看1月、2月的时间范围内搜索,那么我的查询的索引模式应该是列出这两个索引,而不能用通用的索引模式如log-2019*,否则03-12的索引也会去处理我的请求,其实完全没必要。
谢谢各位!
我的问题:es的定位是搜索,一般存在es的数据,也都是基于时间序列的,一般只会用最近1个月、3个月、半年,最多也就1年的查询、统计。那么,比较久远的数据是不是应该压缩存入hdfs?这样的话才节省存储空间,而且也不浪费es的性能?
比如:如果我的es存了3年的数据,那么每次我使用query查询的时候、其实我只查最近1个月的数据,请求都要转发到每个分片上,包括了去年、前年的分片(索引),岂不是浪费感情?
如果想避免这个问题,那么在我搜索的时候,在url里配置的索引模式,要明确索引范围,比如我数据是按月索引的,log-2019-01、log-2019-02、log-2019-03依次类推,如果我只看1月、2月的时间范围内搜索,那么我的查询的索引模式应该是列出这两个索引,而不能用通用的索引模式如log-2019*,否则03-12的索引也会去处理我的请求,其实完全没必要。
谢谢各位!
3 个回复
匿名用户
赞同来自:
还是按照业务进行拆分,按照数据拆分。
你这种情况,可以按照一个月一个集群的方式进行扩展。不要用一个超大的集群。
byx313 - BLOG:https://www.jianshu.com/u/43fd06f9589c
赞同来自:
对的。cluster metadata里面会存储对应shard存在的node,就只会把请求发送到对应的node上,避免集群所有节点都接受到请求。
2、存储历史数据,可以使用数据的冷热架构。
caizhongao
赞同来自: