想向大家请教一个问题:
个人项目,之前用阿里云服务器,不过数据库是自建的 MySQL,一直是单服务器单表存储,备份是每天 dump 一次然后备份到云盘。
目前用户注册量上来后,每天差不多 10w+条新数据写入,最大的一张表,数据量已经超过 1000w,虽然现在体验还好,但是担心再过一段时间后,会有些吃力。
本身服务器配置也不高,2 核 4G,所以最近考虑迁移到阿里云数据库 RDS。 有些纠结的是,这个迁移过程会不会有什么坑呢?希望有经验的大佬一起交流一下,感谢!
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 58 天前
|