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

PostgreSQL 到 MySQL 到 TiDB 迁移实践

  •  1
     
  •   hooopo ·
    hooopo · 2021-06-25 12:58:35 +08:00 · 5450 次点击
    这是一个创建于 1248 天前的主题,其中的信息可能已经有所发展或是发生改变。

    AskTUG 论坛迁移实战:Discourse 从 PostgreSQL 到 MySQL 到 TiDB

    https://asktug.com/t/topic/93923

    27 条回复    2021-12-28 09:31:17 +08:00
    Aoang
        1
    Aoang  
       2021-06-25 13:19:40 +08:00 via Android
    看了看文章,觉得很赞。

    不过它的这个业务需求及业务量,PostgreSQL + Citus 就完事了,省时省心省力,最后玩不转了,商业支持也不会比 TiDB 差
    hooopo
        2
    hooopo  
    OP
       2021-06-25 14:17:24 +08:00
    @Aoang Citus 不错,之前也有关注过。但好像国内 PG 方面的 dba 太少了
    min
        3
    min  
       2021-06-25 14:24:46 +08:00
    按照数据量看,这么搞意义不大啊
    beginor
        4
    beginor  
       2021-06-25 15:41:37 +08:00
    就问你一句,用上了 postgis 怎么迁?
    hooopo
        5
    hooopo  
    OP
       2021-06-25 16:29:50 +08:00
    @beginor 有点难,引入 ES 或 redis geospatial 可以
    bthulu
        6
    bthulu  
       2021-06-25 16:37:47 +08:00
    浪费时间, 毫无意义, 直接上阿里云 PolarDB, 一个上午就搞定了
    bthulu
        7
    bthulu  
       2021-06-25 16:48:55 +08:00
    刚看完了, 基本就是为了 TIDB 论坛应该使用 TIDB 数据库而迁移, 并不是达到了业务瓶颈.
    迁移过程中大量改动了原有的 sql 语句, 并加了很多魔法修改, 对其他人来说, 没有什么实际意义.
    blakejia
        8
    blakejia  
       2021-06-25 16:56:21 +08:00
    Discourse 是一个典型的 HTAP 型应用,它的管理后台有很复杂的报表查询,随着论坛数据量增加,单机 PostgreSQL 很容易出现性能瓶颈。而 TiDB 5.0 引入的 TiFlash MPP 计算模型正好满足了这种应用场景需求。通过引入 TiFlash 节点,对一些复杂的统计分析类查询做并行处理,达到加速的效果。并且不需要改动 SQL 和复杂的 ETL 流程。

    ---------

    具体的性能瓶颈能说下么?一笔带过没有啥技术讨论的意义。从 postgres 转向 mysql 的能解决哪些问题? mysql 转向 TIDB 又能解决哪些问题?
    roundgis
        9
    roundgis  
       2021-06-25 16:57:19 +08:00 via Android
    @hooopo 如果重度依賴 postgis

    redis 那個也無法替換

    需要自己實現,不見得容易
    youngce
        10
    youngce  
       2021-06-25 17:00:42 +08:00   ❤️ 3
    @beginor #4 解决了 TiDB 数据库官方论坛 AskTUG 的 web 服务,使用 PostgreSQL 作为数据库的窘境
    victor
        11
    victor  
       2021-06-25 17:01:32 +08:00
    「 7000+ 注册用户,沉淀了 1.6w+ 问题和 300+ 技术文章」到「 Discourse 是一个典型的 HTAP 型应用,它的管理后台有很复杂的报表查询,随着论坛数据量增加,单机 PostgreSQL 很容易出现性能瓶颈。」

    是 PostgreSQL 太差还是 Discourse 的管理后台报表查询复杂上天了,这点数据量会性能瓶颈?
    sykp241095
        12
    sykp241095  
       2021-06-25 17:04:50 +08:00
    可以理解为这次迁移是产品测试的一环。
    NoirStrike
        13
    NoirStrike  
       2021-06-25 17:08:18 +08:00   ❤️ 1
    TiDB 同时兼容 MySQL 协议和生态,迁移便捷,运维成本极低
    .........
    TIDB 运维成本很低? 上家用的时候都是大佬在伺候
    cstj0505
        14
    cstj0505  
       2021-06-25 17:16:40 +08:00
    从数据库功能看不出有什么迁移的必要
    hooopo
        15
    hooopo  
    OP
       2021-06-25 17:38:12 +08:00
    @bthulu 据我了解 PolarDB 并不是一款 HTAP 数据库,应用场景不 match

    对于其他人的意义,就是如果有从 PG 向 MySQL 迁移的需求,文章里应该覆盖了大部分不兼容的列表和处理方法,可以少走很多弯路。就是一个纯技术分享,也并不是说 MySQL 比 PG 好,只是因为更熟悉而已。
    hooopo
        16
    hooopo  
    OP
       2021-06-25 18:01:50 +08:00
    @blakejia 这里写的确实有点简陋了,由于篇幅原因,之后有时间可以做详细的对比。

    Discourse 这个项目虽然看起来简单,但功能还是很复杂的,报表之类的查询其实没有太多优化空间,OLTP 数据库里一般聚合查询都是全表扫再加上计算,单机很容易出现瓶颈。聚合查询慢也不能算瓶颈吧,有时候就是慢,看个人的忍受程度了,但快一定不是坏事。

    MySQL 转 TiDB 只是一个过渡手段,因为 TiDB 是几乎兼容 MySQL 的。引入 TiFlash 之后,就可以通过增加机器来实现报表查询的加速效果。
    hooopo
        17
    hooopo  
    OP
       2021-06-25 18:02:55 +08:00
    @roundgis 确实。
    sirnay
        18
    sirnay  
       2021-06-25 18:03:52 +08:00
    所以并不是 PostgreSQL 转到 MySQL 再转到 TiDB ?
    只是为了转到 TiDB 所以先转成了 MySQL ?
    hooopo
        19
    hooopo  
    OP
       2021-06-25 18:04:05 +08:00
    @youngce 同样是 9 年义务教育,为什么你那么优秀!
    hooopo
        20
    hooopo  
    OP
       2021-06-25 18:04:39 +08:00
    @sirnay 是的!过河拆桥
    hooopo
        21
    hooopo  
    OP
       2021-06-25 18:09:21 +08:00
    @victor 都很优秀,报表生成可能还需要其他维度的数据,比如用户点击、用户行为,这种表体量会更大一些。
    dayeye2006199
        22
    dayeye2006199  
       2021-06-26 00:22:04 +08:00
    PG 的生态其实特别有意思,国内大家用 mysql 太多,关注 PG 少。

    像这种报表比较多的数据需求,有 https://greenplum.org/ ,citus 我记得也是支持列式存储来更好支持分析型数据需求。也有专门做插件来支持并行执行,列式索引的商业公司: https://swarm64.com/

    文档型数据,PG 也原生支持 JSON 数据类型和 JSON 索引,简单的需求直接上 PG 就行。

    PG 的 FDW ( Foreign Data Wrapper )也非常好玩,可以实现直接接驳对象存储实现数据查询的好玩操作
    hooopo
        23
    hooopo  
    OP
       2021-06-26 09:52:09 +08:00 via Android
    realpg
        24
    realpg  
       2021-06-26 10:22:33 +08:00
    @victor #11
    这点数据量,SQLITE 觉得我都行
    hooopo
        25
    hooopo  
    OP
       2021-06-26 10:59:32 +08:00 via Android
    @realpg 你觉得行你来试试
    adoal
        26
    adoal  
       2021-06-26 11:42:12 +08:00 via iPhone
    一个屁股决定脑袋的案例,只是为了证明自家的狗粮可以吃。有点像以前微软买了 hotmail 之后服务器迁移操作系统。
    freebsdjlu
        27
    freebsdjlu  
       2021-12-28 09:31:17 +08:00
    就像是 oug 论坛,后面不用 db2 一样,从数据量来看,这应该不是技术问题。gitlab 不比这个大多了,不也用 pg 做支撑么。 而对普通用户来讲,用官方不支持的产品,是给自己以后挖坑。个人认为,这不是一个好的示范。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1861 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 16:19 · PVG 00:19 · LAX 08:19 · JFK 11:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.