与国产数据库相关的热点问题解读.docx

《与国产数据库相关的热点问题解读.docx》由会员分享，可在线阅读，更多相关《与国产数据库相关的热点问题解读.docx（13页珍藏版）》请在第一文库网上搜索。

1、与国产数据库相关的热点问题解读1、如何结合不同的业务场景选择合适的数据库？22、业务系统应用架构设计时如何适配分布式数据库以实现高性能，在线扩展后性能如何同步提升？23、分布式数据库故障时如何确保故障自动转移，自动恢复业务，实现高可用？.34、分布式数据库全局一致性和高性能如何取舍达到平衡？35、中小银行后端稳态类系统进行分布式方向改造的必要性？36、是否有适合银行业务场景的O1TP基准测试？47、关于国产分布式数据库未来趋势分析？48、面对这么多国产分布式数据库，如何制定一个选型标准？49、在分布式数据库架构选型中，如何看待计算与存储分离？410、分布式数据库容灾容错方案？411分布式数据库

2、使用规则？512、分布式数据库如何选型？513、有成熟的国产数据库产品替代OraC1e、Db2数据产品吗？514、国产数据库如何实现在正式库中进行测试？615、国产分布式数据库，在成本上是否如宣传的那样比OraCIe有较大的优势？.616、NeWSQ1分布式数据库有哪些缺陷？617、国产数据库去0,是用基于PG产品，还是考虑基于MySQ1产品合适？718、数据迁移如何保证前后一致性？719、目前国产化分布式数据库产品繁多，对O1TP数据库在去0转向国产化该如何做选型评估？720、在核心业务系统方面去0转向国产化数据库产品有哪些典型案例？821、目前国产数据库有哪些自研的迁移工具或软件，迁移的停

3、机时间是多少？.822、去0国产中面对的存储过程、函数等如何处理？923、国产数据库迁移中应用改造量的评估？924、有没有数据库综合管理平台推荐？925、将商业数据库OraCIe、DB2、SQ1SerVer上的应用，迁移到国产数据库，有哪些风险点？1026、用户对自己的信息化都不了解的情况下。如何去更快的了解企业的数信息化数据库业务？1127、国产数据库选型集中式与分布式如何选取？1128、数据库迁移过程中的应用侧改造内容？1229、国产数据库生产环境基础硬件架构是怎样的？1330、数据库国产化方案的方案可行性确认？131、如何结合不同的业务场景选择合适的数据库？在做出合适选择之前，需要以下准

4、备工作：1 .业务画像针对不同的业务，做出业务侧的数据库画像，包括但不限于如下维度： 业务指标：使用方式、使用特征（在线用户、峰值用户、并发用户等）、重要级别、可用性要求。此外，针对未来发展也要有所评估。 系统指标：包括应用系统来源、技术栈、开发语言、系统拓扑、与数据库交互方式等 数据库指标：包括数据规模、访问特征、物理环境、软件环境、数据库拓扑等 运行特征：场景分类（TP、AP、混合）、架构分类、数据规模、数据特征、计算规模、事务一致性要求、扩展性要求、高可用要求、应用耦合性等2 .产品测试对数据库产品进行测试，形成对产品的统一认识。这其中包括数据库内核、管理、开发、安全等多方面能力的评估。

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

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

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

8、动（监管方明确需求） 技术驱动（为适配技术栈革新）管理驱动（从统一管理等角度考虑）这里需权衡分布式改造所带来的投入产出比及对应的风险评估。个人建议，中小型银行的稳态业务，不一定非要做分布式改造，需要做更严谨的评估。6、是否有适合银行业务场景的O1TP基准测试？目前没有统一的O1TP测试标准，其原因是银行的业务也各有不同，很难找到统一标准。一般的做法是找出部分有代表性的业务，简化提炼后形成一个测试case。在测试中，通过不同测试CaSe的组合，形成满足某业务的测试集。7、关于国产分布式数据库未来趋势分析？目前尚处于早期阶段，趋势发展上还不是很明朗。个人有以下一些判断：1多技术路线会长期共存；2

9、.云会在未来达到统一，但周期会很长；3 .MySQ1PG会成为事实生态标准，各产品会加以适配。8、面对这么多国产分布式数据库，如何制定一个选型标准？关于选型标准，目前没有统一国家、行业标准，有条件的企业都在做自有标准。按照之前的工作，需梳理出选型测试的众多评估维度及细化的指标。这里是存在不小的工作量。这里可参考我近期发的一些内容：分布式数据库评估维度分析。9、在分布式数据库架构选型中，如何看待计算与存储分离？存算分离，还是要看具体解决的问题。其最早是由云厂商提出的，目的是将资源解耦，从而实现不同资源的分层扩缩。看待这个特性，还是要看其背后带来的收益，是否是自身关注的；否则没有太大意义。10、分

