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

《数据库去O的选型方案.docx》由会员分享，可在线阅读，更多相关《数据库去O的选型方案.docx（6页珍藏版）》请在第一文库网上搜索。

1、数据库“去0”的选型方案来自twt社区同行交流,欢迎更多同行参与交流国产数据库去0,是用基于PG产品，还是考虑基于MySQ1产品合适？问题来自社区会员wanggeng某银行系统运维工程师，探讨来自twt社区众多同行的分享，欢迎大家参与交流，各抒己见。*“争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点孔再华中国民生银行数据库运维工程师：国产数据库去0,当前主要是金融行业和政企。这些用户都是OraC1e等商业数据库的深耕用户，重度依赖数据库的能力，甚至用了很多存储过程来加速处理性能。那么PG产品和MySQ1产品哪个合适？MySQ1用的那么广泛，是否能承担去。的重任？从相似度来说，PG数

2、据库比mysq1更像OraC1e,无论是数据库对象的概念，还是数据库内的组件概念。但是落到技术的细节上，其实每个数据库都天差地别。MySQ1基于主键索引组织的表，PG的追加更新存储引擎，和OraC1e相比从根子上差异就很大。所以最终还是落到用户的使用场景上来比较。OraCIe的深度用户的应用场景是广泛的，基本上属于HTAP的场景。MySQ1比较适合纯tp的使用场景，对于复杂Sq1的支持能力一直很弱。而PG相对好一点。从这点来说，如果不做Sq1改造调优，PG产品适用性更好。在存储过程的支持上，PG也比MySQ1要好，当然这些还是需要迁移改造的成本，并非无缝迁移。除了适用的场景外，我们还需要关注P

3、G和MySQ1的其他能力。例如产品的成熟度，生态的成熟度。MySQ1作为简单的数据库，在互联网企业中深度使用。因此产品的能力，缺陷都很清楚。周边的生态也是MySQ1要好一些，周边工具的支持通常都会先支持MySQ1。而PG在这方面相对差一些，所以出于对可靠性，稳定性等方面的考虑，使用PG产品还需要时间来催熟。总结一下就是这两类产品都可选，摒弃弱项，选择强项，依据业务的场景（性能，可靠性等）来选择合适的数据库，用得好就是好的去0数据库。zhangjunpoCB1T数据库运维工程师:这个还是看自己的业务场景，PG现在国内社区感觉还是不太好，但是产品的功能还是可以的。如果使用MySQ1替换0,还得慎重

4、考虑，MySQ1只适合业务场景比较简单的，如果数据量和业务量比较大，得分库分表，后续维护起来比较麻烦。个人感觉，如果真要替换0,也不一定非得用PG和MySQ1,也可以考虑其他国产数据库，综合考虑。hanfeng_twt大型金融单位数据库架构师：在去0过程中，我们先明确一点，没有数据库产品是可以完全替代的。即完成去0工作，是需要通过“应用改造+数据库选型+应用迁移”，结合在一起才能完成。这里需要考虑整体目标及路径。问题中的两种方式，原则上都是可以完成去0工作，但对于应用改造及迁移的影响差异较大。1PG类产品，其企业级功能较为完善，使用体感与OraC1e相近。有些基于PG为内核的产品，在OraC1

5、e兼容性上做了了大量工作。对用户来说，使用上与OraC1e更为相近，甚至大部分可以做到无缝迁移；少部分需要修改上，也相对工作量不大。2.MySQ1类产品，流行程度更高，但与OraC1e相比，功能差异较多。如在去0中选用，需做较大的修改。1u1ihuan1987张家港行数据库管理员:这个需要结合业务系统来看，如果是分析型的可以考虑基于PG的产品，比如GaussDB,TDSQ1-PG版本，如果是交易型的可以基于MySQ1的，比如TDSQ1-MYSQ1版本，GoIdenDB等等，如果是混合负载可以考虑国产纯自研的如TIDB,OB等等。某金融企业数据库工程师：去。的database应用有选择PG数据库

6、的，也有选择MySQ1的，根据应用的特点来选吧；好像大数据量，批处理文件多，import批量数据入库频繁的应用选择PoStgreSQ1多，面向前台O1TP应用，频繁有批量查询的应用选MySQ1的多一点。ji11mejo11ytechCIO：虽然MySQ1用的非常的多，特别是电商领域。还有很多互联网大厂都喜欢用MySQ10但是我个人认为MySQ1对比PG有极其强悍的SQ1编程能力。特别很多函数或者原来OraCIe实现的语法，可以简单迁移或者对照换个替换函数使用。但是MySQ1在这方面就差了一些。此外PG在GIS、JSoN和数组等比MySQ1支持的多一些。PG对插件的支持比MySQ1好，可以很好的

7、弥补和扩展功能。当然PG的流复制与MySQ1的BIN1OG比还是差了不少，特别还有在电商的单笔查询或者根据主键查询，PG的性能是弱于MySQ1的。主要还是看使用的场景如何。一般的说电商用MySQ1分析类用PG。某企业DBA：去0先考虑架构优化吧.国产的DB架构复杂且重，完全不适用于普遍的烟囱式IT架构.鼓噪分布式DB的公司没有一家有烟囱式架构的包袱.GBase._DavidDBA：去0是重点。其实去0本来不难。难就难在业务系统的适配，难就难在很多很多业务系统和某个数据库绑定的特别特别死，无法拆分，最终数据库兼容性成了重点。真正数据库要能够解决的核心问题就是事务和并发性。无论哪个应用开发商都应该把业务逻辑尽最大可能的从数据库是迁移出去。数据库只做数据库该做的擅长的事情即可。annoymous技术经理:建议看具体的场景、行业。如果是传统行业，建议PGSQ1。如果是互联网行业，德议MySQ1o1IeI1oWorDomain:国产数据库去0,我理解是：数据库去0,是基于PG还是基于MySQ1。PG或者MySQ1都要考虑1、业务SQ1的改造。2、数据库的迁移，转换。具体还是看：1、当前数据库的数据大小。2、数据库的核心程度。3、业务敏感性的要求。-全文完一