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

数据库单表数据量过大

  •  
  •   a7217107 · 2019-03-07 21:44:08 +08:00 · 7020 次点击
    这是一个创建于 2092 天前的主题,其中的信息可能已经有所发展或是发生改变。

    mysql,单表 1000W 左右,还在继续往上加,emmm,请问除了 mycat 还有啥好的中间件吗?还是手动水平分表?

    29 条回复    2019-03-14 06:48:32 +08:00
    jzmws
        1
    jzmws  
       2019-03-07 21:55:06 +08:00
    借楼有什么好用的 oracle 分表中间件
    cz5424
        2
    cz5424  
       2019-03-07 22:00:41 +08:00
    分区
    opengps
        3
    opengps  
       2019-03-07 22:13:16 +08:00   ❤️ 1
    先考虑表分区,其次考虑分表,下一步考虑分库
    ghostsimon
        4
    ghostsimon  
       2019-03-07 22:15:26 +08:00 via iPhone
    单表 30 亿,分库,根据时间分表,运行的还不错。
    richard1122
        5
    richard1122  
       2019-03-07 22:19:45 +08:00   ❤️ 1
    1000 w 索引设计好的话应该还距离瓶颈远的
    GGGG430
        6
    GGGG430  
       2019-03-08 02:08:32 +08:00 via iPhone
    @cz5424 @opengps 分区的话以后查询就得带上分区字段了,感觉不太好
    GGGG430
        7
    GGGG430  
       2019-03-08 02:11:08 +08:00 via iPhone
    借楼问一下以一个唯一 uuid 作为唯一索引的表如何水平分表较好,采用 hash 算法+取模如何呢?各位大佬
    yanaraika
        8
    yanaraika  
       2019-03-08 03:44:19 +08:00
    短期 sharding-jdbc。长期来看不管现在的很多 DBA 怎么阻挠,NewSQL 迟早会是主流,中间件分库分表都是 poor man's choice
    ihipop
        9
    ihipop  
       2019-03-08 07:58:05 +08:00 via Android
    tidb
    billwang
        10
    billwang  
       2019-03-08 08:17:51 +08:00
    一千万级的表不算过大,大型业务系统到这个数量级别轻轻松松。建立好索引,sql 尽量不要用全表查询。
    ducklyl
        11
    ducklyl  
       2019-03-08 09:12:06 +08:00
    要考虑未来数据量有多大,上亿的话,水平切分
    jiom
        12
    jiom  
       2019-03-08 09:13:24 +08:00
    @ghostsimon +1。
    chaleaochexist
        13
    chaleaochexist  
       2019-03-08 09:24:51 +08:00
    @yanaraika NewSQL 是啥...
    chaleaochexist
        14
    chaleaochexist  
       2019-03-08 09:25:18 +08:00
    @yanaraika 查到了.谢谢.
    saltxy
        15
    saltxy  
       2019-03-08 09:27:04 +08:00
    @ghostsimon 有用什么中间件吗,还是自己处理 sql 路由
    loveCoding
        16
    loveCoding  
       2019-03-08 09:34:19 +08:00
    ghostsimon
        17
    ghostsimon  
       2019-03-08 10:37:09 +08:00
    @saltxy 用的其他厂家的数据库平台,看日志和报错应该是用 mycat,但是肯定有不少二次开发。具体技术细节就不清楚了。
    xiaoidea
        18
    xiaoidea  
       2019-03-08 13:52:12 +08:00
    建好索引 1000W 不是事,上 SSD,减少复杂查询,复杂逻辑在业务代码里处理。我的经验是单条查询能在 10ms 以内返回。楼上有人提到的 sharding-jdbc 分表也不错
    firstfire
        19
    firstfire  
       2019-03-08 14:04:18 +08:00
    正在使用 sharding-jdbc。(楼上也有提到。
    leon0903
        20
    leon0903  
       2019-03-08 14:45:11 +08:00
    1000w 对于 mysql 还是没什么问题的。像 ls 说的那样,用 ssd,建好索引,速度不会慢。我们这里生产环境有些单表 4000w,照样很快。
    opengps
        21
    opengps  
       2019-03-08 15:08:35 +08:00   ❤️ 1
    @GGGG430 不提倡 uuid 作为分区字段,分区一般使用时间之类的字段,并且设置为聚集索引,来实现不同时段的数据靠在一起。uuid 会导致不同分区都在增长,下一次升级更加困难,索引也会碎片化很难维护
    fuyufjh
        22
    fuyufjh  
       2019-03-08 15:10:33 +08:00
    如果是用的阿里云,推荐 https://cn.aliyun.com/product/drds
    HansCathy
        23
    HansCathy  
       2019-03-08 17:59:26 +08:00
    mycat 分表分库
    Mirana
        24
    Mirana  
       2019-03-08 18:29:34 +08:00
    polardb tidb
    GGGG430
        25
    GGGG430  
       2019-03-08 23:33:50 +08:00 via iPhone
    @opengps 可这个 uuid 是我查询的唯一依据啊,如果用时间字段分表不知道还怎么查指定的某个 uuid 了
    opengps
        26
    opengps  
       2019-03-08 23:47:11 +08:00 via Android
    @GGGG430 可以试试手动拼一个自定义 id,比如 yyyyMmddHHmmssfff 加 8 位随机数代替 uuid
    opengps
        27
    opengps  
       2019-03-08 23:50:14 +08:00 via Android
    说一个我的经历,超大表,测试写入 10 亿,虽然用了自增聚集主键,但是有个另外 2 列的联合索引,写入 5 亿以后发现写入性能降低到开始时候的一半。分析原因是每次写入时候维护非聚集索引浪费了一半的性能
    luozic
        28
    luozic  
       2019-03-09 20:01:14 +08:00 via iPhone
    tidb 或者有钱上 oracle,钱少点上 postgresql。 单表又想性能好,mysql 是有收费的数据引擎可以用的。
    dezhou9
        29
    dezhou9  
       2019-03-14 06:48:32 +08:00 via Android
    能考虑用 sparql 重写业务吗
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3856 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 10:25 · PVG 18:25 · LAX 02:25 · JFK 05:25
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.