单表已经超过一千万，自建 MySQL 和阿里云 MySQL 的疑问
qianji201712 · litang0908 · 2019-03-26 08:32:48 +08:00 via Android · 11018 次点击这是一个创建于 2102 天前的主题，其中的信息可能已经有所发展或是发生改变。
想向大家请教一个问题：
个人项目，之前用阿里云服务器，不过数据库是自建的 MySQL，一直是单服务器单表存储，备份是每天 dump 一次然后备份到云盘。
目前用户注册量上来后，每天差不多 10w+条新数据写入，最大的一张表，数据量已经超过 1000w，虽然现在体验还好，但是担心再过一段时间后，会有些吃力。
本身服务器配置也不高，2 核 4G，所以最近考虑迁移到阿里云数据库 RDS。 有些纠结的是，这个迁移过程会不会有什么坑呢？希望有经验的大佬一起交流一下，感谢！
第 1 条附言 · 2019-03-26 11:48:51 +08:00
还想请教一个问题：云盘的读写速度，会比本地自建的快吗？我担心有网络 IO 瓶颈
 |
1
luckybearops 2019-03-26 08:35:41 +08:00 via Android
这量可以锁库随便迁的....
|
 |
2
qianji201712 OP @luckybearops 感谢！我记得阿里云有提供类似的工具是吧？
|
 |
3
goodryb 2019-03-26 08:39:25 +08:00 via iPhone  1
推荐使用 阿里的数据传输工具 DTS，做增量同步，数据校验没问题后切过去
|
 |
4
g079708 2019-03-26 08:39:27 +08:00 via iPhone
阿里云的 数据迁移，免费的
|
|
5
qianji201712 OP @goodryb 好的，多谢大佬，没有这个经验，我回头试试
|
 |
6
9hills 2019-03-26 08:44:21 +08:00 via iPhone
如果是单表过大，RDS 也不解决问题
你应该试试阿里的其他分布式的关系数据库，有三种 |
 |
7
NSAtools 2019-03-26 08:45:48 +08:00
迁移 RDS 有什么优势吗
|
 |
8
rexyan 2019-03-26 08:49:14 +08:00 1
使用 rds 之后，阿里云有数据量大的解决方案的
|
|
9
qianji201712 OP @NSAtools 自带备份，而且容灾和安全性更好一些吧，目前我的单库单表，有些虚，而且数据量再大的话，RDS 数据拆分也容易
|
|
10
qianji201712 OP @rexyan 好的，多谢！我仔细研究看看
|
|
11
qianji201712 OP @9hills 好的，分布式应该最好，不过我没有玩过，有本地 SSD 盘的，有些贵，所以考虑了云盘的 RDS，我再看看你说的这几种
|
|
12
qianji201712 OP 感谢大家的答疑解惑，等我迁移后，写个文档记录一下
|
 |
13
a54552239 2019-03-26 09:16:09 +08:00 2
这不是钱迹作者嘛？
|
 |
14
keepeye 2019-03-26 09:21:14 +08:00
rds iops 限制的死死的 ，三百多万行的表添加索引要等半小时 1 核 1g 的配置
|
 |
15
rockyou12 2019-03-26 09:25:19 +08:00
lz 不考虑下 tidb ？不过运维会麻烦很多就是了
|
 |
16
liyisw 2019-03-26 09:27:31 +08:00
rds 没那么好用，相当于共享数据库，性能互相影响，先多找找更多替代方案
|
|
17
NSAtools 2019-03-26 09:27:45 +08:00
@qianji201712 同样单库单表准备上 RDS，等你迁移后的记录
|
 |
18
xiaogui 2019-03-26 09:28:13 +08:00
可以考虑根据业务对数据库进行横向或者竖向拆表。缓存什么的该上的也需要上了。
|
 |
19
yidinghe 2019-03-26 09:28:27 +08:00
即使迁移到阿里云，到时候也要改造。迁移的话用最新版本的 RDS，改造的话先考虑分区，改造量相对较小，总记录数几个亿都不是问题。
|
 |
20
opengps 2019-03-26 09:28:41 +08:00 via Android
现在的硬盘是 SSD 吗？不是 SSD 的话，下一步马上就遇到 iops 瓶颈了
|
 |
21
gouchaoer2 2019-03-26 09:30:46 +08:00
1000w 的数据流如果 都走索引的话没啥问题的 ，暂时不用担心
|
 |
