原文: https://www.uber.com/en-JP/blog/postgres-to-mysql-migration/
我个人的观点一直是:postgres 的各种丰富功能,对于中小数据规模的业务非常好用,OLAP 非常便利,中小数据规模也没性能瓶颈,而数据量大的 OLAP 功能用传统关系型数据库都是无法满足的,都需要 streaming 、map/reduce 之类的大数据基础设施以及实施、离线计算分离才是正解。而一旦排除 OLAP 的便利性之后,postgres 相对于 mysql 并没有优势。
大陆之外的国家和地区的非 Top 数据量计的业务,人口基数和数据量没那么大,这是 postgres 在大陆之外越来越流行的非常重要的原因之一。
非引战,如果是我个人项目,数据量不大,我也乐于使用 postgres 。但是以往一些 postgres 教徒的观点太幼稚了。 恰好看到 uber 的这个 blog ,拿来背书,所以引来说几句公平话。
![]() |
1
guiyumin 1 天前
who cares ?
uber 都快倒闭了 |
2
kzfile 1 天前
mysql 简单便宜对大多数业务也够用
但对我不够用,我用 pg |
3
sthwrong 1 天前
uber 的问题比较久了,不一定合时宜,当时有的问题现在很多都解决或者改善了。
在部分领域又有明显优势,能选 pg 我还是选 pg 的。 |
4
kapr1k0rn 1 天前
你拿快 10 年前的案例来背书?
|
![]() |
5
lesismal OP |
6
sthwrong 23 小时 55 分钟前
海量数据这俩都不是银弹,都得拉队友支撑,问题是,现阶段,pg 的队友可能更多更强大。稍小一个量级的情况下,pg 比 mysql 强是不争的事实。
|
![]() |
7
lesismal OP @sthwrong #6
> 海量数据这俩都不是银弹,都得拉队友支撑 对,我在主贴中就说过了。 > 现阶段,pg 的队友可能更多更强大 普通数据量级,pg 功能丰富很多业务非常好用,这个我在主贴里也说了 但是我见到的几次 V 站上 pger 们的现象,有点盲目相信 pg 了,不区分业务量级数据量级和场景,一味贬低 mysql 。 这样会造成很多错觉,中小项目做得风生水起,大项目直接拉垮,尤其是早期阶段的 OLAP 甚至业务逻辑重度依赖 pg ,导致大项目发展起来后的重构成本高太多。 所以我并不是说 pg 不好,也不是说 mysql 比 pg 好,而是应该懂得如何合理选型、不要盲目追捧和吹嘘。 对于这种海量数据场景,mysql 的劣势甚至成为项目发展生命周期中的优势,比如 OLAP 不友好、干脆早期就少用它搞 OLAP ,比如存储过程不行、干脆不使用它的存储过程,而是把这些都诉诸于拉队友的方式解决。这些不便利,在业务量级剧增需要重构时,反倒成为优势。 当然,多数人的工作内容并不涉及这种海量数据场景,用 pg 足够爽,挺好的,但是没必要盲目捧 pg 贬 mysql 。 |