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