22
dnsaq 2019-03-26 09:30:57 +08:00 via iPhone
rds 不是 mysql ？
|
|
23
qianji201712 OP @a54552239 哟，大佬你好😏
|
|
24
qianji201712 OP @keepeye 我看有 4000 多 IOPS 的，应该够用了
|
|
25
qianji201712 OP @rockyou12 主要觉得阿里云省去了很多运维和 DBA 的工作量啊，毕竟个人开发者，还是想把主要精力放到开发上
|
|
26
qianji201712 OP @liyisw 好的，多谢，我会先仔细研究看看的
|
|
27
qianji201712 OP @NSAtools 好的，我先学习学习看
|
|
28
qianji201712 OP @xiaogui 考虑先把一些高频的，做一个 Redis 缓存试试
|
|
29
qianji201712 OP @yidinghe 好的
|
|
30
qianji201712 OP @opengps 基础班只有云盘，不是本地 SSD 的，不清楚云盘是不是，我得确认一下，高级版太贵啊，买不起，毕竟个人开发者
|
|
31
qianji201712 OP @gouchaoer2 嗯目前用着还行，我主要考虑后期的数据量以及数据安全问题，怕自建的不靠谱
|
|
32
qianji201712 OP @dnsaq 也是 MySql 的，不过就是阿里云自己的了，有很多成熟的管理工具，还有备份容灾机制，省了 DBA 很多工作
|
|
33
9hills 2019-03-26 09:49:57 +08:00 via iPhone
@qianji201712 可以试试 polardb，完全兼容 mysql
|
 |
34
flyoungstudio 2019-03-26 09:55:48 +08:00
钱迹现在后台就靠一个 2c4g 的服务器撑着，还是仅仅是数据库？
|
|
35
qianji201712 OP @flyoungstudio 就这一个阿里云的服务器，里面自己搭建的 Apache 和 MySql，使用 PHP 写的，用的 PHP 框架是 Phalcon.
服务器配置可以看这里  带宽是 2M 的，服务器 CPU 平均在 30% |
 |
36
avenger 2019-03-26 10:30:10 +08:00 via iPhone
rds 就是一个异地的 mysql，不要指望性你能能，访问量大的话，还是要靠业务优化
|
 |
37
rogwan 2019-03-26 10:52:44 +08:00
放数据库的磁盘务必 SSD，性能差别很大。数据量超大可以用 TiDB，HybridDB for MySQL 这类兼容 MySQL 的分布式 NewSQL 数据库。
|
 |
38
xiangliangyu 2019-03-26 11:09:36 +08:00
没有坑，直接迁移就可以了
|
 |
39
EmdeBoas 2019-03-26 11:22:25 +08:00 1
这个数据量不建议上 TiDB，成本太高了，overkill
其实不涉及到复杂 SQL 偏 AP 的查询，纯粹的点查即使 MySQL 存储 4~5 亿行的数据也能良好工作 磁盘务必 SSD 这个观点很奇怪...这个是与你使用数据库的底层数据结构强相关的 我有负责过组内每天过 TB 吞吐和单表百亿行的场景到 TiDB，TiDB 有他的好，也有他的坏，我个人还是很喜欢这个数据库，也看好他，不说实话实说，目前这家的坑不少，不要盲目追求新的技术（ NewSQL ），适合自己最好 |
|
40
qianji201712 OP @EmdeBoas 嗯，还是阿里云省心啊
|
|
41
qianji201712 OP @rogwan 现在量还不大，就单表 1 千万的量级
|
 |
42
cnbobolee 2019-03-26 12:04:55 +08:00
用阿里云的 rds，毕竟他们专业人员做的，而且做过优化。
|
 |
43
Les1ie 2019-03-26 12:32:31 +08:00
看了这篇 post... 我去下载了钱迹试了试，感觉体验极好 :)
给 lz 点赞 |
|
45
qianji201712 OP @Les1ie 哈哈，我这成了广告贴，欢迎加入钱迹家族！！！
|
|
46
qianji201712 OP @cnbobolee 读写速度和自建的比呢？ 你们用的什么配置呢？
|
 |