10、布式数据库容灾容错方案？高可用方案，各家产品实现有所差异。一般情况下，在同城双中心异地单中心的情况下，当同城某AZ出现问题时，是无法自动切换到同城第二个AZ,是需要引入第三个AZ,满足仲裁需求的。当然有些是可以写死切换逻辑在里面，但非标准的切换流程。因此，一般建议在同城采用3AZ,满足多数派选举，可实现自动切换能力。异地一般不建议参与其中，毕竟存在较长时延。11、分布式数据库使用规则？分布式数据库较传统单机数据库或集中式数据库，是存在较多不同，因此在开发之处就有针对性的进行规避比较重要。这其中常见的点包括：事务大小、SQ1复杂度、分布式事务、DD1变更等。基本的处理原则就是3B原则，即避免Bi

11、gSQ1、BigTransactionBigBatch0此外,尽量减小分布式数据库中的变更，无论是架构上的（如扩缩容）、结构上的（如DD1）等。12、分布式数据库如何选型？通常不会根据每套应用来选择合适的数据库，这样做的话技术栈可能过于发散。建议的做法是，根据公司业务场景，收敛为若干种类型，然后为每个类型选择23款产品。选择多款产品的原因，是为了避免厂商绑定问题。然后需要根据每类场景，制定开发规范（取23款产品的功能交集作为标准）。13、有成熟的国产数据库产品替代OraCIe、Db2数据产品吗？替代OraCIe或DB2的产品，可分为几种类型：1 .核心业务此类业务特点是数据规模大、并发高、延迟

12、要求低，但数据库使用场景较为简单。通常这种方式可使用业务侧单元化+国产库方式。这种方式对库的要求相对不高，可选择的范围较广。2 .中型业务此类业务特点是数据规模中等，数据库使用复杂度。这种方式要想很好地替代，相对较难。一般建议的做法是重构。当然这里需要考虑的改造成本比较高。可考虑的选型范围是NeWSQ1系列产品。3 .小型业务此类业务特点是数据规模较小，复杂度不低。这种系统数量众多，可考虑是使用对（）rac1eDB2兼容性较高的产品。如很多从PG衍生的产品或国内部分数据库产品。14、国产数据库如何实现在正式库中进行测试？库内测试的问题，一般不是通过数据库端实现的，可通过互联网通常采用的影子库方

13、案来解决。也有一些开源产品（如Shardingsphere）,内置了这一能力，通过在上层模拟出数据库的统一入口，内部设置分流、限流策略，来完成压测工作。15、国产分布式数据库，在成本上是否如宣传的那样比OraCie有较大的优势？采用分布式数据库的成本来自几个方面： 软件授权费用：这部分相对有一定优势，OraC1e原厂费用较高。 软件服务费用：这部分相对国产库较高，因为成熟度不足，还需大量人力投入且还未形成成熟的服务生态 硬件采购费用：这部分分布式国产库较高，因为涉及的组件较多，需耗费机器资源较多。 日常维护费用：这部分国产库较高，因需重新搭建队伍，新增人力成本较高。16、NeWSQ1分布式数据

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

15、品，在OraCIe兼容性上做了了大量工作。对用户来说，使用上与OraCIe更为相近，甚至大部分可以做到无缝迁移；少部分需要修改上，也相对工作量不大。 MySQ1类产品，流行程度更高，但与OraCIe相比，功能差异较多。如在去。中选用，需做较大的修改。18、数据迁移如何保证前后一致性？数据迁移后，前后环境处于静态切面，做数据对比是比较简单的。操作上可有几种方式： 自研-数据可通过SQ1语句完成简单的数据对比，如记录条目数，多维度统计报告进行比对。 自研-过程可针对迁移过程中的日志的方式，通过代码提取对比。这种方式对目标库无影响。 外部工具有些外部产品也支持数据比对，如DSG的SUPerSynC等问题：数据比对的核心问题是效率，需找到一种平衡。19、目前国产化分布式数据库产品繁多，对O1TP数据库在去0转向国产化该如何做选型评估？可分为几种情况： 兼容性评估这与去O的路线有关，如考虑尽量减少去O的应用迁移难度，选择兼容OraCIe的产品，则兼容性需要重点评估。OraCIe的功能非常丰富，目前国产化产品无法做到全部兼容，对于分布式数据库而言，这点更为突出。 产品评估除去上