与国产数据库有关的30个问题解读.docx

《与国产数据库有关的30个问题解读.docx》由会员分享，可在线阅读，更多相关《与国产数据库有关的30个问题解读.docx（17页珍藏版）》请在优知文库上搜索。

1、1、如何结合不同的业务场景选择合适的数据库？在做出合适选择之前，需要以下准备工作：1 .业务画像针对不同的业务，做出业务侧的数据库画像，包括但不限于如下维度：业务指标：使用方式、使用特征（在线用户、峰值用户、并发用户等）、圭要级别、可用性要求.此外，针对未来发展也要有所评估。系统指标：包括应用系统来源、技术栈、开发语言、系统拓扑、与数据库交互方式等数据库指标：包括数据规模、访问特征、物理环境、软件环境、数据库拓扑等运行特征：场景分类（TP、AP,混合）、架构分类、数据规模、数据特征、计第规模、事务一致性要求、扩展性要求、高可用要求、应用耦合性等2 .产品测试对数据麻产品进行测试，形成对产品的统

2、一认识.这其中包括数据库内核、管理、开发、安全等多方面能力的评估.这方面可参考我之前分享的分布式数据库评测标准.3 .其他因素除上述外，还应包括企业内部的一些自身因素的考虑，如成本、运维、开发改造等因素.上述因素综合考虑后，才能做出相对合理的选择.2、业务系统应用架构设计时如何适配分布式数据库以实现高性能，在线犷展后性能如何同步提升？性能问题，是需要慎事考虑的.如果仅仅考察个体的表现，分布式数据库很有可能不如传统单机数据库或集中式数据库.其分布式架构在原理就先天存在一些短板，对于要求极致性能的场景是不合适的.分布式数据库的强处，是在于扩展系统的整体吞吐能力，可承载更多的业务量.因此从原理上讲，

3、扩展后不会提升性能.当然，分布式系统扩展后，数据庵被做个更多的拆分，会有助于单体执行效率的提升，这种情况下是有性能提升的.基干上面，在应用架构设计时.应充分利用分布式数据库的数据分布特点，做好业务单元化.通过在更小的数据以元完成，进而达到优化效果.3、分布式数据库故障时如何确保故障自动转移，自动恢复业务，实现高可用？分布式库的组件较多,大致可分为数据节点、计算节点、控制节点三类角色。其中，计算书点一股为无状态的,故障后可切换自动恢豆；控制节点一般采用自身高可用保障，出现问题会主动自愈；数据节点出现问题时较为重要，因为其上面承载的数据。我理解问题主要是对应这一角色.针对数据节点，不同分布式数据库

4、产品，底层实现有所差异，大致可分为两种情况：1 .基于单机数据廊的主从豆制模式2 .基于多数派协议保证的多副本模式无论是哪种模式，当出现故障时都会完成自动选主，自动切换，从而实现高可用。目前的大部分产品.都已可实现在同AZ、同城踏RZ的自主切换、对业务无感（业务需实现出惜重试机制）.针对异地的情况，一般还是建议人工介入，而不自动完成切涣.4、分布式数据库全局一致性和高性能如何取舍达到平衡?个人觉得这两者不存在平衡关系,一般一致性要求是来源于业务，很难去做业务上的取舍.都是在有明确一致性要求的情况I,尽量做到性能最好.5、中小银行后端稳态类系统进行分布式方向改造的必要性？分布式改造的必要性，主要

5、来自于几个方面：业务驱动（数据规模、算力不足等需要犷展）政策驱动（监管方明确需求）技术驱动（为适配技术栈革新）管理驱动（从统一管理等角度考虑）这里需权衡分布式改造所带来的投入产出比及对应的风睑评估.个人建议，中小型银行的稳态业务，不一定非要做分布式改造，需要做Sl严谩的评估.6、是否有适合银行业务场景的O1.TP基准测试？目前没有统一的O1.Tp测试标准其原因是银行的业务也各有不同，很难找到统一标准。一般的做法是找出部分有代表性的业务，简化提炼后形成一个测试case.在测试中，通过不同测试CaSe的组合，形成满足某业务的测试集。7、关于国产分布式数据库未来趋势分析？目前尚处于早期阶段，趋势发展

