一张 mysql 主表有三千万数据量,这才刚开始,后期数据量会更多,v 友有什么建议吗
1
guokeke 2019-07-01 18:36:26 +08:00
你预期后期数据量每天什么规模?
|
2
guokeke 2019-07-01 18:36:38 +08:00
以及说下业务呗
|
3
mokeyjay 2019-07-01 18:39:35 +08:00
无非是分库分表、或者上非关系型
|
5
v2eb OP 公司有人提到要用 ES
|
6
tt67wq 2019-07-01 18:42:09 +08:00
删苦跑路吧!!!
|
7
swulling 2019-07-01 18:42:44 +08:00 via iPhone
三天这个量,只能放弃关系数据库了
|
8
guokeke 2019-07-01 18:46:02 +08:00
@v2eb 如果数据有时间相关性可以按照天或者月分表,无时间相关就要根据业务来分析了,粗暴点可以按照常用查询的列的值的 hash 进行分表。
|
9
gaoyulong 2019-07-01 18:48:01 +08:00
看业务啊,不说具体要求就是耍流氓
|
10
txy3000 2019-07-01 18:51:12 +08:00 via Android
以后还会有每天 1000w 的增量吗? 会的话索引更新很频繁 单机承载不了的 上分布式吧 sharding 负载均衡那一套
如果查询还多 Redis 也得上 缓存热点数据 减轻数据库 IO 如果并发还高 建议上消息队列 异步插入 |
11
neptuno 2019-07-01 18:51:13 +08:00
是不是表设计有问题?
|
12
Solarest 2019-07-01 18:51:25 +08:00
热数据分库分表,冷数据进数仓
|
13
icekingcy 2019-07-01 18:53:41 +08:00 via iPhone
就是些流水数据吧? 换 ES 吧
|
14
v2eb OP 感觉 DBA 有点水,字段大小随意设
|
15
chenqh 2019-07-01 19:33:15 +08:00 via Android
一天 1kw 的数据公司应该很有钱
|
16
rrfeng 2019-07-01 19:46:09 +08:00
单表十二亿路过
|
17
janus77 2019-07-01 19:51:11 +08:00
这个增量速度,怕是需要搞冷热分库吧
你千万级别用作数据展示 都放出来?不太可能吧,最多就是把计算结果再存一个表而已。计算任务应该是定时跑的,这个不需要多高的实时性 |
18
vZexc0m 2019-07-01 23:14:04 +08:00 via Android 1
持续增长,上 tidb 得了。
|
19
airfling 2019-07-01 23:25:42 +08:00 via Android
上 es 吧,一天几个 g 的数据都不怕,反正你也只是展示数据,es 分好索引完全没问题
|
20
Takamine 2019-07-01 23:30:09 +08:00 via Android
ETL。(。ò ∀ ó。)
|
21
watsy0007 2019-07-02 01:43:35 +08:00
tsdb 了解下.
|
22
ETiV 2019-07-02 05:15:04 +08:00
#17 +1
5 年前供职的公司就是这种情况: MySQL、每天一个表,每天一千万行数据,遇到推广可能两三千万,收集客户端上报的数据 每天零点过就把线上数据拉下来算一下当天的新增、日活这些指标 同时客户端还会冗余的向百度统计上报数据,作为一种参考手段 |
23
ihipop 2019-07-02 07:20:28 +08:00 via Android
用 tidb,告别分库分表
|
24
jaskle 2019-07-02 07:28:09 +08:00 via Android
一个字:删
|
25
feiyunruyue 2019-07-02 09:09:03 +08:00
Tidb 搞起吧,兼容 mysql
|
26
chaleaochexist 2019-07-02 09:09:51 +08:00
妥妥大数据.具体用啥咱也不懂.
好像 ES 是最简单的. |
27
opengps 2019-07-02 09:11:38 +08:00
挺好,能遇到这类问题真的可以快速提升自己的架构水平
|
28
Aresxue 2019-07-02 09:20:22 +08:00
我们公司用的是 ES,算是比较简单粗暴的做法吧。我很羡慕这样的机会。
|
29
alpha2016 2019-07-02 09:21:22 +08:00
es 吧,我知道个 mysql 到了瓶颈,然后上 es 的
|
30
HunterPan 2019-07-02 09:43:48 +08:00
类似的日志数据 就不需要 mysql 了
|
31
laojiaqing 2019-07-02 09:49:16 +08:00
@icekingcy 请问下 es 是什么
|
32
fengxianqi 2019-07-02 10:09:17 +08:00
@laojiaqing #31 我一个前端,猜一下是指 Elastic Search
|
33
sujin190 2019-07-02 11:17:47 +08:00
@ETiV #22 如果纯统计数据完全没必要落数据库吧,直接队列,实时计算,之后文本存储就行了,写入速度快性能好,就算之后有其他统计需求,读文本也比读 mysql 快多了
|
34
tiedan 2019-07-02 11:30:27 +08:00
直接每天一张表即可
|
35
salamanderMH 2019-07-02 11:38:00 +08:00
如果可以,试试 tidb
|
36
chrisliu1314 2019-07-02 12:13:35 +08:00 via iPhone
不知道是什么业务场景,无法分析。
分布式数据库 tidb,可以了解一下,没用过。 如果是数据分析的话,那就用 hive 表。 |
37
ducklyl 2019-07-02 12:23:38 +08:00
要求加薪,然后,就有解决方案了
|
38
PerpetualHeng 2019-07-02 12:27:15 +08:00
数据量大,增长慢,用分库分表。
你这是数据量已经大了,但是增量也大,后面无法预估,传统 db 已经不能解决了。 搜索引擎(ES),或者 HBase。 |
39
kim01 2019-07-02 12:43:56 +08:00
mongo 数据库,一天 8000W+数据。搞了一伙按月分表按小时存,简直就是洒洒水一个月也就 5000W+左右了
|
40
linxiaoziruo 2019-07-02 14:40:34 +08:00
如果坚持使用 MySQL 的话,建议了解一下 MySQL 的分区功能,专做历史数据处理的。如果用 mongo 的话,建议了解一下 mongo 的分片功能,专做大数据的,如果是 es 的话,如果只做统计,建议使用,如果频繁增删改查,我建议不要用 es,会有很多数据不一致的坑出现。
|
41
xzc19970719 2019-07-02 14:44:44 +08:00
鹰角??
|
42
eslizn 2019-07-02 14:49:24 +08:00
@linxiaoziruo mysql 的分区很坑的,首先你也必须用到分区的 key 才能高效,另外线上涉及 ddl 操作简直是噩梦
|
44
whp1473 2019-07-02 19:14:45 +08:00
ES 是 Nosql,非结构化的数据,可以按照天建立 Index 索引,然后区分冷热数据,时间久的归冷数据。
Mysql 分库分库可以用 tidb(没用过,不知道什么情况),mycat(有坑,左连接这种需要提前指定,没法自由,还有事务不支持其他还可以) |
45
kxjhlele 2019-07-03 05:30:53 +08:00 via Android
结构数据换 PostgreSQL,还支持时序
|
46
v2exe2v 2019-07-03 09:40:08 +08:00
DolphinDB 了解一下
|