47
m2276699 2019-03-26 13:09:15 +08:00 2
我的方案有点特别，也是私人项目。
硬件：1 台 ECS+2 台垃圾笔记本+移动宽带 软件：galera cluster，n2n，frp n2n 将 3 台服务器组成局域网，用于 galera2 个主节点+1 个仲裁节点做数据同步 稳定运行中，不用再担心云上的某些问题。 frp 转发请求的并发量还是有些影响，但小型项目我感觉还是可以接受的 仅供参考 |
|
48
qianji201712 OP @m2276699 老哥你这就有点优秀了👏👏👏 我主要是每日请求量也大啊，一天数据库写入新数据就 10w+了
|
 |
49
keenor 2019-03-26 14:32:06 +08:00
rds 相比于 ecs 在同价格下，性能上没优势，优势在于运维。被 rds 坑过的留下言。
|
|
50
qianji201712 OP @keenor 好的，多谢！我也打算观望观望再决定了
|
 |
51
leon0903 2019-03-26 17:36:28 +08:00
mysql 这点数据量应该还可以，我们生产环境的自建数据库，配置 4c 8g + ssd 硬盘， 单表现在有 4000w+，性能还是不错的，我觉得还是要 ssd，那对于 mysql 速度真的是提升很大。
|
 |
52
MoHen9 2019-03-26 17:54:28 +08:00 via Android
写什么数据一天 10w+?
|
 |
53
akira 2019-03-26 18:04:05 +08:00
只要是迁移数据库 出现各种问题不奇怪的
|
 |
56
yufeng0681 2019-03-26 19:17:34 +08:00
现在的重点，不应该是分表的设计工作么？
就一个 Android 端，本地数据搞定查看，新建记账才操作数据库（同步比对一下，消耗不大）； 放 RDS，单表操作的性能影响和本地自建是一样的…… |
 |
57
insiderzzy 2019-03-26 19:39:11 +08:00
表大可以用中间件分表呀？ java 的话用 shading-jdbc
|
 |
58
jjx 2019-03-26 19:45:38 +08:00
rds 性能还不如本地
好处在可伸缩, 或者你有钱, 可以玩高配置 至于 tidb , 每个查询的业务场景都要考虑测试好, 否则 很多查询都可能远慢于本地 mysql |
 |
59
vjnjc 2019-03-26 20:58:49 +08:00
@EmdeBoas 请教一下这个场景是否适合迁移 tidb。目前单表 4 亿条，考虑到未来可能到 10 亿条在做 tidb 的预研。问一下 tidb 集群起步的硬件要求有点高啊，要 4 台以上的 8 核 8G?
|
 |
60
reactna1ve 2019-03-26 21:00:22 +08:00
点赞一下你们 app，做的不错
不过和之前的薄荷比，差了一个 tag 的功能（比如某个特定情况下的消费统计，比如春节、旅游），希望后面能改进！ |
|
61
qianji201712 OP @reactna1ve 感谢反馈，我们也考虑加标签功能了，更加灵活
|
 |
62
yuikns 2019-03-27 03:22:52 +08:00
看了下。貌似最新的博客关联有问题。
http://blog.qianjiapp.com/2020/10/user-guide/ 现在才 2019 年.... 最下面几个导航地址是 http://www.qianjiapp.com/xxxx 但实际上你们已经迁移了，URL 应该是 http://blog.qianjiapp.com/xxxx 才对。 |
 |
63
gz911122 2019-03-27 09:18:16 +08:00
我待过有鱼记账和口袋记账
口袋记账是 16 年-17 年 有鱼记账是 17-18 年 口袋后端是 php,有鱼的是 java...账单表都做了分库分表... |
|
64
qianji201712 OP @yuikns 多谢指正，这个地方故意写 2020 年，是为了置顶 - -（ Hexo 博客是按照时间排序的） ，不过官网也在调整中了，不会再用这个 Hexo 搭建的了
后续其实会有三个关联的站点: - http://www.qianjiapp.com 作为 App 的官网落地页存在 - http://docs.qianjiapp.com 则作为钱迹的用户指南存在，考虑用 GitBook 搭建一个完整的用户指南。 - http://blog.qianjiapp.com 会作为我们官方的一个记录博客存在，每次版本更新或者一些技术问题，会写在上面，也算是一个记录钱迹成长的地方，让用户了解一些钱迹背后的故事。 docs 这个还没有建成，blog 则会持续更新（目前上面的内容残缺），欢迎关注～ |
|
65
qianji201712 OP @gz911122 多谢！你这经历真是独特啊，一直在做记账，haaaa
我们这边后端也是 PHP 写的，目前账单表还未做分表处理，计划在 6 月份做，到时候表单数据超过 1500w 了，会把新用户考虑分到新的表里面。其他的比如分类表、资产表，目前还没有考虑，因为量大，分类表目前 400w，增长也没有账单表那么多。 |
|
66
yuikns 2019-03-27 11:01:50 +08:00
@qianji201712 我是说你更改后那个页面主界面，账单同步，账单分类，账号相关这四个链接指向的是 404
|
|
67
qianji201712 OP @yuikns 多谢多谢，马上改
|
|
68
gz911122 2019-03-27 12:03:59 +08:00
|
 |
