今天在想一个问题，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
赞同来自: