这是一个创建于 254 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目背景：
每天有 300 万的订单数据，一个月 1 亿，新增和更新，表结构很简单，字段也不多
需求：
查询一段时间内的订单数据 基本都是按订单时间查询
查询频次很低，并发很低，公司内部使用
主要是要求存储数据，三个月内的数据查询快一点，三个月外的数据保留好
现在面临问题：
云服务器 mysql ，插入很慢，io 延迟，查询死机
朋友给的方案：
mysql 分区表，按照订单时间每天创建一个分区表，这样单分区表 300 万数据
这个方案存储一年的数据，查询有压力吗？
没用过云数据库，需要上云数据库吗？另外还有朋友建议上分布式云数据库，但我看分布式云数据库主要解决并发问题，我们就是公司自己用，并发很低，查询频次也很低。
大佬们有什么维护成本较低的方案
每天有 300 万的订单数据，一个月 1 亿，新增和更新，表结构很简单，字段也不多
需求：
查询一段时间内的订单数据 基本都是按订单时间查询
查询频次很低，并发很低，公司内部使用
主要是要求存储数据，三个月内的数据查询快一点，三个月外的数据保留好
现在面临问题：
云服务器 mysql ，插入很慢，io 延迟，查询死机
朋友给的方案：
mysql 分区表，按照订单时间每天创建一个分区表，这样单分区表 300 万数据
这个方案存储一年的数据，查询有压力吗？
没用过云数据库，需要上云数据库吗？另外还有朋友建议上分布式云数据库，但我看分布式云数据库主要解决并发问题，我们就是公司自己用，并发很低，查询频次也很低。
大佬们有什么维护成本较低的方案
41 条回复 • 2024-04-03 16:29:00 +08:00
 |
1
xyxy OP 不要问为什么交给我这么专业的人。。。O(∩_∩)O 哈哈~
|
 |
2
mightybruce 254 天前
订单的数据要求是实时的， 你这个查询看是对内的，属于统计，那么建议增加 OLAP
mysql 除了三个月以外的数据放历史表吧，建历史表，每天执行计划任务将当天的数据放入历史表中，再通过 canal 等 CDC 方案 同步历史数据到 clickhouse 上。 更久的历史表如何在 clickhouse 中，历史表中数据可以删掉。 |
 |
3
me1onsoda 254 天前
分区表提升不了性能，只是方便你管理数据归档
|
 |
4
java123 254 天前
Doris 适合你
|
 |
5
dododada 254 天前
clickhouse ，根据经验，单表 10 亿随便折腾，就是不要 update
|
 |
6
coderxy 254 天前
跑个定时任务每天归档三个月前的数据就行了。 保持单表一直在 1 个亿的数据左右就问题不大。
|
 |
7
SpikeX 254 天前
一个月一亿，查询 3 个月内的就是三亿，MySQL 支撑不了这量啊。你朋友那方案存储没问题，可以写个脚本查 3 个月的量。不行就招人吧
|
 |
8
coderzhangsan 254 天前
订单每天 300 万数据，插入很慢，mysql 就扛不住了？我想了解下你们云服务 mysql 什么架构配置，有没有做主从？置于查询这块，大数据表聚合运算，不是 mysql 的强项，可以单独做冗余方案设计，例如 clickhouse 等等。
|
 |
9
netnr 254 天前 via Android
DuckDB
|
 |
10
flmn 254 天前
直接 parquet 存对象存储上，如果是私有环境，用 minio 。
然后有大把的工具能来查 parquet 文件。 |
 |
12
kuqma98 254 天前
clickhouse 啊，分布式数据库就是解决数据量大的问题
|
 |
13
XyIsMy 254 天前
每天都 300w 的订单数据，那说明业务量很大，直接上云数据库，让公司给钱就行
|
 |
15
weixind 254 天前  1
每天 300w 的订单量，就不要来社区白嫖技术方案了吧。
|
 |
16
oneisall8955 254 天前 via Android 2
每日 300w 订单量，什么平台鸭，想都不敢想，公司架构师什么建议
|
 |
17
YVAN7123 254 天前
直接分表，每天创建一个表
|
 |
18
q11391 254 天前
hbase
|
 |
19
qiyilai 254 天前
选型方向是 mpp 数据库，一个月一亿订单的平台，讲道理不会问这个的
|
 |
20
SbloodyS 254 天前
上 OLAP 引擎，Doris 、CK 都行
|
 |
21
harleyliao 254 天前
建议按月分表， 方便查询和数据清理，记得 修改 mysql 参数, innodb_file_per_table=1 ， 这样单个表会独立使用一个文件存储
|
 |
22
MoYi123 254 天前 1
这么大个公司, 不去大厂挖大佬, 来论坛问我们这些穷哥们?
|
 |
23
dlmy 254 天前
ClickHouse ，公司单表 5 亿多条数据，查询一次 0.9 秒
|
 |
24
UGas2t22Svnlm2K2 254 天前
可以试试 greenplum
|
 |
