1
xyxy OP 不要问为什么交给我这么专业的人。。。O(∩_∩)O 哈哈~
|
2
mightybruce 277 天前
订单的数据要求是实时的, 你这个查询看是对内的,属于统计,那么建议增加 OLAP
mysql 除了三个月以外的数据放历史表吧,建历史表,每天执行计划任务将当天的数据放入历史表中,再通过 canal 等 CDC 方案 同步历史数据到 clickhouse 上。 更久的历史表如何在 clickhouse 中,历史表中数据可以删掉。 |
3
me1onsoda 277 天前
分区表提升不了性能,只是方便你管理数据归档
|
4
java123 277 天前
Doris 适合你
|
5
dododada 277 天前
clickhouse ,根据经验,单表 10 亿随便折腾,就是不要 update
|
6
coderxy 277 天前
跑个定时任务每天归档三个月前的数据就行了。 保持单表一直在 1 个亿的数据左右就问题不大。
|
7
SpikeX 277 天前
一个月一亿,查询 3 个月内的就是三亿,MySQL 支撑不了这量啊。你朋友那方案存储没问题,可以写个脚本查 3 个月的量。不行就招人吧
|
8
coderzhangsan 277 天前
订单每天 300 万数据,插入很慢,mysql 就扛不住了?我想了解下你们云服务 mysql 什么架构配置,有没有做主从?置于查询这块,大数据表聚合运算,不是 mysql 的强项,可以单独做冗余方案设计,例如 clickhouse 等等。
|
9
netnr 277 天前 via Android
DuckDB
|
10
flmn 276 天前
直接 parquet 存对象存储上,如果是私有环境,用 minio 。
然后有大把的工具能来查 parquet 文件。 |
12
kuqma98 276 天前
clickhouse 啊,分布式数据库就是解决数据量大的问题
|
13
XyIsMy 276 天前
每天都 300w 的订单数据,那说明业务量很大,直接上云数据库,让公司给钱就行
|
15
weixind 276 天前 1
每天 300w 的订单量,就不要来社区白嫖技术方案了吧。
|
16
oneisall8955 276 天前 via Android 2
每日 300w 订单量,什么平台鸭,想都不敢想,公司架构师什么建议
|
17
YVAN7123 276 天前
直接分表,每天创建一个表
|
18
q11391 276 天前
hbase
|
19
qiyilai 276 天前
选型方向是 mpp 数据库,一个月一亿订单的平台,讲道理不会问这个的
|
20
SbloodyS 276 天前
上 OLAP 引擎,Doris 、CK 都行
|
21
harleyliao 276 天前
建议按月分表, 方便查询和数据清理,记得 修改 mysql 参数, innodb_file_per_table=1 , 这样单个表会独立使用一个文件存储
|
22
MoYi123 276 天前 1
这么大个公司, 不去大厂挖大佬, 来论坛问我们这些穷哥们?
|
23
dlmy 276 天前
ClickHouse ,公司单表 5 亿多条数据,查询一次 0.9 秒
|
24
UGas2t22Svnlm2K2 276 天前
可以试试 greenplum
|
25
Yinoes 276 天前
可以直接入 doris ,partition 设计好就行;
https://doris.apache.org/zh-CN/docs/get-starting/quick-start doris 版本用 2.0 之后的就行 1.x 版本的会有各种小问题; 语法基本上兼容 mysql |
26
rocliu2020 276 天前
你这个数据量以后会不会随业务增长?是否需要考虑以后数据量增长之后架构能方便扩容?是不是必须得用 MySQL ?服务器相关成本预算有没有限制?这些都不是在这论坛三言两语能说清的。(业务都这么大了,就舍不得请个高级工程师或者架构师做下架构设计?白嫖方案以后出问题了又来论坛寻求解决办法?)
|
27
9c04C5dO01Sw5DNL 276 天前
上 olap
|
28
vincent7245 276 天前
同上 ,用 olap
clickhouse ,doris ,imapala+kudu ,都行,看你喜欢哪个 |
29
angryfish 276 天前
我司用的阿里云 maxcompute ,大数据好用,小数据不好用
|
30
dorothyREN 276 天前
@coderzhangsan 做了主从,插入只会更慢。
|
31
daxin945 276 天前
clickhouse
|
32
lbaob 276 天前
你说的插入很慢是什么级别,插入是批量插入还是每次单条插入?按理 mysql 批量导入 300W 的数据也不会很慢,如果是一次单条的插入还要每次刷盘那就慢了
|
33
chutianyao 276 天前
到我的专业领域了.
我们订单量跟这差不多,如果对查询性能要求不高的话,直接存 es 就完了, 3 个月 1 个索引就行, 做好定期创建索引. 或者可用性要求不高的话,直接上 tidb 也行(但是我们发生过几次故障) 或者 mycat 做分库分表也行(tps 高的话性能优点问题) 或者 mysql 自己做分库分表,超过 3 个月的数据每天进行结转归档 |
34
yjhatfdu2 276 天前
你这量,只要不是要求一次几亿的数据聚合秒级结果,直接 pg+时间列 brin 索引解决了,然后老数据定期归档
|
35
mark2025 276 天前
timescale ?
|
36
rockyliang 276 天前
订单数据插入后会频繁更新不?不频繁的话可以考虑用 clickhouse
|
37
stephenxiaxy 276 天前
clickhouse
|
38
rawburuser 276 天前
上 tidb ,我司的月数据量差不多是你们的一半
|
39
poembre 276 天前
订单一般需要事务支持吧,推荐 mysql 。 假如困惑点在与存储 和写入的话 mysql 分表也可以解决。 另外设定好索引 别说 300W 单表 30 亿 也没压力。
|
40
zzmark06 264 天前 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 264 天前 via Android
至于上面推荐 parquet 的,最简单也要有 hive ,查也要有 impala/kylin 之类的引擎,不太推荐。greenplum 是个好东西,不过是 pg 体系的,若是你们用 pg 必然优选这个,etl 更简单。
上 es 的,属于屠龙刀杀鸡,查询也存在割裂,需要研发成本,不推荐。 hbase 的,体系很大,若没有已存在的基础设施,也是不推荐。 我提议按日 etl ,有个前提,超过 n 天的数据无法修改。 每次 etl ,要把这个范围内的日期都 drop part 然后重新 insert 。 若你这个 n ,它很大,那每次 etl 运动数据量很恐怖,clickhouse 这个方案也不太行,建议走 cdc 路子 |