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

[xyxy]

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

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

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

[harleyliao]

建议按月分表， 方便查询和数据清理，记得 修改 mysql 参数, innodb_file_per_table=1 ， 这样单个表会独立使用一个文件存储

[MoYi123]

这么大个公司, 不去大厂挖大佬, 来论坛问我们这些穷哥们?

[dlmy]

ClickHouse ，公司单表 5 亿多条数据，查询一次 0.9 秒

[UGas2t22Svnlm2K2]

可以试试 greenplum

[Yinoes]

可以直接入 doris ，partition 设计好就行；
https://doris.apache.org/zh-CN/docs/get-starting/quick-start


doris 版本用 2.0 之后的就行 1.x 版本的会有各种小问题；
语法基本上兼容 mysql

[rocliu2020]

你这个数据量以后会不会随业务增长？是否需要考虑以后数据量增长之后架构能方便扩容？是不是必须得用 MySQL ？服务器相关成本预算有没有限制？这些都不是在这论坛三言两语能说清的。（业务都这么大了，就舍不得请个高级工程师或者架构师做下架构设计？白嫖方案以后出问题了又来论坛寻求解决办法？）

[9c04C5dO01Sw5DNL]

上 olap

[vincent7245]

同上 ，用 olap

clickhouse ，doris ，imapala+kudu ，都行，看你喜欢哪个

[angryfish]

我司用的阿里云 maxcompute ，大数据好用，小数据不好用

[dorothyREN]

@coderzhangsan 做了主从，插入只会更慢。

[daxin945]

clickhouse

[lbaob]

你说的插入很慢是什么级别，插入是批量插入还是每次单条插入？按理 mysql 批量导入 300W 的数据也不会很慢，如果是一次单条的插入还要每次刷盘那就慢了

[chutianyao]

到我的专业领域了.

我们订单量跟这差不多,如果对查询性能要求不高的话,直接存 es 就完了, 3 个月 1 个索引就行, 做好定期创建索引.
或者可用性要求不高的话,直接上 tidb 也行(但是我们发生过几次故障)
或者 mycat 做分库分表也行(tps 高的话性能优点问题)
或者 mysql 自己做分库分表,超过 3 个月的数据每天进行结转归档

[yjhatfdu2]

你这量，只要不是要求一次几亿的数据聚合秒级结果，直接 pg+时间列 brin 索引解决了，然后老数据定期归档

[mark2025]

timescale ?

[rockyliang]

订单数据插入后会频繁更新不？不频繁的话可以考虑用 clickhouse

[stephenxiaxy]

clickhouse

[rawburuser]

上 tidb ，我司的月数据量差不多是你们的一半

[poembre]

订单一般需要事务支持吧，推荐 mysql 。 假如困惑点在与存储 和写入的话 mysql 分表也可以解决。 另外设定好索引 别说 300W 单表 30 亿 也没压力。

[zzmark06]

理智点讲，分两种工况

1. 业务正常读写，能正常跑就单表顶多分区，不建议扯太多。分表增加很多管理压力，而不分表只是 ddl 压力、备份恢复压力。当然前提管住手欠的直接无索引查全表。
2. 有范围聚合性统计操作，这类按惯例，etl 一份到 olap 库，典型目标库 doris/clickhouse ，但这个不要做实时，建议按日，业务侧保证不查当日，或者查询业务上区分当日和非当日。极少有业务无法妥协，不妥协那是人的事不是业务的。
3. 若不能妥协，上游“劳资非要任意查不能拆分”，那就要考虑 cdc 链路，若业务存在 update 则不能选择 clickhouse(细碎麻烦很多，虽然都有解法但太麻烦不适合快速落地)，若业务数据量大(日 300w 不算多，稍微多给点资源就当小量)，doris 配 cdc 合并上也吃不消。至于 cdc 也是有延迟的，分钟级的程度，努努力能做到秒级(十几二十几的程度)，资源消耗究极猛

按日 etl 难度不高，落地很快，配个定时跑下 sql 就能完成入仓。

clickhouse 单机 8c64g 配几块机械盘，足够支撑你这丁丁点数据量(我这单点 ck 每天手机号量级写入)

至于 mysql 插入慢，问题可能多方面。根据描述只能建议先切出 adhoc 查询流量，优化查询体验，没法给你解决写性能问题。

顺带一提，mysql 单表亿级别，也不是什么大奸大恶，必须分表。理智点做取舍。个人信奉“分库分表为数据治理最后方案”