25
Yinoes 254 天前
可以直接入 doris ，partition 设计好就行；
https://doris.apache.org/zh-CN/docs/get-starting/quick-start doris 版本用 2.0 之后的就行 1.x 版本的会有各种小问题； 语法基本上兼容 mysql |
 |
26
rocliu2020 254 天前
你这个数据量以后会不会随业务增长？是否需要考虑以后数据量增长之后架构能方便扩容？是不是必须得用 MySQL ？服务器相关成本预算有没有限制？这些都不是在这论坛三言两语能说清的。（业务都这么大了，就舍不得请个高级工程师或者架构师做下架构设计？白嫖方案以后出问题了又来论坛寻求解决办法？）
|
 |
27
9c04C5dO01Sw5DNL 254 天前
上 olap
|
 |
28
vincent7245 254 天前
同上 ，用 olap
clickhouse ，doris ，imapala+kudu ，都行，看你喜欢哪个 |
 |
29
angryfish 254 天前
我司用的阿里云 maxcompute ，大数据好用，小数据不好用
|
 |
30
dorothyREN 254 天前
@coderzhangsan 做了主从，插入只会更慢。
|
 |
31
daxin945 254 天前
clickhouse
|
 |
32
lbaob 254 天前
你说的插入很慢是什么级别，插入是批量插入还是每次单条插入？按理 mysql 批量导入 300W 的数据也不会很慢，如果是一次单条的插入还要每次刷盘那就慢了
|
 |
33
chutianyao 254 天前
到我的专业领域了.
我们订单量跟这差不多,如果对查询性能要求不高的话,直接存 es 就完了, 3 个月 1 个索引就行, 做好定期创建索引. 或者可用性要求不高的话,直接上 tidb 也行(但是我们发生过几次故障) 或者 mycat 做分库分表也行(tps 高的话性能优点问题) 或者 mysql 自己做分库分表,超过 3 个月的数据每天进行结转归档 |
 |
34
yjhatfdu2 254 天前
你这量，只要不是要求一次几亿的数据聚合秒级结果，直接 pg+时间列 brin 索引解决了，然后老数据定期归档
|
 |
35
mark2025 254 天前
timescale ?
|
 |
36
rockyliang 254 天前
订单数据插入后会频繁更新不？不频繁的话可以考虑用 clickhouse
|
 |
37
stephenxiaxy 254 天前
clickhouse
|
 |
38
rawburuser 254 天前
上 tidb ，我司的月数据量差不多是你们的一半
|
 |
39
poembre 253 天前
订单一般需要事务支持吧，推荐 mysql 。 假如困惑点在与存储 和写入的话 mysql 分表也可以解决。 另外设定好索引 别说 300W 单表 30 亿 也没压力。
|
 |
40
zzmark06 242 天前 via Android
理智点讲，分两种工况
1. 业务正常读写，能正常跑就单表顶多分区，不建议扯太多。分表增加很多管理压力，而不分表只是 ddl 压力、备份恢复压力。当然前提管住手欠的直接无索引查全表。 2. 有范围聚合性统计操作，这类按惯例，etl 一份到 olap 库，典型目标库 doris/clickhouse ，但这个不要做实时，建议按日，业务侧保证不查当日，或者查询业务上区分当日和非当日。极少有业务无法妥协，不妥协那是人的事不是业务的。 3. 若不能妥协，上游“劳资非要任意查不能拆分”，那就要考虑 cdc 链路，若业务存在 update 则不能选择 clickhouse(细碎麻烦很多，虽然都有解法但太麻烦不适合快速落地)，若业务数据量大(日 300w 不算多，稍微多给点资源就当小量)，doris 配 cdc 合并上也吃不消。至于 cdc 也是有延迟的，分钟级的程度，努努力能做到秒级(十几二十几的程度)，资源消耗究极猛 按日 etl 难度不高，落地很快，配个定时跑下 sql 就能完成入仓。 clickhouse 单机 8c64g 配几块机械盘，足够支撑你这丁丁点数据量(我这单点 ck 每天手机号量级写入) 至于 mysql 插入慢，问题可能多方面。根据描述只能建议先切出 adhoc 查询流量，优化查询体验，没法给你解决写性能问题。 顺带一提，mysql 单表亿级别，也不是什么大奸大恶，必须分表。理智点做取舍。个人信奉“分库分表为数据治理最后方案” |
|
41
zzmark06 242 天前 via Android
至于上面推荐 parquet 的，最简单也要有 hive ，查也要有 impala/kylin 之类的引擎，不太推荐。greenplum 是个好东西，不过是 pg 体系的，若是你们用 pg 必然优选这个，etl 更简单。
上 es 的，属于屠龙刀杀鸡，查询也存在割裂，需要研发成本，不推荐。 hbase 的，体系很大，若没有已存在的基础设施，也是不推荐。 我提议按日 etl ，有个前提，超过 n 天的数据无法修改。 每次 etl ，要把这个范围内的日期都 drop part 然后重新 insert 。 若你这个 n ，它很大，那每次 etl 运动数据量很恐怖，clickhouse 这个方案也不太行，建议走 cdc 路子 |
Select Language