6、上还不是很明朗.个人有以下一些判断：1 .多技术路线会长期共存；2 .云会在未来达到统一，但周期会很长；3 .MySQ1.PG公成为事实生态标准,各产品会加以适配。8、面对这么多国产分布式数据库，如何制定一个选型标准？关于选型标准，目前没有统一国家、行业标准，有条件的企业都在做自有标准.按照之前的工作，需檎理出选型测试的众多评估维度及细化的指标.这里是存在不小的工作A1.这里可参考我近期发的一些内容：分布式数据库评估维度分析.9、在分布式数据库架构选型中，如何看待计算与存储分离？存算分离，还是要看具体斛决的问黑i,其最早是由云厂商提出的,目的是将资源解假，从而实现不同资源的分层扩缩。赤特这个特

7、性,还是要看其背后带来的收益是否是自身关注的：否则没有太大意义.10、分布式数据库容灾容错方案？而可用方案,各家产品实现有所差异.一般情况F.在同城双中心异地单中心的情况b.当同城某AZ出现问题时，是无法自动切换到同城第二个AZ,是需要引入第三个AZ,满足仲裁需求的,当然有些是可以写死切换逻辑在里面，但非标准的切换流程.囚此，般建议在同城采用3RZ,湎足多数派选举，可实现白动切换能力。异地一般不建议参与其中,毕竟存在较长时空。11、分布式数据库使用规则？分布式数据眸较传统单机数据库或集中式数据库，是存在较多不同，因此在开发之处就有针对性的诳行规避比较重要。这其中常见的点包括：事务大小、SQ1.

8、纹杂度、分布式事务、DD1.变更等。基本的处理匣则就是3B原则,即避免BigSQ1.、BigTranSaClion、BigBatch.此外,尽量减小分布式数据库中的变更，无论是架构上的（如扩缩容）、结构上的（如DD1.）等.12、分布式数据库如何选型？通常不会根据每食应用来选择合适的数据底，这惮做的话技术栈可能过于发散。建议的做法是.根据公司业务场景，收敛为若干种类型,然后为祗个类型选择23款产品,选弃多款产马的原因，是为J避免厂商绑定向翘，然后制黑根据每类场景，制定开发规范（取23款产品的功能交集作为标准）。13、有成熟的国产数据库产品替代OracIe、Db2数据产品吗？替代Orade或DB

9、2的产品，可分为几种类型：1.核心业务此类业务特点是数据规模大、并发高、延迟要求低，但数据库使用场景较为简单.通常这种方式可使用业务到单元化+国产库方式。这种方式对库的要求相对不高.可选择的范围较广.2 .中型业务此类业务特点是数据规模中等，数据库使用巨杂度。这种方式要想很好地替代，相对较难.一般建议的做法是蚕构.当然这里需要考虑的改造成本比较高.可考虑的选型范围是NewSQ1.系列产品。3 .小型业务此类业务特点是数据规模较小，包杂度不低。这种系统数找众多，可考虑是使用对0racleDB2藕容性较商的产品.如很多从PG衍生的产品或国内部分数据库产品。14、国产数据库如何实现在正式库中进行测试

10、？库内测试的何速.一般不是通过数据库端实现的,可通过互联网通常采用的影子麻方案来解决,也有一些开源产AA（如ShardingSPhere）,内Bff这一能力，通过在上层模拟出数据扉的统一入口，内部设置分流、限流策略，来完成压测工作。15、国产分布式数据库，在成本上是否如宣传的那样比OraCle有较大的优势？采用分布式数据库的成本来自几个方面：软件授权费用：这部分相对有一定优势，OraCIe原厂费用较高.软件服务费用：这部分相对国产库较高，因为成熟度不足，还需大JS人力投入目还未形成成熟的服务生态硬件采购赛用：这部分分布式国产库较高，因为涉及的组件较多，需耗费机器资源较多.日常维护费用：这部分国

