单表已经超过一千万，自建 MySQL 和阿里云 MySQL 的疑问

[qianji201712]

想向大家请教一个问题：

个人项目，之前用阿里云服务器，不过数据库是自建的 MySQL，一直是单服务器单表存储，备份是每天 dump 一次然后备份到云盘。

目前用户注册量上来后，每天差不多 10w+条新数据写入，最大的一张表，数据量已经超过 1000w，虽然现在体验还好，但是担心再过一段时间后，会有些吃力。

本身服务器配置也不高，2 核 4G，所以最近考虑迁移到阿里云数据库 RDS。 有些纠结的是，这个迁移过程会不会有什么坑呢？希望有经验的大佬一起交流一下，感谢！

[qianji201712]

@reactna1ve 感谢反馈，我们也考虑加标签功能了，更加灵活

[yuikns]

看了下。貌似最新的博客关联有问题。

http://blog.qianjiapp.com/2020/10/user-guide/

现在才 2019 年....
最下面几个导航地址是 http://www.qianjiapp.com/xxxx 但实际上你们已经迁移了，URL 应该是 http://blog.qianjiapp.com/xxxx 才对。

[gz911122]

我待过有鱼记账和口袋记账
口袋记账是 16 年-17 年
有鱼记账是 17-18 年
口袋后端是 php,有鱼的是 java...账单表都做了分库分表...

[qianji201712]

@yuikns 多谢指正，这个地方故意写 2020 年，是为了置顶 - -（ Hexo 博客是按照时间排序的） ，不过官网也在调整中了，不会再用这个 Hexo 搭建的了

后续其实会有三个关联的站点:
- http://www.qianjiapp.com 作为 App 的官网落地页存在
- http://docs.qianjiapp.com 则作为钱迹的用户指南存在，考虑用 GitBook 搭建一个完整的用户指南。
- http://blog.qianjiapp.com 会作为我们官方的一个记录博客存在，每次版本更新或者一些技术问题，会写在上面，也算是一个记录钱迹成长的地方，让用户了解一些钱迹背后的故事。

docs 这个还没有建成，blog 则会持续更新（目前上面的内容残缺），欢迎关注～

[qianji201712]

@gz911122 多谢！你这经历真是独特啊，一直在做记账，haaaa

我们这边后端也是 PHP 写的，目前账单表还未做分表处理，计划在 6 月份做，到时候表单数据超过 1500w 了，会把新用户考虑分到新的表里面。其他的比如分类表、资产表，目前还没有考虑，因为量大，分类表目前 400w，增长也没有账单表那么多。

[yuikns]

@qianji201712 我是说你更改后那个页面主界面，账单同步，账单分类，账号相关这四个链接指向的是 404

[qianji201712]

@yuikns 多谢多谢，马上改

[gz911122]

@qianji201712 口袋记账的实现模式是 app 端和服务端都保存账本.
双方通过用户主动触发同步来保持数据一致.
这样的话日常查询实际上不会落在服务端上...压力会小很多很多.

[cyspy]

业内在线迁数据的基本想法是，给定一个时间戳开始全量搬数据库，再把时间戳以后的 binlog 同步过去。记账场景用户应该只能访问自己的数据吧，账号量也不会特别大，直接分表感觉比较容易

[qianji201712]

@gz911122 嗯，钱迹目前是这样的：每次用户主动下拉刷新，就会触发一下同步，而且每次记录一笔，也会触发同步，就是为了能够及时同步上去，目前唯一不太好的就是查询依赖于服务器，这也是接下来改造的重点，用户体验也会好很多

[qianji201712]

@cyspy 嗯，目前决定先不迁移了，发现阿里云 RDS 优势不是很大，等到后期考虑分库分表再迁移，到时候迁移的话，找个半夜，直接停服迁移就好，简单粗暴，也不会影响用户记账，客户端有同步机制的，目前 MySQL 的数据量还扛得住

[leicam3]

好厉害啊

[qianji201712]

@leicam3 我们现在还是初期啊，打磨产品阶段

[EmdeBoas]

@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 能力外，还有一个优势就是分布式事务
可以结合自身的实际情况尝尝鲜，先从非核心业务慢慢迁移和熟悉，后面自己心里应该就有答案了

[vjnjc]

@EmdeBoas 不要紧，本来数据增长还没这么快，在做预先的研究～你写了这么多，我要看会，多谢！

[kzzhr]

1. 如果表结构简单，千万级对于 MySQL 不是什么事，性能不用太考虑。在意的话简单分个表就行。

2. 不过一天一 dump 确实有风险，可以根据你的条件完善一下。

3. 上阿里云不会带来什么性能飞跃，无非是帮你省点运维工作。花钱办事。

[wyjwork]

下载你们 app 试一下