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

数据库“去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先考虑架构优化吧.国产的DB架构复杂且重,完全不适用于普遍的烟囱式IT架构.鼓噪分布式DB的公司没有一家有烟囱式架构的包袱.@GBase_David

DBA：去O是重点。其实去O本来不难。难就难在业务系统的适配，难就难在很多很多业务系统和某个数据库绑定的特别特别死，无法拆分，最终数据库兼容性成了重点。真正数据库要能够解决的核心问题就是事务和并发性。无论哪个应用开发商都应该把业务逻辑尽最大可能的从数据库是迁移出去。数据库只做数据库该做的擅长的事情即可。@annoymous技术经理：建议看具体的场景、行业。如果是传统行业，建议PGSQL。如果是互联网行业，建议MySQL。@HelloWorDomai