1、如何结合不同的业务场景选择合适的数据库？
在做出合适选择之前，需要以下准备工作：
1. 业务画像
针对不同的业务，做出业务侧的数据库画像，包括但不限于如下维度：
-
业务指标：使用方式、使用特征（在线用户、峰值用户、并发用户等）、重要级别、可用性要求。此外，针对未来发展也要有所评估。
-
系统指标：包括应用系统来源、技术栈、开发语言、系统拓扑、与数据库交互方式等
-
数据库指标：包括数据规模、访问特征、物理环境、软件环境、数据库拓扑等
-
运行特征：场景分类（TP、AP、混合）、架构分类、数据规模、数据特征、计算规模、事务一致性要求、扩展性要求、高可用要求、应用耦合性等
2. 产品测试
对数据库产品进行测试，形成对产品的统一认识。这其中包括数据库内核、管理、开发、安全等多方面能力的评估。这方面可参考我之前分享的《分布式数据库评测标准》。
3. 其他因素
除上述外，还应包括企业内部的一些自身因素的考虑，如成本、运维、开发改造等因素。
上述因素综合考虑后，才能做出相对合理的选择。
2、业务系统应用架构设计时如何适配分布式数据库以实现高性能，在线扩展后性能如何同步提升？
-
性能问题，是需要慎重考虑的。如果仅仅考察个体的表现，分布式数据库很有可能不如传统单机数据库或集中式数据库。其分布式架构在原理就先天存在一些短板，对于要求极致性能的场景是不合适的。
-
分布式数据库的强处，是在于扩展系统的整体吞吐能力，可承载更多的业务量。因此从原理上讲，扩展后不会提升性能。当然，分布式系统扩展后，数据库被做个更多的拆分，会有助于单体执行效率的提升，这种情况下是有性能提升的。
基于上面，在应用架构设计时，应充分利用分布式数据库的数据分布特点，做好业务单元化。通过在更小的数据单元完成，进而达到优化效果。
3、分布式数据库故障时如何确保故障自动转移，自动恢复业务，实现高可用？
分布式库的组件较多，大致可分为数据节点、计算节点、控制节点三类角色。其中，计算节点一般为无状态的，故障后可切换自动恢复；控制节点一般采用自身高可用保障，出现问题会主动自愈；数据节点出现问题时较为重要，因为其上面承载的数据。我理解问题主要是对应这一角色。针对数据节点，不同分布式数据库产品，底层实现有所差异，大致可分为两种情况：
1.基于单机数据库的主从复制模式
2.基于多数派协议保证的多副本模式
无论是哪种模式，当出现故障时都会完成自动选主，自动切换，从而实现高可用。目前的大部分产品，都已可实现在同AZ、同城跨AZ的自主切换、对业务无感（业务需实现出错重试机制）。针对异地的情况，一般还是建议人工介入，而不自动完成切换。
4、分布式数据库全局一致性和高性能如何取舍达到平衡？
个人觉得这两者不存在平衡关系，一般一致性要求是来源于业务，很难去做业务上的取舍。都是在有明确一致性要求的情况下，尽量做到性能最好。
5、中小银行后端稳态类系统进行分布式方向改造的必要性？
分布式改造的必要性，主要来自于几个方面：
-
业务驱动（数据规模、算力不足等需要扩展）
-
政策驱动（监管方明确需求）
-
技术驱动（为适配技术栈革新）
-
管理驱动（从统一管理等角度考虑） 这里需权衡分布式改造所带来的投入产出比及对应的风险评估。个人建议，中小型银行的稳态业务，不一定非要做分布式改造，需要做更严谨的评估。
6、是否有适合银行业务场景的OLTP基准测试？
目前没有统一的OLTP测试标准，其原因是银行的业务也各有不同，很难找到统一标准。一般的做法是找出部分有代表性的业务，简化提炼后形成一个测试case。在测试中，通过不同测试case的组合，形成满足某业务的测试集。
7、关于国产分布式数据库未来趋势分析？
目前尚处于早期阶段，趋势发展上还不是很明朗。个人有以下一些判断：
1.多技术路线会长期共存；
2.云会在未来达到统一，但周期会很长；
3.MySQL、PG会成为事实生态标准，各产品会加以适配。
8、面对这么多国产分布式数据库，如何制定一个选型标准？
关于选型标准，目前没有统一国家、行业标准，有条件的企业都在做自有标准。按照之前的工作，需梳理出选型测试的众多评估维度及细化的指标。这里是存在不小的工作量。这里可参考我近期发的一些内容： 分布式数据库评估维度分析。
9、在分布式数据库架构选型中，如何看待计算与存储分离？
存算分离，还是要看具体解决的问题。其最早是由云厂商提出的，目的是将资源解耦，从而实现不同资源的分层扩缩。看待这个特性，还是要看其背后带来的收益，是否是自身关注的；否则没有太大意义。
10、分布式数据库容灾容错方案？
高可用方案，各家产品实现有所差异。一般情况下，在同城双中心异地单中心的情况下，当同城某AZ出现问题时，是无法自动切换到同城第二个AZ，是需要引入第三个AZ，满足仲裁需求的。当然有些是可以写死切换逻辑在里面，但非标准的切换流程。因此，一般建议在同城采用3AZ，满足多数派选举，可实现自动切换能力。异地一般不建议参与其中，毕竟存在较长时延。
11、分布式数据库使用规则？
分布式数据库较传统单机数据库或集中式数据库，是存在较多不同，因此在开发之处就有针对性的进行规避比较重要。这其中常见的点包括：事务大小、SQL复杂度、分布式事务、DDL变更等。基本的处理原则就是3B原则，即避免Big SQL、Big Transaction、Big Batch。此外，尽量减小分布式数据库中的变更，无论是架构上的（如扩缩容）、结构上的（如DDL）等。
12、分布式数据库如何选型？
通常不会根据每套应用来选择合适的数据库，这样做的话技术栈可能过于发散。建议的做法是，根据公司业务场景，收敛为若干种类型，然后为每个类型选择2~3款产品。选择多款产品的原因，是为了避免厂商绑定问题。然后需要根据每类场景，制定开发规范（取2~3款产品的功能交集作为标准）。
13、有成熟的国产数据库产品替代Oracle、Db2数据产品吗？
替代Oracle或DB2的产品，可分为几种类型：
1.核心业务
此类业务特点是数据规模大、并发高、延迟要求低，但数据库使用场景较为简单。通常这种方式可使用业务侧单元化+国产库方式。这种方式对库的要求相对不高，可选择的范围较广。
2.中型业务
此类业务特点是数据规模中等，数据库使用复杂度。这种方式要想很好地替代，相对较难。一般建议的做法是重构。当然这里需要考虑的改造成本比较高。可考虑的选型范围是NewSQL系列产品。
3.小型业务
此类业务特点是数据规模较小，复杂度不低。这种系统数量众多，可考虑是使用对Oracle/DB2兼容性较高的产品。如很多从PG衍生的产品或国内部分数据库产品。
14、国产数据库如何实现在正式库中进行测试？
库内测试的问题，一般不是通过数据库端实现的，可通过互联网通常采用的影子库方案来解决。也有一些开源产品（如shardingsphere），内置了这一能力，通过在上层模拟出数据库的统一入口，内部设置分流、限流策略，来完成压测工作。
15、国产分布式数据库，在成本上是否如宣传的那样比Oracle有较大的优势？
采用分布式数据库的成本来自几个方面：
-
软件授权费用：这部分相对有一定优势，Oracle原厂费用较高。
-
软件服务费用：这部分相对国产库较高，因为成熟度不足，还需大量人力投入且还未形成成熟的服务生态
-
硬件采购费用：这部分分布式国产库较高，因为涉及的组件较多，需耗费机器资源较多。
-
日常维护费用：这部分国产库较高，因需重新搭建队伍，新增人力成本较高。
16、NewSQL分布式数据库有哪些缺陷？
主要缺陷取决于不同库的架构，这点差异很大。重点可考察：
-
分布式事务、全局一致性
-
全局日志，数据唯一性
-
同城&异地高可用
-
生态功能（如针对研发）
-
管控能力（管理、优化、监控等）
17、国产数据库去O，是用基于PG产品，还是考虑基于MySQL产品合适？
在去O过程中，我们先明确一点，没有数据库产品是可以完全替代的。即完成去O工作，是需要通过"应用改造+数据库选型+应用迁移"，结合在一起才能完成。这里需要考虑整体目标及路径。问题中的两种方式，原则上都是可以完成去O工作，但对于应用改造及迁移的影响差异较大。
-
PG类产品，其企业级功能较为完善，使用体感与Oracle相近。有些基于PG为内核的产品，在Oracle兼容性上做了了大量工作。对用户来说，使用上与Oracle更为相近，甚至大部分可以做到无缝迁移；少部分需要修改上，也相对工作量不大。
-
MySQL类产品，流行程度更高，但与Oracle相比，功能差异较多。如在去O中选用，需做较大的修改。
18、数据迁移如何保证前后一致性？
数据迁移后，前后环境处于静态切面，做数据对比是比较简单的。操作上可有几种方式：
-
自研-数据
可通过SQL语句完成简单的数据对比，如记录条目数，多维度统计报告进行比对。
-
自研-过程
可针对迁移过程中的日志的方式，通过代码提取对比。这种方式对目标库无影响。
-
外部工具
有些外部产品也支持数据比对，如DSG的super sync等问题：数据比对的核心问题是效率，需找到一种平衡。
19、目前国产化分布式数据库产品繁多，对OLTP数据库在去O转向国产化该如何做选型评估？
可分为几种情况：
-
兼容性评估
这与去O的路线有关，如考虑尽量减少去O的应用迁移难度，选择兼容Oracle的产品，则兼容性需要重点评估。Oracle的功能非常丰富，目前国产化产品无法做到全部兼容，对于分布式数据库而言，这点更为突出。
-
产品评估
除去上面因素外，就是从数据产品本身维度进行测试。这里涉及的测试点很多，具体细节可参考我之前的社区文章。
20、在核心业务系统方面去O转向国产化数据库产品有哪些典型案例？
各家在去O场景上，案例还是很多的，包括部分股份制银行、城商行等。如中信、平安、张家口商业、亿联、北京银行等。
从未来趋势来看，目前国内去O尚未形成较为主流的实现路线，各家策略均有不同。从技术路线来看，也未达到形式上的统一。因此建议金融企业，根据自身特点，选择更为通用性的标准作为迁移依据。即从应用角度入手，重点考虑兼容标准开发模式，忽略个体产品差异。对未来不同路线，保持充分的灵活性。
21、目前国产数据库有哪些自研的迁移工具或软件，迁移的停机时间是多少？
从上述数据库迁移到国产库，可分为两种技术路线：
-
物理迁移：基于日志
这种方式的产品很多，如国内的DSG、英方、Datapipe等
-
逻辑迁移：基于数据
这种方式的产品，开源和商业的都有，如典型的Kettle、DataX等
影响迁移的时长，主要取决于几个因素：
-
迁移逻辑：是否存在加工转换
-
数据对比：是否需做质量检查
-
数据规模/链路：一般都采用全量+增量方式，这一因素一般影响不大
22、去O国产中面对的存储过程、函数等如何处理？
国产数据库在库内计算（存储过程、函数）及特性能力（如视图），较Oracle数据库还存在一定差距。特别是采取分布式架构的国产数据库，差距更为明显。从实际推动工作上看，也是两种策略：
-
尽量选择兼容性产品，这样代价相对较小
-
简化数据库应用，将上述能力在应用层解决，数据库只做CRUD
23、国产数据库迁移中应用改造量的评估？
应用改造工作量的评估，是有一定参考依据的。之前在项目实践中，也积累些方法并形成小工具。基本原理就是根据对象和语句的数量、复杂度等作为输入，根据实践总结出的单位工时进行评估。在后续的不断迭代中，改进评估方法。
24、有没有数据库综合管理平台推荐？
该提问点出了一个迁移到国产库的共性问题，即数据库碎片化。在传统数据库选型中，主打两三款数据库，就可以覆盖几乎所有的业务场景，而到了国产库上则情况大不同。一方面数据库的架构类别多样；二方面还没形成垄断性产品，众多产品都可选择；三方面各产品能力差异较突出，都有各自的适应性场景。基于上述现状，这一问题势必会影响到企业的使用。影响的方面包括：数据库架构设计、应用开发、管理维护等多方面。我将此问题，发散回答下。
1.架构设计
不同国产库的架构差异很大，没有办法统一架构，但这方面可通过标准进行规范化。国家及行业也推出一些规范，指导企业进行架构设计。例如：针对可用性设计上面，同城3AZ成为很多分布式数据库的默认，以此才能提供自动切换能力，满足RTO=0,RPO=0的预期。
2.应用开发
应用开发方面，整体差异不大。现有主流数据库还是遵循关系建模，可利用之前的工具完成。问题比较大的是在结构设计方面，特别是分布式架构有其特点，很多传统的设计思想需要改变；SQL语句开发方面，尽量做到简洁处理，避免重度依赖国产库。这方面可使用一些数据库审核工具，辅助做些结构设计、语法开发的质量检查工作；但这方面是否有欠缺的，主要是现有工具几乎无法对各家数据库产品做到差异化审核，只能完成比较初级的检查。而厂商自有产品能力，大部分还未涉及此部分。
3.管理维护
在管理维护方面，如上面谈到的，各家产品架构差异明显，尚无法做到统一管理。虽然有些第三方厂商产品支持多种数据库平台的管理功能，但大部分是支持国外商业数据库和较为流行的开源数据库。对国产库的支持，尚比较有限。甚至大部分厂商自有产品，在这方面的能力都不太健全。因此，想实现一体化的数据库管理，困难较大。解决的方法，要么是通过自研的方式解决，要么是等待国内三方产品完善起来，要么是依赖云平台（全栈使用某云厂家产品）。
4.应用访问
在应用访问方面，是否可提供统一的访问接入也是用户比较头疼的问题。大量在数据上层应用（如审计、安全、可视化等）是无法兼容多种数据库（特别是国产库）。这方面有些第三方的数据库中间层产品，可提供一定的屏蔽能力，满足统一访问的诉求。但比较完美的不多，很多还需要二研增强。
25、将商业数据库Oracle、DB2、SQL Server上的应用，迁移到国产数据库，有哪些风险点？
从商业数据库迁移到国产库，风险是来自多方面的：
1.技术风险
国产库的功能较大型商业数据库仍存在一定差距，需要在选型时期就有清晰认识。不同国产库架构不同、技术路线各异，需要建立符合企业自身要求的评测体系。通过完善的测试，对国产库有着全面细致的了解。虽然无法做到功能一一对应，但起码要做到对功能边界清晰可控。通过上述手段，规避可能潜在的技术风险。
2.开发风险
没有能够完美替代数据库的产品，都是需要开发做一定适配性改造。此处的风险主要一方面来自国产库功能缺失带来的应用实现侧的技术难度；一方面则来自开发资源的投入。特别是当面临后者的不确定性时，风险更大。此外，还需通过引入测试完成对开发结果的验证，规避可能的处理逻辑、性能风险。
3.迁移风险
这里谈到的迁移包括数据迁移和应用迁移。针对前者，相对好处理些，通过应用逻辑或其他三方工具是完成数据的迁移工作，重点需考虑迁移后的质量对比，避免数据不一致问题。更多难点在于应用迁移，如何平滑完成迁移很重要。此外，相关的灰度、回退等迁移能力同样需要具备。而此方面，很难找到通用的平台来提供基础能力，大部分还是需要用户自研完成。
4.运行风险
数据库上线只是第一步，长期稳定运行更为重要。国产数据库普遍面临发展时间短，缺少大量线上运行积累，缺少较为成熟的运行维护体系。包括常见的监控、诊断、优化、排障、备份、高可用、升级等均需要完善支持。
26、用户对自己的信息化都不了解的情况下。如何去更快的了解企业的数信息化数据库业务？
造成这一问题的原因有多种。有些是自研的，因企业人员流失导致信息丢失；有些是采用外包方式，随着外包公司的变化消失而导致信息丢失。上述这些现象是客观存在的，解决方法无外乎两种，通过业务侧和技术侧解决，亦或是两者配合使用。
1.业务侧：需要通过文档、人员调研等方式，搜集现有系统运行情况。
2.技术侧：通过各类日志、报告等形式，收集现有系统运行情况。
27、国产数据库选型集中式与分布式如何选取？
集中式和分布式，是数据库两个大的架构类型，两者都有各自适应场景。从过去二三十年发展来看，集中式架构很好地解决了金融机构的场景问题，从技术角度来讲绝大多数场景并没有因能力不足而选择分布式架构的必要。这里更多的是需要考虑多种因素，来做这样的选择。
1.业务诉求
随着金融机构业务逐步互联网化，很多敏态的业务需要底层数据库提供更好的弹性、更大规模承载力，此时可考虑采用分布式架构。
2.技术诉求
技术诉求这里主要来自两个方面，存储与计算。一方面是存储能力的不足，希望通过分布式架构提供的水平扩展能力，满足海量数据存储；一方面是计算能力的不足，希望分布式架构引入更多计算资源参与其中。
3.风险诉求
分布式架构因其自身架构设计特点，在高可用、数据一致性等方面，较集中式架构有优势。有这方面诉求的可考虑分布式。
4.成本诉求
这点非针对分布式，主要是因为国外大型商业数据库经济成本较高，该选择国产库可相对降低成本投入。但因为国产库集中式架构承载力相对受限，因而考虑分布式架构。
5.发展诉求
从更为长远的技术演进路线角度考虑，引入分布式架构做长期储备。
6.政策诉求
为响应国家或监管部门要求，而采用国产库进而使用到国产分布式数据库。
28、数据库迁移过程中的应用侧改造内容？
1.应用侧改造内容
应用侧需改造内容，分为几个方面：
-
数据处理逻辑
这方面指使用数据库的业务逻辑，简单分为结构改造和语句改造。部分情况，可通过简单的Mapping方式去解决，但还有些需要重构逻辑，甚至重新设计结构来完成。有些特别复杂的或存在数据库端无法实现的逻辑，就需要第二方面完成。
-
应用处理逻辑
针对不易处理的逻辑，需要拆分到应用侧解决或者使用其他数据库能力（如引入数据分析）来解决。
-
应用迁移逻辑
为满足后面平滑迁移需求，有时是需要在应用侧做些改造，例如同时适配多种数据源，实现应用级双发来保证数据一致等。
2.应用平滑迁移
简单的可通过三方系统，满足对数据迁移、同步需求，在窗口期可满足情况下，可实现相对的平滑。当然最好的方式，还是在业务侧通过双发逻辑实现迁移。可根据业务特点，定制迁移方式，满足平滑性要求。
29、国产数据库生产环境基础硬件架构是怎样的？
国产数据库自身对基础硬件环境要求和国外产品无本质差别。
对于分布式架构产品而言，有一定特殊性，受限于其架构特点，各组件对CPU、IO、NET要求各不同。例如，通常对网络要求较高，分布式组件间需要大量通信；数据节点建议使用SSD（甚至是NVMe SSD）。
国产化诉求，对基础环境也提出新的要求。主要是CPU方面，对ARM产品有部分需求。
30、数据库国产化方案的方案可行性确认？
评估可行性，可从多个角度并遵循一定步骤，例如下：
-
理论基础
听取厂商的理论讲述，从原理上了解产品能力。必要时，可引入外脑帮助决策。
-
功能评测
可要求厂商提供基础功能测试报告，同时根据自有场景需求，挑选有代表性场景进行评测。
-
案例考察
考察与自有业务类似的其他客户进行考察，了解其使用情况。
-
核心演练
针对关注的核心要点（如高可用、迁移、性能）等，可安排专项演练。