69
cyspy 2019-03-27 12:07:33 +08:00
业内在线迁数据的基本想法是，给定一个时间戳开始全量搬数据库，再把时间戳以后的 binlog 同步过去。记账场景用户应该只能访问自己的数据吧，账号量也不会特别大，直接分表感觉比较容易
|
|
70
qianji201712 OP @gz911122 嗯，钱迹目前是这样的：每次用户主动下拉刷新，就会触发一下同步，而且每次记录一笔，也会触发同步，就是为了能够及时同步上去，目前唯一不太好的就是查询依赖于服务器，这也是接下来改造的重点，用户体验也会好很多
|
|
71
qianji201712 OP @cyspy 嗯，目前决定先不迁移了，发现阿里云 RDS 优势不是很大，等到后期考虑分库分表再迁移，到时候迁移的话，找个半夜，直接停服迁移就好，简单粗暴，也不会影响用户记账，客户端有同步机制的，目前 MySQL 的数据量还扛得住
|
 |
72
leicam3 2019-03-27 13:39:19 +08:00
好厉害啊
|
|
73
qianji201712 OP @leicam3 我们现在还是初期啊，打磨产品阶段
|
|
74
EmdeBoas 2019-03-31 20:03:18 +08:00 1
@vjnjc 抱歉回复得晚了，最近比较忙..
对于存储引擎的选项来说，核心是从业务场景出发： 1. 数据应用层的类型到底是 OLTP （高频点查，明显的特征就是查询走索引，关心明细数据）还是 OLAP （指标分析类、海量数据聚合，关注扫描性能） 2. 冷热数据分离，数据量在持续增长，但如果其实有大量冷数据，没必要一直放在关系型数据库中，归档至 HIVE 也是不错的选择，即使临时碰到了需要查询的场景，不过是慢一些而已 3. 对可用性的要求是不是真的有那么高，其实 MySQL+MHA 的可用性也很高了，不是金融行业，挂个 30~60s 也能接受吧 下面再来结合谈谈 TiDB 本身： 1. TiDB 目前 OLAP 是不能看的，TiSpark 优势比起其他的传统 AP 没有啥优势，他们最近也在基于 Clickhouse 做新的一个 AP 引擎 TiFlash，不过稳定估计还是要过很长一段时间了.... 2. 不考虑异地多 IDC 的情况，TiDB 的可用性并不一定比传统的 MySQL+MHA 好很多，如果 KV 层挂一个 node，其实也会有 60s （具体看配置，但肯定不会少于 15s ）左右的部分查询写入失败； 3. 小坑会比较多（一般都是参数配置相关的）...这个也没法具体展开讲，但核心就是碰到了问题网上资料会很少，你需要与官方去沟通，官方比较活跃的，但这个时间比起能在网上找到肯定长很多....所以最好要有相关的知识储备，它复杂的架构不是一般开发能 cover 住的，多达 700 多个监控指标...所以运维门槛比较高 4. 成本，这个就不多谈了 5. 很关注读写延迟就不用考虑用这个了 其实现在 sharding-proxy 的框架挺多的，tddl、zebra 等等，10 亿的数据量做 sharding 也还好 对于 NewSQL 除了强大的 scale-out 能力外，还有一个优势就是分布式事务 可以结合自身的实际情况尝尝鲜，先从非核心业务慢慢迁移和熟悉，后面自己心里应该就有答案了 |
 |
76
kzzhr 2019-04-05 11:48:46 +08:00
1. 如果表结构简单，千万级对于 MySQL 不是什么事，性能不用太考虑。在意的话简单分个表就行。
2. 不过一天一 dump 确实有风险，可以根据你的条件完善一下。 3. 上阿里云不会带来什么性能飞跃，无非是帮你省点运维工作。花钱办事。 |
 |
77
wyjwork 61 天前
下载你们 app 试一下
 |
Select Language