首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

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

  •  
  •   qianji201712 · 204 天前 via Android · 6941 次点击
    这是一个创建于 204 天前的主题,其中的信息可能已经有所发展或是发生改变。

    想向大家请教一个问题:

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

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

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

    第 1 条附言  ·  204 天前
    还想请教一个问题:云盘的读写速度,会比本地自建的快吗?我担心有网络 IO 瓶颈
    76 回复  |  直到 2019-04-05 11:48:46 +08:00
        1
    luckybearops   204 天前 via Android
    这量可以锁库随便迁的....
        2
    qianji201712   204 天前
    @luckybearops 感谢!我记得阿里云有提供类似的工具是吧?
        3
    goodryb   204 天前 via iPhone   ♥ 1
    推荐使用 阿里的数据传输工具 DTS,做增量同步,数据校验没问题后切过去
        4
    g079708   204 天前 via iPhone
    阿里云的 数据迁移,免费的
        5
    qianji201712   204 天前
    @goodryb 好的,多谢大佬,没有这个经验,我回头试试
        6
    9hills   204 天前 via iPhone
    如果是单表过大,RDS 也不解决问题

    你应该试试阿里的其他分布式的关系数据库,有三种
        7
    NSAtools   204 天前
    迁移 RDS 有什么优势吗
        8
    rexyan   204 天前   ♥ 1
    使用 rds 之后,阿里云有数据量大的解决方案的
        9
    qianji201712   204 天前 via Android
    @NSAtools 自带备份,而且容灾和安全性更好一些吧,目前我的单库单表,有些虚,而且数据量再大的话,RDS 数据拆分也容易
        10
    qianji201712   204 天前 via Android
    @rexyan 好的,多谢!我仔细研究看看
        11
    qianji201712   204 天前 via Android
    @9hills 好的,分布式应该最好,不过我没有玩过,有本地 SSD 盘的,有些贵,所以考虑了云盘的 RDS,我再看看你说的这几种
        12
    qianji201712   204 天前 via Android
    感谢大家的答疑解惑,等我迁移后,写个文档记录一下
        13
    a54552239   204 天前   ♥ 2
    这不是钱迹作者嘛?
        14
    keepeye   204 天前
    rds iops 限制的死死的 ,三百多万行的表添加索引要等半小时 1 核 1g 的配置
        15
    rockyou12   204 天前
    lz 不考虑下 tidb ?不过运维会麻烦很多就是了
        16
    liyisw   204 天前
    rds 没那么好用,相当于共享数据库,性能互相影响,先多找找更多替代方案
        17
    NSAtools   204 天前
    @qianji201712 同样单库单表准备上 RDS,等你迁移后的记录
        18
    xiaogui   204 天前
    可以考虑根据业务对数据库进行横向或者竖向拆表。缓存什么的该上的也需要上了。
        19
    yidinghe   204 天前
    即使迁移到阿里云,到时候也要改造。迁移的话用最新版本的 RDS,改造的话先考虑分区,改造量相对较小,总记录数几个亿都不是问题。
        20
    opengps   204 天前 via Android
    现在的硬盘是 SSD 吗?不是 SSD 的话,下一步马上就遇到 iops 瓶颈了
        21
    gouchaoer2   204 天前
    1000w 的数据流如果 都走索引的话没啥问题的 ,暂时不用担心
        22
    dnsaq   204 天前 via iPhone
    rds 不是 mysql ?
        23
    qianji201712   204 天前 via Android
    @a54552239 哟,大佬你好😏
        24
    qianji201712   204 天前 via Android
    @keepeye 我看有 4000 多 IOPS 的,应该够用了
        25
    qianji201712   204 天前 via Android
    @rockyou12 主要觉得阿里云省去了很多运维和 DBA 的工作量啊,毕竟个人开发者,还是想把主要精力放到开发上
        26
    qianji201712   204 天前 via Android
    @liyisw 好的,多谢,我会先仔细研究看看的
        27
    qianji201712   204 天前 via Android
    @NSAtools 好的,我先学习学习看
        28
    qianji201712   204 天前 via Android
    @xiaogui 考虑先把一些高频的,做一个 Redis 缓存试试
        29
    qianji201712   204 天前 via Android
    @yidinghe 好的
        30
    qianji201712   204 天前 via Android
    @opengps 基础班只有云盘,不是本地 SSD 的,不清楚云盘是不是,我得确认一下,高级版太贵啊,买不起,毕竟个人开发者
        31
    qianji201712   204 天前 via Android
    @gouchaoer2 嗯目前用着还行,我主要考虑后期的数据量以及数据安全问题,怕自建的不靠谱
        32
    qianji201712   204 天前 via Android
    @dnsaq 也是 MySql 的,不过就是阿里云自己的了,有很多成熟的管理工具,还有备份容灾机制,省了 DBA 很多工作
        33
    9hills   204 天前 via iPhone
    @qianji201712 可以试试 polardb,完全兼容 mysql
        34
    flyoungstudio   204 天前
    钱迹现在后台就靠一个 2c4g 的服务器撑着,还是仅仅是数据库?
        35
    qianji201712   204 天前
    @flyoungstudio 就这一个阿里云的服务器,里面自己搭建的 Apache 和 MySql,使用 PHP 写的,用的 PHP 框架是 Phalcon.
    服务器配置可以看这里
    带宽是 2M 的,服务器 CPU 平均在 30%
        36
    avenger   204 天前 via iPhone
    rds 就是一个异地的 mysql,不要指望性你能能,访问量大的话,还是要靠业务优化
        37
    rogwan   204 天前
    放数据库的磁盘务必 SSD,性能差别很大。数据量超大可以用 TiDB,HybridDB for MySQL 这类兼容 MySQL 的分布式 NewSQL 数据库。
        38
    xiangliangyu   204 天前
    没有坑,直接迁移就可以了
        39
    EmdeBoas   204 天前   ♥ 1
    这个数据量不建议上 TiDB,成本太高了,overkill
    其实不涉及到复杂 SQL 偏 AP 的查询,纯粹的点查即使 MySQL 存储 4~5 亿行的数据也能良好工作
    磁盘务必 SSD 这个观点很奇怪...这个是与你使用数据库的底层数据结构强相关的
    我有负责过组内每天过 TB 吞吐和单表百亿行的场景到 TiDB,TiDB 有他的好,也有他的坏,我个人还是很喜欢这个数据库,也看好他,不说实话实说,目前这家的坑不少,不要盲目追求新的技术( NewSQL ),适合自己最好
        40
    qianji201712   204 天前
    @EmdeBoas 嗯,还是阿里云省心啊
        41
    qianji201712   204 天前
    @rogwan 现在量还不大,就单表 1 千万的量级
        42
    cnbobolee   204 天前
    用阿里云的 rds,毕竟他们专业人员做的,而且做过优化。
        43
    Les1ie   204 天前
    看了这篇 post... 我去下载了钱迹试了试,感觉体验极好 :)
    给 lz 点赞
        44
    cholerae   203 天前
    @rockyou12 才千万的表要啥 tidb
        45
    qianji201712   203 天前
    @Les1ie 哈哈,我这成了广告贴,欢迎加入钱迹家族!!!
        46
    qianji201712   203 天前
    @cnbobolee 读写速度和自建的比呢? 你们用的什么配置呢?
        47
    m2276699   203 天前   ♥ 1
    我的方案有点特别,也是私人项目。
    硬件:1 台 ECS+2 台垃圾笔记本+移动宽带
    软件:galera cluster,n2n,frp
    n2n 将 3 台服务器组成局域网,用于 galera2 个主节点+1 个仲裁节点做数据同步
    稳定运行中,不用再担心云上的某些问题。
    frp 转发请求的并发量还是有些影响,但小型项目我感觉还是可以接受的
    仅供参考
        48
    qianji201712   203 天前 via Android
    @m2276699 老哥你这就有点优秀了👏👏👏 我主要是每日请求量也大啊,一天数据库写入新数据就 10w+了
        49
    keenor   203 天前
    rds 相比于 ecs 在同价格下,性能上没优势,优势在于运维。被 rds 坑过的留下言。
        50
    qianji201712   203 天前
    @keenor 好的,多谢!我也打算观望观望再决定了
        51
    leon0903   203 天前
    mysql 这点数据量应该还可以,我们生产环境的自建数据库,配置 4c 8g + ssd 硬盘, 单表现在有 4000w+,性能还是不错的,我觉得还是要 ssd,那对于 mysql 速度真的是提升很大。
        52
    MoHen9   203 天前 via Android
    写什么数据一天 10w+?
        53
    akira   203 天前
    只要是迁移数据库 出现各种问题不奇怪的
        54
    lovejoy   203 天前
    @9hills 哦?
        55
    rogwan   203 天前 via Android
    @keenor 掉什么样的坑了?让大伙好避避...
        56
    yufeng0681   203 天前
    现在的重点,不应该是分表的设计工作么?
    就一个 Android 端,本地数据搞定查看,新建记账才操作数据库(同步比对一下,消耗不大);
    放 RDS,单表操作的性能影响和本地自建是一样的……
        57
    insiderzzy   203 天前
    表大可以用中间件分表呀? java 的话用 shading-jdbc
        58
    jjx   203 天前
    rds 性能还不如本地

    好处在可伸缩, 或者你有钱, 可以玩高配置

    至于 tidb , 每个查询的业务场景都要考虑测试好, 否则 很多查询都可能远慢于本地 mysql
        59
    vjnjc   203 天前
    @EmdeBoas 请教一下这个场景是否适合迁移 tidb。目前单表 4 亿条,考虑到未来可能到 10 亿条在做 tidb 的预研。问一下 tidb 集群起步的硬件要求有点高啊,要 4 台以上的 8 核 8G?
        60
    reactna1ve   203 天前
    点赞一下你们 app,做的不错
    不过和之前的薄荷比,差了一个 tag 的功能(比如某个特定情况下的消费统计,比如春节、旅游),希望后面能改进!
        61
    qianji201712   203 天前
    @reactna1ve 感谢反馈,我们也考虑加标签功能了,更加灵活
        62
    yuikns   203 天前
    看了下。貌似最新的博客关联有问题。

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

    现在才 2019 年....
    最下面几个导航地址是 http://www.qianjiapp.com/xxxx 但实际上你们已经迁移了,URL 应该是 http://blog.qianjiapp.com/xxxx 才对。
        63
    gz911122   203 天前
    我待过有鱼记账和口袋记账
    口袋记账是 16 年-17 年
    有鱼记账是 17-18 年
    口袋后端是 php,有鱼的是 java...账单表都做了分库分表...
        64
    qianji201712   203 天前
    @yuikns 多谢指正,这个地方故意写 2020 年,是为了置顶 - -( Hexo 博客是按照时间排序的) ,不过官网也在调整中了,不会再用这个 Hexo 搭建的了

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

    docs 这个还没有建成,blog 则会持续更新(目前上面的内容残缺),欢迎关注~
        65
    qianji201712   203 天前
    @gz911122 多谢!你这经历真是独特啊,一直在做记账,haaaa

    我们这边后端也是 PHP 写的,目前账单表还未做分表处理,计划在 6 月份做,到时候表单数据超过 1500w 了,会把新用户考虑分到新的表里面。其他的比如分类表、资产表,目前还没有考虑,因为量大,分类表目前 400w,增长也没有账单表那么多。
        66
    yuikns   203 天前
    @qianji201712 我是说你更改后那个页面主界面,账单同步,账单分类,账号相关这四个链接指向的是 404
        67
    qianji201712   203 天前
    @yuikns 多谢多谢,马上改
        68
    gz911122   203 天前
    @qianji201712 口袋记账的实现模式是 app 端和服务端都保存账本.
    双方通过用户主动触发同步来保持数据一致.
    这样的话日常查询实际上不会落在服务端上...压力会小很多很多.
        69
    cyspy   203 天前
    业内在线迁数据的基本想法是,给定一个时间戳开始全量搬数据库,再把时间戳以后的 binlog 同步过去。记账场景用户应该只能访问自己的数据吧,账号量也不会特别大,直接分表感觉比较容易
        70
    qianji201712   202 天前 via Android
    @gz911122 嗯,钱迹目前是这样的:每次用户主动下拉刷新,就会触发一下同步,而且每次记录一笔,也会触发同步,就是为了能够及时同步上去,目前唯一不太好的就是查询依赖于服务器,这也是接下来改造的重点,用户体验也会好很多
        71
    qianji201712   202 天前 via Android
    @cyspy 嗯,目前决定先不迁移了,发现阿里云 RDS 优势不是很大,等到后期考虑分库分表再迁移,到时候迁移的话,找个半夜,直接停服迁移就好,简单粗暴,也不会影响用户记账,客户端有同步机制的,目前 MySQL 的数据量还扛得住
        72
    leicam3   202 天前
    好厉害啊
        73
    qianji201712   202 天前
    @leicam3 我们现在还是初期啊,打磨产品阶段
        74
    EmdeBoas   198 天前   ♥ 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 能力外,还有一个优势就是分布式事务
    可以结合自身的实际情况尝尝鲜,先从非核心业务慢慢迁移和熟悉,后面自己心里应该就有答案了
        75
    vjnjc   198 天前 via Android
    @EmdeBoas 不要紧,本来数据增长还没这么快,在做预先的研究~你写了这么多,我要看会,多谢!
        76
    kzzhr   194 天前
    1. 如果表结构简单,千万级对于 MySQL 不是什么事,性能不用太考虑。在意的话简单分个表就行。

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

    3. 上阿里云不会带来什么性能飞跃,无非是帮你省点运维工作。花钱办事。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3457 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 30ms · UTC 04:38 · PVG 12:38 · LAX 21:38 · JFK 00:38
    ♥ Do have faith in what you're doing.