11、产库较高，因需重新搭建队伍，新增人力成本较高.16、NewSQ1.分布式数据库有哪些缺陷？主要缺陷取决于不同库的架构，这点差异很大.重点可考察：分布式事务、全局一致性全局日志，数据唯一性同城&异地高可用生态功能（如针对研发）管控能力（管理、优化、监控等）17、国产数据库去O,是用基于PG产品，还是考虑基于MySQ1.产品合适？在去O过程中，我们先明确一点，没有数据库产品是可以完全替代的.即完成去。工作，是需要通过应用改造+数据库选型+应用迁移，结合在一起才能完成.这里需要考虑整体目标及路径。问题中的两种方式，原则上都是可以完成去O工作，但对于应用改造及迁移的影响差异较大.PG类产品，其企业级功

12、能较为完善，使用体感与Orade相近.有些基于PG为内核的产品,在Orade兼容性上做了了大盘工作.对用户来说，使用上与OraCIe更为相近，甚至大部分可以做到无缝迁移；少部分需要修改上，也相对工作量不大.MySQ1.类产品，流行程度更高，但与OraCIe相比，功能差异较多.如在去。中选用，需做较大的修改.18、数据迁移如何保证前后一致性？数据迁移后，前后环境处于静态切面，做数据对比是比较简单的.操作上可有几种方式：自研-数据可通过SQi.语句完成简单的数据对比如记录条目数,多维度统计报告进行比对.自研-过程可针对迁移过程中的日志的方式,通过代码提取对比。这种方式对目标库无影晌.外部工具有些外

13、部产品也支持数据比对，如DSG的supersync等问题：数据比对的核心问题是效率，需找到一种平衡.19、目前国产化分布式数据库产品繁多，对O1.TP数据库在去0转向国产化该如何做选型评估？可分为几种情况：兼容性评估这与去。的路线有关,如考虑尽量减少去0的应用迁移难度，选择兼容OraCIe的产品，则兼容性需要圭点评估。Orade的功能非常丰富，目前国产化产品无法做到全部兼容，对于分布式数据库而言，这点更为突出。产品评估除去上面因素外，就是从数据产品本身维度进行测试.这里涉及的测试点很多，具体细节可参考我之前的社区文克.20、在核心业务系统方面去0转向国产化数据库产品有哪些典型案例？各家在去。场

14、景上，案例还是很多的，包括部分股份制银行、城商行等.如中信、平安、张家口商业.亿联、北京银行等.从未来趋势来看,目前国内去。尚未形成较为主流的实现路线,各家策略均有不同,从技术路线来看，也未达到形式上的统一.因此建议金触企业，根据自身特点，选择更为通用性的标准作为迁移依据，即从应用角度入手，重点考虑涨容标准开发模式，忽略个体产品差异。对未来不同路线，保持充分的灵活性。少？从上述数据南迁移到国产库,可分为两种技术路线：物理迁移：基于日志这种方式的产品很多，如国内的DSG、英方、DataPiPe等逻辑迁移：基于数据这种方式的产品,开源和商业的都有,如典型的Kettle.DataX等影响迁移的时长，

15、主要取决于几个因素：迁移逻辑：是否存在加工转换数据对比：是否需做质量检查数据规模/链路：一般都采用全量+增量方式，这一因素一般影响不大22、去O国产中面对的存储过程、函数等如何处理？国产数据库在库内计算（存储过程、函数）及特性能力（如视图）,较Orade数据南还存在一定差距.特别是采取分布式架构的国产数据面,差距更为明显.从实际推动工作上看，也是两种策略:尽量选择兼容性产品，这样代价相对较小简化数据库应用，格上述能力在应用层解决，数据库只做CRUD23、国产数据库迁移中应用改造量的评估？应用改造工作量的W估，是有一定参考依据的。之前在项目实践中，也积累些方法并形成小工具.基本原理就是根据对象和语句的数歌、亚杂度等作为输入，根据实践总结出的球位工时i三行评估.在后续的不断迭代中，改进评估方法。24、有没有数据库综合管理平台推荐？该提问点出了一个迁移到国产库的共性问题，即数据库碎片化.在传统数据库选型中，主打两三款数据库，就可以覆盖几乎所有的业务场景,而到了国产库上则情况大不同。一方面数据库的架构类别多样；二方面还没形成垄断性产品，众多产品都可选择；三方面各产品能力差异较突出，都有各自的适应性场景.基于上述现状，这一问题势必会影响到企业的使用.影响的方面包括：数据库架构设计、应