V2EX = way to explore V2EX 是一个关于分享和探索的地方
Sign Up Now For Existing Member Sign In
请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2492 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 |
 | 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