这是一个创建于 1247 天前的主题，其中的信息可能已经有所发展或是发生改变。
AskTUG 论坛迁移实战：Discourse 从 PostgreSQL 到 MySQL 到 TiDB
27 条回复 • 2021-12-28 09:31:17 +08:00
 |
1
Aoang 2021-06-25 13:19:40 +08:00 via Android
看了看文章，觉得很赞。
不过它的这个业务需求及业务量，PostgreSQL + Citus 就完事了，省时省心省力，最后玩不转了，商业支持也不会比 TiDB 差 |
 |
3
min 2021-06-25 14:24:46 +08:00
按照数据量看，这么搞意义不大啊
|
 |
4
beginor 2021-06-25 15:41:37 +08:00
就问你一句，用上了 postgis 怎么迁？
|
 |
6
bthulu 2021-06-25 16:37:47 +08:00
浪费时间, 毫无意义, 直接上阿里云 PolarDB, 一个上午就搞定了
|
|
7
bthulu 2021-06-25 16:48:55 +08:00
刚看完了, 基本就是为了 TIDB 论坛应该使用 TIDB 数据库而迁移, 并不是达到了业务瓶颈.
迁移过程中大量改动了原有的 sql 语句, 并加了很多魔法修改, 对其他人来说, 没有什么实际意义. |
 |
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 又能解决哪些问题？ |
 |
10
youngce 2021-06-25 17:00:42 +08:00  3
@beginor #4 解决了 TiDB 数据库官方论坛 AskTUG 的 web 服务，使用 PostgreSQL 作为数据库的窘境
|
 |
11
victor 2021-06-25 17:01:32 +08:00
「 7000+ 注册用户，沉淀了 1.6w+ 问题和 300+ 技术文章」到「 Discourse 是一个典型的 HTAP 型应用，它的管理后台有很复杂的报表查询，随着论坛数据量增加，单机 PostgreSQL 很容易出现性能瓶颈。」
是 PostgreSQL 太差还是 Discourse 的管理后台报表查询复杂上天了，这点数据量会性能瓶颈？ |
 |
12
sykp241095 2021-06-25 17:04:50 +08:00
可以理解为这次迁移是产品测试的一环。
|
 |
13
NoirStrike 2021-06-25 17:08:18 +08:00 1
TiDB 同时兼容 MySQL 协议和生态，迁移便捷，运维成本极低
......... TIDB 运维成本很低? 上家用的时候都是大佬在伺候 |
 |
14
cstj0505 2021-06-25 17:16:40 +08:00
从数据库功能看不出有什么迁移的必要
|
 |
15
hooopo OP @bthulu 据我了解 PolarDB 并不是一款 HTAP 数据库，应用场景不 match
对于其他人的意义，就是如果有从 PG 向 MySQL 迁移的需求，文章里应该覆盖了大部分不兼容的列表和处理方法，可以少走很多弯路。就是一个纯技术分享，也并不是说 MySQL 比 PG 好，只是因为更熟悉而已。 |
|
16
hooopo OP @blakejia 这里写的确实有点简陋了，由于篇幅原因，之后有时间可以做详细的对比。
Discourse 这个项目虽然看起来简单，但功能还是很复杂的，报表之类的查询其实没有太多优化空间，OLTP 数据库里一般聚合查询都是全表扫再加上计算，单机很容易出现瓶颈。聚合查询慢也不能算瓶颈吧，有时候就是慢，看个人的忍受程度了，但快一定不是坏事。 MySQL 转 TiDB 只是一个过渡手段，因为 TiDB 是几乎兼容 MySQL 的。引入 TiFlash 之后，就可以通过增加机器来实现报表查询的加速效果。 |
 |
18
sirnay 2021-06-25 18:03:52 +08:00
所以并不是 PostgreSQL 转到 MySQL 再转到 TiDB ?
只是为了转到 TiDB 所以先转成了 MySQL ? |
 |
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 ）也非常好玩，可以实现直接接驳对象存储实现数据查询的好玩操作 |
|
23
hooopo OP @dayeye2006199 是的
|
 |
26
adoal 2021-06-26 11:42:12 +08:00 via iPhone
一个屁股决定脑袋的案例，只是为了证明自家的狗粮可以吃。有点像以前微软买了 hotmail 之后服务器迁移操作系统。
|
 |
27
freebsdjlu 2021-12-28 09:31:17 +08:00
就像是 oug 论坛，后面不用 db2 一样，从数据量来看，这应该不是技术问题。gitlab 不比这个大多了，不也用 pg 做支撑么。 而对普通用户来讲，用官方不支持的产品，是给自己以后挖坑。个人认为，这不是一个好的示范。
|
Select Language