[Feature request] 未来是否支持热/冷数据分布存储在SSD和机械硬盘上,以节省存储成本

### Search before asking

- [X] I searched in the [issues](https://github.com/apache/iotdb/issues) and found nothing similar.

### Motivation

比如将30天内的数据当做热数据，30天之前的当做冷数据

如下：发现如果全部使用SSD存储的话成本太高了，目前的方案是需要自己写定时任务将30天之前的数据移动到安装在机械硬盘的系统上，当查询60天内的数据时，比较割裂。

按照1万+点位每秒上次一次数据作为参考

24 * 60 * 60 * 10000 = 864000000 条/天 = 8.64亿条数据/天

按照每条数据1KB计算，计划数据保存1年时间
每个数据点大小: 1KB (千字节)
每秒的数据量: 1 KB × 10,000 = 10,000 KB
每分钟的数据量: 10,000 KB × 60 秒 = 600,000 KB
每小时的数据量: 600,000 KB × 60 分钟 = 36,000,000 KB
每天的数据量: 36,000,000 KB × 24 小时 = 864,000,000 KB
每年的数据量: 864,000,000 KB × 365 天 = 315,360,000,000 KB
将KB转换为TB：315,360,000,000 / 1024 /1024 / 1024 = 294TB(约等)
因此，为了存储一年的数据，大约需要300TB的空间（考虑到实际存储需求，可能还需要额外的空间来存储索引、元数据等）。这是理论上的估计，实际应用中可能还需要考虑数据压缩等因素。如果数据经过压缩或者其他优化存储技术处理，实际所需的空间可能会少一些。

### Solution

目前的方案是需要自己写定时任务将30天之前的数据移动到安装在机械硬盘的系统上，当查询60天内的数据时，比较割裂。

### Alternatives

1、官方是否有自动迁移冷数据方案/计划，省的定时迁移数据
2、期望在一个系统上查询跨热/冷数据做聚合操作

### Are you willing to submit a PR?

- [ ] I'm willing to submit a PR!

No se nombran archivos, pruebas ni puntos de entrada. Empieza revisando cómo IoTDB almacena y consulta actualmente los datos, y después aclara la política prevista de migración automática y el comportamiento de las consultas entre distintos almacenamientos. Como resultado final, debería incluirse un diseño acordado para el almacenamiento hot y cold, la migración, la retención y las consultas que abarquen ambos medios.

Escrito por el modelo de indexación a partir del texto del issue.