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

[xyxy]

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

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

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

[xyxy]

不要问为什么交给我这么专业的人。。。O(∩_∩)O 哈哈~

[mightybruce]

订单的数据要求是实时的， 你这个查询看是对内的，属于统计，那么建议增加 OLAP

mysql 除了三个月以外的数据放历史表吧，建历史表，每天执行计划任务将当天的数据放入历史表中，再通过 canal 等 CDC 方案 同步历史数据到 clickhouse 上。
更久的历史表如何在 clickhouse 中，历史表中数据可以删掉。

[me1onsoda]

分区表提升不了性能，只是方便你管理数据归档

[java123]

Doris 适合你

[dododada]

clickhouse ，根据经验，单表 10 亿随便折腾，就是不要 update

[coderxy]

跑个定时任务每天归档三个月前的数据就行了。 保持单表一直在 1 个亿的数据左右就问题不大。

[SpikeX]

一个月一亿，查询 3 个月内的就是三亿，MySQL 支撑不了这量啊。你朋友那方案存储没问题，可以写个脚本查 3 个月的量。不行就招人吧

[coderzhangsan]

订单每天 300 万数据，插入很慢，mysql 就扛不住了？我想了解下你们云服务 mysql 什么架构配置，有没有做主从？置于查询这块，大数据表聚合运算，不是 mysql 的强项，可以单独做冗余方案设计，例如 clickhouse 等等。

[netnr]

DuckDB

[flmn]

直接 parquet 存对象存储上，如果是私有环境，用 minio 。

然后有大把的工具能来查 parquet 文件。

[xyxy]

@me1onsoda 分区表后 单表不就 300 万数据了吗 查询性能就快了吧

[kuqma98]

clickhouse 啊，分布式数据库就是解决数据量大的问题

[XyIsMy]

每天都 300w 的订单数据，那说明业务量很大，直接上云数据库，让公司给钱就行

[me1onsoda]

@xyxy 一样的，单表还是那么多，不然分表就成傻 x 方案了。。

[weixind]

每天 300w 的订单量，就不要来社区白嫖技术方案了吧。

[oneisall8955]

每日 300w 订单量，什么平台鸭，想都不敢想，公司架构师什么建议

[YVAN7123]

直接分表，每天创建一个表

[q11391]

hbase

[qiyilai]

选型方向是 mpp 数据库，一个月一亿订单的平台，讲道理不会问这个的

[SbloodyS]

上 OLAP 引擎，Doris 、CK 都行