海量数据存储问题，求大佬们指导选型

[xyxy]

项目背景：
每天有 300 万的订单数据，一个月 1 亿，新增和更新，表结构很简单，字段也不多
需求：
查询一段时间内的订单数据 基本都是按订单时间查询
查询频次很低，并发很低，公司内部使用
主要是要求存储数据，三个月内的数据查询快一点，三个月外的数据保留好
现在面临问题：
云服务器 mysql ，插入很慢，io 延迟，查询死机

朋友给的方案：
mysql 分区表，按照订单时间每天创建一个分区表，这样单分区表 300 万数据
这个方案存储一年的数据，查询有压力吗？

没用过云数据库，需要上云数据库吗？另外还有朋友建议上分布式云数据库，但我看分布式云数据库主要解决并发问题，我们就是公司自己用，并发很低，查询频次也很低。
大佬们有什么维护成本较低的方案

[zzmark06]

至于上面推荐 parquet 的，最简单也要有 hive ，查也要有 impala/kylin 之类的引擎，不太推荐。greenplum 是个好东西，不过是 pg 体系的，若是你们用 pg 必然优选这个，etl 更简单。
上 es 的，属于屠龙刀杀鸡，查询也存在割裂，需要研发成本，不推荐。
hbase 的，体系很大，若没有已存在的基础设施，也是不推荐。

我提议按日 etl ，有个前提，超过 n 天的数据无法修改。
每次 etl ，要把这个范围内的日期都 drop part 然后重新 insert 。
若你这个 n ，它很大，那每次 etl 运动数据量很恐怖，clickhouse 这个方案也不太行，建议走 cdc 路子