这是一个创建于 2364 天前的主题，其中的信息可能已经有所发展或是发生改变。
一张 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 simple2025 2019-07-01 19:33:15 +08:00 via Android 一天 1kw 的数据公司应该很有钱 |
 | 16 rrfeng 2019-07-01 19:46:09 +08:00 单表十二亿路过 |
 | 17 rb6221 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 了解一下 |
Select Language