数据库“去O”的选型方案.docx

?

?

数据库“去O”的选型方案

?

?

来自twt社区同行交流，欢迎更多同行参与交流

国产数据库去O，是用基于PG产品，还是考虑基于MySQL产品合适？问题来自社区会员@wanggeng某银行系统运维工程师，探讨来自twt社区众多同行的分享，欢迎大家参与交流，各抒己见。*“争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点

@孔再华中国民生银行?数据库运维工程师：

国产数据库去O，当前主要是金融行业和政企。这些用户都是oracle等商业数据库的深耕用户，重度依赖数据库的能力，甚至用了很多存储过程来加速处理性能。

那么PG产品和MySQL产品哪个合适？MySQL用的那么广泛，是否能承担去O的重任？

从相似度来说，PG数据库比mysql更像Oracle，无论是数据库对象的概念，还是数据库内的组件概念。但是落到技术的细节上，其实每个数据库都天差地别。

MySQL基于主键索引组织的表，PG的追加更新存储引擎，和Oracle相比从根子上差异就很大。所以最终还是落到用户的使用场景上来比较。

Oracle的深度用户的应用场景是广泛的，基本上属于HTAP的场景。

MySQL比较适合纯tp的使用场景，对于复杂sql的支持能力一直很弱。

而PG相对好一点。从这点来说，如果不做sql改造调优，PG产品适用性更好。在存储过程的支持上，PG也比MySQL要好，当然这些还是需要迁移改造的成本，并非无缝迁移。

除了适用的场景外，我们还需要关注PG和MySQL的其他能力。例如产品的成熟度，生态的成熟度。MySQL作为简单的数据库，在互联网企业中深度使用。因此产品的能力，缺陷都很清楚。周边的生态也是MySQL要好一些，周边工具的支持通常都会先支持MySQL。

而PG在这方面相对差一些，所以出于对可靠性，稳定性等方面的考虑，使用PG产品还需要时间来催熟。

总结一下就是这两类产品都可选，摒弃弱项，选择强项，依据业务的场景（性能，可靠性等）来选择合适的数据库，用得好就是好的去O数据库。

@zhangjunpoCBIT数据库运维工程师：

这个还是看自己的业务场景，PG现在国内社区感觉还是不太好，但是产品的功能还是可以的。

如果使用MySQL替换O，还得慎重考虑，MySQL只适合业务场景比较简单的，如果数据量和业务量比较大，得分库分表，后续维护起来比较麻烦。

个人感觉，如果真要替换O，也不一定非得用PG和MySQL，也可以考虑其他国产数据库，综合考虑。

@hanfeng_twt大型金融单位数据库架构师：

在去O过程中，我们先明确一点，没有数据库产品是可以完全替代的。即完成去O工作，是需要通过“应用改造+数据库选型+应用迁移”，结合在一起才能完成。这里需要考虑整体目标及路径。问题中的两种方式，原则上都是可以完成去O工作，但对于应用改造及迁移的影响差异较大。

1.PG类产品，其企业级功能较为完善，使用体感与Oracle相近。有些基于PG为内核的产品，在Oracle兼容性上做了了大量工作。对用户来说，使用上与Oracle更为相近，甚至大部分可以做到无缝迁移；少部分需要修改上，也相对工作量不大。

2.MySQL类产品，流行程度更高，但与Oracle相比，功能差异较多。如在去O中选用，需做较大的修改。

@lulihuan1987张家港行数据库管理员：

这个需要结合业务系统来看，如果是分析型的可以考虑基于PG的产品，比如GaussDB，TDSQL-PG版本，如果是交易型的可以基于MySQL的，比如TDSQL-MYSQL版本，GoldenDB等等，如果是混合负载可以考虑国产纯自研的如TIDB，OB等等。

@某金融企业数据库工程师：

去O的database应用有选择PG数据库的，也有选择MySQL的，根据应用的特点来选吧；好像大数据量，批处理文件多，import批量数据入库频繁的应用选择PostgreSQL多，面向前台OLTP应用，频繁有批量查询的应用选MySQL的多一点。

@jillmejollytechCIO：

虽然MySQL用的非常的多，特别是电商领域。还有很多互联网大厂都喜欢用MySQL。但是我个人认为MySQL对比?PG有极其强悍的SQL编程能力。特别很多函数或者原来Oracle实现的语法，可以简单迁移或者对照换个替换函数使用。但是MySQL在这方面就差了一些。?

此外PG在GIS、JSON和数组等比MySQL支持的多一些。

PG对插件的支持比MySQL好，可以很好的弥补和扩展功能。

当然PG的流复制与MySQL的BINLOG比还是差了不少，特别还有在电商的单笔查询或者根据主键查询，PG的性能是弱于MySQL的。

主要还是看使用的场景如何。一般的说电商用MySQL分析类用PG。

@某企业DBA：

去O先考虑架构优化吧.国