V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
echoless
V2EX  ›  MySQL

MySQL 处理亿级别的数据怎么做?

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

    面试的时候被问到这个.

    面试官的问题是要设计一个交易所, 支持亿级别的 CRUD.

    我被问住了, 我的有限经验 Postgres 接近过了亿级别, 就很有点慢了.

    当时一直找不到好的解决办法.

    我就说要 sharding 一下, 分库分表实际上也是 sharding 的思维.

    55 条回复    2024-09-11 11:54:55 +08:00
    awalkingman
        1
    awalkingman  
       78 天前   ❤️ 31
    上来就要设计一个交易所,亿你麻痹亿亿亿。
    prodcd
        2
    prodcd  
       78 天前   ❤️ 2
    我这有个 MySQL 表,结构比较简单,类似 key/value 结构,再加个 datetime 用来分区,7 亿数据量,查询带着 datetime ,速度没任何问题。感觉只要能将查询落到分区里,速度不会有什么明显变化。
    luoyou1014
        3
    luoyou1014  
       78 天前   ❤️ 1
    表结构尽量简单,确保查询要走到索引,复杂查询拆开,便于优化,上 SSD ,读写分离,可以支撑到 10 亿级别数据
    再往上可以用分区功能,我的经验只到 20 亿级别,没有开分区,也扛住了。
    echoless
        4
    echoless  
    OP
       78 天前
    @awalkingman #1 这个没办法, 面试官问,我没接触过, 给问懵了.
    echoless
        5
    echoless  
    OP
       78 天前
    @prodcd #2 insert or update 怎么办?
    GeekGao
        6
    GeekGao  
       78 天前   ❤️ 4
    就这些主要的
    echoless
        7
    echoless  
    OP
       78 天前
    @GeekGao #6 多谢, 我顺着这个思路看看.
    esile
        8
    esile  
       78 天前 via Android
    MongoDB 高过 10 亿的,MySQL 百万级别优化不好都会卡吧。
    june4
        9
    june4  
       78 天前   ❤️ 1
    性能和查询有没有优化到位有关,和表数据多少关系不大,百亿表优化了照样正常用
    Mrun
        10
    Mrun  
       78 天前
    只要索引设置合理,mysql 单表存储几十亿并不是什么很难的事情。
    Mrun
        11
    Mrun  
       78 天前
    esee
        12
    esee  
       78 天前
    索引设置合理,没有太多联表操作的话,上亿并没有什么问题,我的数据表已经 4 亿了,也没有性能问题,本来设想的是出现性能瓶颈再分库分表,现在看来完全是想多了。不过我用的阿里的 RDS ,可能硬件性能硬盘的 IO 也是一个很重要的指标。
    xiuming
        13
    xiuming  
       78 天前
    用中间件 vitess 之类
    sagaxu
        14
    sagaxu  
       78 天前
    以前在传统行业的时候,Oracle 单表超过 10 亿的多了去了,那年代没有 SSD ,读写也不慢啊,基本只按 ID 读写,且索引字段不更新
    sagaxu
        15
    sagaxu  
       78 天前
    不按冷热数据分,只按 ID 取模分,单机分库分表意义何在,B+树从 3 层变 4 层,性能下降一个数量级吗?
    echoless
        16
    echoless  
    OP
       78 天前
    @Mrun #11 接近 1 亿的表, 索引就有几十 GB. 这个肯定是要从磁盘读写. 速度不会快的. 交易所要经受频繁读写.

    偏读, 和 CRUD 全照顾到, 不是简单 db 优化就可以的. 我感觉 @GeekGao 那个表比较全面. 说几十亿没问题的, 要么偏向读, 要么写和更新速度肯定慢.
    xuanbg
        17
    xuanbg  
       78 天前
    分表啊,还能怎么办。mysql 处理不了亿级规模的表,虽然开源,但你也没这个能力去优化不是么。
    zhouhuab
        18
    zhouhuab  
       78 天前
    上 TiDB
    BBCCBB
        19
    BBCCBB  
       78 天前
    用的 aws aurora mysql 版本, 单表几亿没任何问题.
    UWH0TdA14ta0s6n9
        20
    UWH0TdA14ta0s6n9  
       78 天前 via Android
    加硬件可及
    june4
        21
    june4  
       78 天前
    @echoless 才几十 GB ?个人 pc 都有几十 GB 内存。至于数据写入,交易所订单量远不能超过 nvme 的写入瓶颈。
    wupher
        22
    wupher  
       78 天前
    面试造火箭,上班拧螺丝

    直接买云服务!
    cslive
        23
    cslive  
       78 天前
    先大力出奇迹再说,上 nvme 固态,1tb 内存
    opengps
        24
    opengps  
       78 天前   ❤️ 1
    回归简单用法,单表过亿并不见得有问题,我还真用过,也有过相关的优化。没想到好几年了这篇文章还能拿来吹一下: https://www.opengps.cn/Blog/View.aspx?id=284
    opengps
        25
    opengps  
       78 天前
    但现在这个时间点,已经有很多更好的方案了,没必要继续去吃透这套思想而继续使用 mysql 干这个业务
    wqhui
        26
    wqhui  
       78 天前
    亿级使用有区分度索引的情况下没什么问题,除非做复杂查询,对于大数据的复杂查询就不走 mysql 了,数据同步到合适的地方玩
    sagaxu
        27
    sagaxu  
       78 天前
    几十 G 的索引拆成 100 个几百 M 的索引,索引文件的大小并没有下降啊,读写 100 个不同的文件还是读 1 个文件不同的区域,对磁盘来说并无区别。单磁盘分表,相当于把索引的第一页,改成人工计算了。
    Felldeadbird
        28
    Felldeadbird  
       78 天前
    八股文方式回答。硬件先改成 SSD 。设置好索引,把表复杂度降低,空间换时间。来来去去也就这么多。

    另外,楼主可以透露一下面试公司是行业什么水平吗。上来就要做交易所。他们是缺人吗?
    jonsmith
        29
    jonsmith  
       78 天前 via Android
    有索引,内存够大就没问题。
    Mrun
        30
    Mrun  
       78 天前   ❤️ 1
    @echoless #14

    并不会,我手上就有几十亿的表,QPS 4000+没啥大压力,更高的没测过
    8355
        31
    8355  
       78 天前
    能问出这种问题的人一定没有实践过。。。问题本身过于开放,聊 2 个小时可以不重样。
    他根本预设不出来一个具体的性能问题,只是感觉会有问题实际并不会有。
    以现在硬件来说并不难达到,成本也不高,上云就更简单了。
    解决方案根据不同的业务场景有很多,单纯 crud 不写垃圾 sql 没什么跑不动。
    ElmerZhang
        32
    ElmerZhang  
       78 天前
    先回问,这个上亿的表存的到底是什么东西,CRUD 分别都是什么样的场景,再根据情况具体设计优化方案。
    Caratpine
        33
    Caratpine  
       78 天前
    不说业务场景,单说 MySQL 处理亿级别的数据,你该更新更新你的知识库了,现在的硬件处理亿级别数据真是绰绰有余
    winglight2016
        34
    winglight2016  
       78 天前
    @BBCCBB #19 我们也用了 aurora ,实测下来性能比阿里的 polardb 要差一点,目前只有几千万数据,很担心上亿之后性能更慢。你们的数据库上到几核了?
    ala2008
        35
    ala2008  
       78 天前
    数据量这么大的表,备份和同步是不是可以考考
    echoless
        36
    echoless  
    OP
       78 天前   ❤️ 1
    @Felldeadbird #28 面的是虚拟币交易所 想弄个 team 做 LLM, 提出这个问题的是最后一个交叉面的面试官(个人感觉还是有水平的,应该是做交易所业务的一个 leader, 问的问题有些比较刁钻, 但也不让人不舒服) 薪水 35kx14 还算可以, 这家做交易所确实还比较知名.
    echoless
        37
    echoless  
    OP
       78 天前
    @8355 #31 以我的感觉这个面试官真的做过.他们就是做交易所的, 而且看起来是面试我的人中水平最高的.

    我接触过股票交易, 感觉要做出那种支持高频的交易所软件 并不容易(大部分都是定制的系统).

    潜意识觉得搞不定, 就懵掉了. 我觉得 GeekGao 那张图比较好. 面试官可能也就是考系统思维能力. 只要每一层说上一两句 应该就合格了.
    salmon5
        38
    salmon5  
       78 天前
    数据库八股文,属于最简单的,因为它比较标准化的东西,有 3-5 年经验就完全掌握。
    salmon5
        39
    salmon5  
       78 天前
    一般的公司里。
    echoless
        40
    echoless  
    OP
       78 天前
    @salmon5 惭愧 没有做过的东西 我一般答不好
    echoless
        41
    echoless  
    OP
       78 天前
    @opengps #24 你这个厉害, 我看过 redshift 的文档, 有一个模式就是你这样做的.
    prodcd
        42
    prodcd  
       78 天前   ❤️ 1
    @echoless 可能我这表有点特殊吧,都是传感器采集回来的数据,insert 就是正常插入,没什么特别的。基本也没 update 操作,所以连 id 字段都没用。根据传感器 id 创建的索引,查询速度基本都是 10ms 以内。
    aino
        43
    aino  
       78 天前
    上亿数据,业务场景很重要,不同场景不同因对方式,我现在单表上亿数据,我就只做分页查询展示出来,表引擎用的 MyISAM 就好了,查询的字段建立索引就行了,服务器 2 核 8G 的
    wogogoing
        44
    wogogoing  
       78 天前
    @awalkingman 哈哈 暴躁老哥,在线怼人
    BBCCBB
        45
    BBCCBB  
       78 天前
    @winglight2016 忘了是 core 8 还是 core 16
    echoless
        46
    echoless  
    OP
       78 天前
    @wogogoing #44 大家上网都是吃饱没事做的, 怼怼能缓解一下压力也好
    wogogoing
        47
    wogogoing  
       78 天前
    @echoless 之前公司业务数据分析这块,有涉及到上亿数据,当时我记得有张表是日 GB 级别的增加。因为是属于日志分析类,所以后面在分区的基础上按日拆分表作为基础数据表,然后生成二级、三级表为最终报表的数据作支撑。
    scyuns
        48
    scyuns  
       78 天前
    厉害 我可以用 mongodb 不
    vopsoft
        49
    vopsoft  
       78 天前
    @sagaxu #14 你说的对 不光 Oracle sqlserver 上亿数据 连索引不用 就能秒查
    Mrun
        50
    Mrun  
       78 天前   ❤️ 1
    @echoless #37

    你可以看看我 11 楼发的,再大的数据,mysql B-Tree 的层高也不会超过 5 层,如果几十亿的数据只是简单查询的话,并不会有什么很大的问题。回归你的面试问题,他的场景如果是交易所,就要问清楚业务场景了,复杂查询和简单查询快递不一样。比如交易订单,如果只有 订单号的 where 查询,十几亿都不会有什么大问题,如果有各种筛选条件,那肯定不行
    weiqk
        51
    weiqk  
       77 天前
    交易所看着吓人,业务简单,也没多少数据
    有人报价时触发撮合下,报价记录队列去存储,撮合记录也队列去存储,就算队列存储延时五分钟也没关系
    撮合过程在内存中,上海证券那么牛逼一分钟也没有 100 万笔报价吧,这个数据量对大家来说还不是小儿科
    正规交易所就连很有限的会员单位(券商)连接数也很少
    julyclyde
        52
    julyclyde  
       77 天前
    交易所其实和关系型数据库差异很大
    撮合系统其实是按价格排序然后再按时间排序的二维链表吧
    wenxueywx
        53
    wenxueywx  
       76 天前   ❤️ 1
    B-tree 高度的问题,无非就是会增加读磁盘的 io 次数。在十年前磁盘还普遍是机械盘的时候是个大问题,现在都上 SSD 了,B-Tree 高度已经不是什么问题了。十年前一般建议 MySQL 单表不要超过 2 千万行,就是因为想要把 B-Tree 高度控制在 3 以下,为此有了很多 sharding 方案;现在索引设计的好,MySQL 处理大几千万到亿级都很快。
    steelshadow39
        54
    steelshadow39  
       71 天前
    @sagaxu #15 想请教一下,一般 B+树三层存 2000W 左右。多一层多一次 IO ,性能下降会特别明显吗?
    sagaxu
        55
    sagaxu  
       71 天前   ❤️ 1
    @steelshadow39

    IO 延迟,
    文件系统缓存(内存),~100ns
    SSD ,~100us
    万转 HDD, ~5ms
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5316 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 08:51 · PVG 16:51 · LAX 00:51 · JFK 03:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.