想请教大家一个 SQL 大表的问题。
需求为: 使用 SQL 存储大约 12 亿的 time series 数据, ttl 为 30 天。Schema 为 (group_id, sub_group_id, timestamp, value)
。
绝大多数查询是做一些 aggregation , 比如 sum(value) group by sub_group_id
。所有查询保证都在同一 group id
内。
我能想到的一些做法:
group_id
分成多个 server。timestamp
(以天为单位), group_id
分表。这样可以按天 drop table 来删除过期数据。(group_id, sub_group_id, timestamp)
创建 index。问题:
使用分表会降低 performance 吗?(从我的 test 结果看好像是的。)
MySQL or PostgreSQL?
PostgreSQL 的好处是:
MySQL 好处:
问题很多,先感谢大家的宝贵时间!
1
widewing 2018-01-13 09:03:31 +08:00 via Android 1
为啥不用 tsdb?
|
2
gouchaoer 2018-01-13 09:22:06 +08:00 via Android 1
你这个每行字段很小只有几个字节,所以几亿数据也就几 g 或者几十 g 不算多,分表对查询没提高的吧,因为你查询用了索引,只是插入速度提高了。。。。总结,可以按照日期分表每张表控制在千万级别,保证插入速度,查询的时候分表查
|
3
dangyuluo 2018-01-13 09:37:34 +08:00 1
试试 pi 数据库吧
|
4
feverzsj 2018-01-13 13:22:03 +08:00 1
你才这么点数据,至于折腾成这样吗,随便什么数据库,一张表就足够了
|
5
rrfeng 2018-01-13 13:46:17 +08:00 via Android 1
如果要考虑以后接入更多的话,直接上 tsdb
如果以后也只有 12 亿的话,MySQL 还是什么 SQL 区别不大,针对性的做优化就好了 |
6
cevincheung 2018-01-13 14:32:30 +08:00 1
postgresql 站队
|
7
ziding 2018-01-13 15:12:35 +08:00 1
postgresql 有很多扩展,很适合,你可以看看 pipelinedb 感觉就是为了你这个场景量身定做的。mysql 数据量大了之后关联查询想死的心都有了。
|
8
dexterzzz 2018-01-13 15:48:36 +08:00 1
列存储数据库专门干这个用的
|
9
suixn 2018-01-13 15:56:18 +08:00 via Android 1
尝试下 clickhouse,实测百亿级数据,有 group by. order by. 10s 内完成
|
11
lzdhlsc OP @gouchaoer 我们测试了一下大约有个几百 G 吧。我描述的可能是简化版的 schema,实际上每个 value 可能是 4 个 double 类型。
|
12
akira 2018-01-13 19:58:41 +08:00 1
你要给出 预期执行的时间呀。 允许跑一天的话,什么都不用处理的啦。
|