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

[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 都行

[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 ，都行，看你喜欢哪个

[GBdG6clg2Jy17ua5]

我司用的阿里云 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 单表亿级别，也不是什么大奸大恶，必须分表。理智点做取舍。个人信奉“分库分表为数据治理最后方案”

[zzmark06]

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

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