《与国产数据库有关的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估，是有一定参考依据的。之前在项目实践中，也积累些方法并形成小工具.基本原理就是根据对象和
16、语句的数歌、亚杂度等作为输入，根据实践总结出的球位工时i三行评估.在后续的不断迭代中，改进评估方法。24、有没有数据库综合管理平台推荐？该提问点出了一个迁移到国产库的共性问题，即数据库碎片化.在传统数据库选型中，主打两三款数据库，就可以覆盖几乎所有的业务场景,而到了国产库上则情况大不同。一方面数据库的架构类别多样；二方面还没形成垄断性产品，众多产品都可选择；三方面各产品能力差异较突出，都有各自的适应性场景.基于上述现状，这一问题势必会影响到企业的使用.影响的方面包括：数据库架构设计、应用开发、管理维护等多方面.我将此问题,发散回答下.1 .架构设计不同国产库的架构差异很大，没有办法统一架构，但
17、这方面可通过标准进行规范化.国东及行业也推出一些规范，指导企业进行架构设计。例如：针对可用性设计上面，同城3AZ成为很妥分布式数据库的默认，以此才能提供自动切换能力，满足RTo=O,RPO=O的预期。2 .应用开发应用开发方面，整体差异不大。现有主流数据库还是避循关系建模，可利用之前的工具完成.问题比较大的是在结构设计方面，特别是分布式架构有其特点，很多传统的设计思想需要改变；SQ1.语句开发方面，尽量做到简洁处理，避免年度依赖国产库.这方面可使用一些数据库审核工具，辅助做些结构设计、语法开发的质量检直工作；但这方面是否有欠缺的，主要是现有工具几乎无法对各家数据库产品做到差异化审核，只能完成比
18、较初级的检百.而厂商自有产品能力，大部分还未涉及此部分.3 .管理维护在管理维护方面，如上面谈到的，各家产品架构差异明显，尚无法做到统一管理.虽然有些第三方厂商产品支持多种数据库平台的管理功能，但大部分是支持国外商业数据库和较为流行的开源数据库.对国产库的支持，尚比较有限.甚至大部分厂商自有产品，在这方面的能力都不太健全.因此，想实现一体化的数据库管理，困难较大,解决的方法，要么是通过自研的方式解决，要么是等待国内三方产品完善起来，要么是依赖云平台（全栈使用某云厂家产品）.4 .应用访问在应用访问方面，是否可提供统一的访问接入也是用户比较头咚的问Sg。大量在数据上层应用（如审计、安全、可视化等
19、）是无法兼容多种数据库（特别是国产库）。这方面有些第三方的数据库中间层产品，可提供一定的屏蔽熊力，满足统一访问的诉求.但比较完美的不多，很多还需要二研增强，25、将商业数据库Orade、DB2、SQ1.Sener上的应用，迁移到国产数据库，有哪些风险点？从商业数据库迁移到国产库，风险是来自多方面的:1.技术风险国产库的功能较大型商业敌据库仍存在一定差距，需要在选型时期就有清淅认识.不同国产库架构不同、技术路线各异，需要建立符合企业自身要求的评测体系.通过完善的测试，对国产库有着全面细致的了解。虽然无法做到功能一一对应，但起码要做到对功能边界清淅可控.通过上述手段，规避可能潜在的技术风险.2 .
20、开发风除没有能缪完美替代数据库的产品，都是需要开发做一定适配性改造.此处的风险主要一方面来自国产库功能缺失带来的应用实现侧的技术难度；一方面则来自开发资源的投入,特别是当面临后者的不确定性时，风险更大.此外，还需通过引入测试完成对开发结果的验证，规避可能的处理逻辑、性能风险.3 .迁移风除这里谈到的迁移包括数据迁移和应用迁移.针对前者，相对好处理些，通过应用逻辑或其他三方工具是完成数据的迁移工作，蚤点霜考虑迁移后的质量对比，避免数据不一致问题.更多难点在于应用迁移，如何平滑完成迁移很函要.此外，相关的灰度、回退等迁移能力同样需要具备。而此方面，很难找到通用的平台来提供基础能力，大部分还是需要用
21、户自研完成.4 .运行风险数据库上线只是第一步，长期检定运行更为重要.国产数据扉普遍面临发展时间短，缺少大信践上运行积累，抉少较为成熟的运行维护体系。包括常见的监控、诊断、优化、排障、得份、高可用、升级等均需要完善支持。26、用户对自己的信息化都不了解的情况下.如何去更快的了解企业的数信息化数据库业务？造成这一问题的原因有多种.有些是自研的，因企业人员流失导致信息丢失；有些是采用外包方式，随有外包公司的变化消失而导致信息丢失。上述这些现象是客观存在的，解决方法无外乎两种，通过业务侧和技术侧解决，亦或是两者配合使用。1 .业务侧：需要通过文档、人员调研等方式，搜集现有系统运行情况.2 .技术例：
22、通过各类日志、报告等形式，收集现有系统运行情况.如针对数据库，可利用下述方法做好两研收集工作。可以参考这篇文率：例次成功的数案以调研27、国产数据库选型集中式与分布式如何选取？集中式和分布式，是数据库两个大的架构类型，两者都有各自适应场景.从过去二三十年发展来看，集中式架构很好地解决了金融机构的场景问题，从技术角度来讲绝大多数场景并没有因能力不足而选择分布式架构的必要。这里更多的是需要考虑多种因素，来做这样的选择.1 .业务诉求随着金融机构业务逐步互联网化，很多敢态的业务需要底层数据库提供更好的弹性、更大规模承载力，此时可考虑采用分布式架构.2 .技术诉求技术诉求这里主要来自两个方面，存储与计
23、算.一方面是存储能力的不足，希望通过分布式架构提供的水平扩展能力，满足海房数据存储；一方面是计算能力的不足，希望分布式架构引入更多计凭资源参与其中.3 .风险诉求分布式架构因其自身架构设计特点，在高可用、数据一致性等方面，较集中式架构有优势,有这方面诉求的可考虑分布式.4 .成本诉求这点非针对分布式，主要是因为国外大型商业数据库经济成本较高，该选择国产库可相对降低成本投入。但因为国产库集中式架构承载力相对受限，因而考虑分布式架构.5 .发展诉求从更为长远的技术演进路线角度考虑，引入分布式架构做长期储备.6 .政策诉求为晌应国家或监管部门要求，而采用国产库进而使用到国产分布式数据库.28、数据库
24、迁移过程中的应用侧改造内容？1 .应用侧改造内容应用侧需改造内容，分为几个方面：数据处理逻辑这方面指使用数据座的业务逻辑，简单分为结构改造和语句改造.部分情况，可通过简单的Mapping方式去解决，但还有些需要重构逻娼，甚至重新设计结构来完成,有些特别豆杂的或存在数据库端无法实现的逻辑，就需要第二方面完成.应用处理逻辑针对不易处理的逻辑，需要拆分到应用侧解决或者使用其他数据座能力（如引入数据分析）来解决.应用迁移逻辑为满足后面平滑迁移需求，有时是需要在应用侧做些改造，例如同时适配多种数据源，实现应用级双发来保证数据一致等.2 .应用平滑迁移简单的可通过三方系统，湎足时数据迁移、同步需求,在窗口
25、期可满足情况卜.,可实现相对的平滑,当然肢好的方式,还是在业务恻通过双发逻辑实现迁移.可根据业务特点，定制迁移方式，满足平滑性要求，29、国产数据库生产环境基础硬件架构是怎样的？国产数据库自身对基础硬件环境要求和国外产品无本质差别。对于分布式架构产品而言，有一定特殊性，受限于其架构特点，各组件对CPU、10、NET要求各不同。例如，通常对网络要求较高，分布式组件间竟要大量通信；数据节点建议使用SSD（甚至是NVMeSSD）.国产化诉求，对基础环境也提出新的要求。主要是CPU方面，对ARM产品有部分需求.30、数据库国产化方案的方案可行性确认？评估可行性，可从多个角度并遵循一定步躲,例如下：理论基础听取厂商的理论讲述，从原理上了解产品能力.必要时，可引入外脑帮助决策.功能评测可要求厂商提供基明功能测试报告，同时根据自有场景需求，挑选有代表性场景进行评测.案例考察考察与自有业务类似的其他客户进行考察，了解其使用情况.核心演练针对关注的核心要点（如高可用、迁移、性能）等，可安排专项演练。
