在政策和技术的双重背景下，企业面临自主可控的压力迫在眉睫。数据库作为生产环境最重要的组件之一，是自主可控的重中之重，也是这项工作中最难处理的环节。而面对纷繁复杂的数据库厂商和产品，究竟该如何选择？如何进行产品选型以适配本公司业务需求？如何在技术先进性和稳定兼容性之间取得平衡？数据库自主可控落地当前没有通用的行业参考，大多数企业缺少同业经验指导，可能发生选型错误，迁移过程中困难重重，成本升高，项目延后等风险。
云原生应用创新实践联盟通过课题方向专家组在“数据库自主可控方向”的课题研究，帮助企业加强对自身需求认知、选择合适的自主可控数据库产品、提高对自主可控数据库迁移改造工程的认知。从选型评估、迁移改造、持续运维等各个环节总结经验，帮助企业少走弯路，高效克服难题。重点内容包括 选型方法论和评估标准、迁移方法论和难点剖析、如何建设新产品新技术的可持续性高效运维。
国产数据库选型评估体系建设经验参考
执笔专家
云原生应用创新实践联盟——数据库自主可控方向课题组专家。数据库专家，有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。曾担任多家公司首席DBA、数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎，精通多种关系型数据库，对NoSQL及大数据相关技术也有涉足，实践经验丰富。曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。
顾问专家
云原生应用创新实践联盟——数据库自主可控方向课题组组长。具有丰富的数据库环境问题诊断和性能调优的经验。在数据库同城双活，集群，多分区，分布式等项目实施上具有丰富的经验。现任职于某股份制银行科技部，工作致力于数据库同城双活架构建设，数据库分布式架构建设和数据库智能运维（AIOps 方向。对于如何将AI技术运用在运维领域具有浓厚的兴趣和创新热情。
卢丽欢 数据库自主可控用户委员会委员
云原生应用创新实践联盟——数据库自主可控方向课题组专家。张家港农商银行系统运维经理，长期从事数据库尤其是分布式数据库应用实践工作，具备银行核心系统、互联网聚合支付系统、信贷系统、中间业务等银行关键业务系统采用国产分布式数据库落地实践经验。
针对分布式数据库的发展路线，大体可分为两种
这种架构是从中间件路线演进而来。其架构采用存储与计算分离架构，底层采用标准单机数据库，副本间基于数据库主从复制机制，通过上述机制完成数据存储。上层由多个独立的、无状态的节点来承担计算，并可将部分计算下推到存储节点执行。这种架构在分布式事务、全局MVCC等方面，往往存在一定难点，各厂商也有各自解决之道。
这种架构正是受到Google论文影响演进而来。其采用存储与计算分离架构，底层采用单机库(不一定是关系型)，副本间采用分布式一致性协议完成复制，支持多数派提交。上层承担计算，并可将部分计算下推到存储节点执行。
针对不同的场景，不同分布式数据库路线产品各有所长。
针对事务类场景下，强调高并发联机交易、对分析能力要求不高的场景比较适合分布式中间件路线产品。
针对事务类及事务/分析混合类场景，既要满足常规联机交易场景的同时，还需满足分析类的一部分能力，这种情况比较适合原生分布式产品。基于原生分布式的 HTAP 数据库，用一个数据平台应对规模化交易和实时分析，提升业务决策的时效性，降低数据技术栈的复杂性，越来越多的混合负载需求推动了 HTAP 在金融场景的落地。
针对不同技术路线产品，在具体评估工作中，需要根据业务特点挑选出主要关注指标进行评估。下面通过两个示例说明这一过程。
流水型系统实现实时支付、证券交易、订单等业务的发起方和接收方之间的转接功能。典型的流水型系统是银行渠道系统、转接清算系统、非银行支付机构的快捷支付（协议支付 系统等。对于此类系统，业务请求和业务请求响应需要实时转发至业务发起方和业务接收方，对系统的实时性有较高的要求，但关键数据（如交易涉及的账户数据 的一致性由业务发起方和接收方保证，流水型系统对业务的流水信息进行记录。流水型系统的幂等性处理是架构设计的重点和难点，可采用多层幂等保障机制，如用户发起业务流量环节幂等、实时业务处理环节幂等、交易对账环节幂等。
此类业务系统重点关注的指标之一是对对于实时性，即在规定的时间内完成交易。对应数据库应提供持续、稳定的服务响应能力。例如99线在xx毫秒内完成，即99%以上的交易需要在多少毫秒内完成。其不允许出现所谓毛刺现象，需要非常稳定。从这个角度出发，可针对备选产品从时延及稳定性做好充分评估。根据过往经验，分库分表类产品在这方面表现更为突出，其避免了NewSQL架构产品在数据合并、迁移、重分片过程中可能造成的影响。其响应链路简单，可保证效率，提供较为稳态的服务。
账户型系统主要实现账户信息、用户信息等业务数据的处理和记录。此类系统需要优先保障关键数据的一致性。数据一致性是架构设计的重点和难点，应结合业务模型选择解决方案，如关键数据采用同步复制等手段、将只读数据和可写数据分离、业务处理层与数据存储层协调工作等。通常可采用单元化处理，将账户拆分到多个部署单元，并行进行账务处理。当故障发生时，只有部分账户受到影响。
此类系统关注的重点在数据一致性及可靠性。这点对于分布式架构下，带来了更多的挑战。需要对应数据库系统在分布式事务能力及全局数据一致性方面有着更好的表现。通常来说，NewSQL类产品在这方面表现更为优秀，主要是基于其重新构造的一致性实现。此外，这类产品在数据拆分粒度上更细且使用分布式共识算法，可提供更有保障的数据安全支持。
技术是为业务服务的，不能为了使用技术而使用，需要综合考虑成本和收益的平衡。分布式数据库在数据大规模、高并发、高可用性等场景下有其特有优势。一般的业务场景如果能用单机数据库支撑的尽量用单机库。选择一款分布式数据库，会带来一系列的成本，如应用适配成本、运维成本、硬件成本等。在具体的选型评估过程中，可参考下面的问题
针对分布式数据库不同路线，其架构有其天然的优势与劣势。这点是需要有独立评估。
分库分表
这一架构产品的优势在于功能丰富、可按业务做定制；稳定性较高，基于成熟稳定的单机引擎。在面对超大规模数据存储，通过灵活的分片配置策略，支持高灵活度数据打散技术，并可贴近场景需求定制分片。相对不足在于全局事务能力、全局MVCC、副本控制、高可用等方面存在先天短板，需要有针对性增强。例如引入全局事务管理器组件，突破单机限制，实现分布式事务的实时一致性及全局MVCC能力，对应用透明的分布式事务处理，应用无需改造。通过本地一阶段提交+自动补偿机制，提升分布式事务处理性能。针对数据强一致性的要求，在单机库同步技术基础上，通过内核级的增强优化实现更高级别的复制保证数据不丢失。此外，由于需维护多节点一致性而带来的在跨分片DDL、分片节点扩容、跨节点复杂查询、全局一致的备份恢复等方面问题值得关注。
原生分布式
分布式的原生实现，工程上不依赖其他产品，可控程度更高。面对很多新的需求，可从底层加以实现支持，不受限于第三方。在副本控制、数据一致性、容灾、弹性能力等方面更具有优势。此外，场景方面有更为灵活的选择及未来可扩展的空间。劣势在于产品成熟度，仍需较长时间沉淀。特别是使用在核心业务场景，仍然需要较长时间的锤炼。此外，其内置的分片规则，对于某些需贴合业务的架构设计不太友好。对于高并发、低延迟的极端场景仍然有一定局限。
软件规划和部署方案
分布式数据库组件众多，而且每个组件都有高可用备份，所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡，GTM作为分布式数据库的瓶颈尽量和他们组件分开部署。
监控方案
监控一般可以采用开源的Zabbix进行定制化开发，当然也可以基于Grafana+Prometheus的方案做监控。但一般大中型金融企业都有一套自己的监控系统，这里需要有个对接适配的过程。此外，由于分布式的多组件特点，在监控指标数量及指标间关联上，与传统数据库差异巨大，是需要监控摸索过程。
语句调优
因为不同厂商研发的数据库SQL优化器及执行计划都有所不同，所以要根据不同产品进行学习。天然由于分布式架构带来的复杂度，也会影响到语句的执行效率。比较常见的如数据库访问链路长所带来的的问题、数据分布不均带来的问题及分布式优化器的问题等。
备份方案
分布式数据库如何做到多节点全局一致性备份也是难点，要做到真正意义上的基于时点恢复，就需要做到分布式环境下每个全局事务的可追溯操作。
应急方案
因为分布式数据库还处于发展阶段，还不成熟，技术比较复杂，所以生产环境下要制定详细的应急方案，让不了解分布式数据库的同事也能够在出现问题时按照手册操作。
结构变更
在分布式架构下，结构变更是个难点。如果做到全局一致，做到业务无感知，是核心点。不同厂商产品实现能力参差不齐，介于此安排在低峰期操作并做好必要的监控回退。
水平扩容
分布式架构下，都是支持水平扩容的。一般来说，非数据节点的扩容是相对容易的，对业务也是无感的，但涉及到数据节点的扩容，势必会遇到数据reshard的问题。建议选择在低峰期，同时控制好扩容粒度。即便如此，仍然建议提前做好容量规划，避免扩容。
跨片计算
分布式架构下，数据是分布在多个节点中。如果数据计算是可以在本地计算完成，无疑是效率最高的，但完全避免跨片计算是不太现实的。如果发生跨片计算，则不可避免地对上层节点带来压力，要做好相应监控，并争取在根本上避免跨片类计算。
分布式数据库较传统单机数据库 集中式数据库，是存在较多不同，因此在开发之处就有针对性的进行规避比较重要。这其中常见的点包括 事务大小、SQL复杂度、分布式事务、DDL变更等。基本的处理原则就是3B原则，即避免Big SQL、Big Transaction、Big Batch。其出发点是基于尽量简化对数据库的使用，提高数据库运行效率；并保留未来架构更换的可能。此外，尽量减小分布式数据库中的变更，无论是架构上的（如扩缩容 、还是结构上的（如DDL 等。在具体工作上，包括
数据处理逻辑
简单分为结构改造和语句改造。部分情况，可通过简单的Mapping方式去解决，但还有些需要重构逻辑，甚至重新设计结构来完成。有些特别复杂的 存在数据库端无法实现的逻辑，就需要第二方面完成。
应用处理逻辑
针对不易处理的逻辑，需要拆分到应用侧解决 者使用其他数据库能力（如引入数据分析 来解决。
应用迁移逻辑
为满足后面平滑迁移需求，有时是需要在应用侧做些改造，例如同时适配多种数据源，实现应用级双发来保证数据一致等。
分布式数据库不依赖于特有硬件，标准X86服务器 者国产化服务器即可，存储多为本地存储即可，推荐使用SSD甚至是NVMe SSD，网络一般万兆网络即可。在这部分主要成本是取决于集群规模、数据量及数据库自身架构。此外，如果涉及到灾备方案，还需要考虑灾备环境的硬件 入及主备间的专线费用。
软件成本
这部分是来自分布式数据库本身的软件采购成本，成本取决于各厂商的内部商业策略。但这部分总体来讲，是较传统数据库产品还是有优势的。此外，这部分还涉及到维保费用，针对分布式数据库来说，相对较新，企业自有能力尚不具备，还是建议购买原厂服务 其他三方公司的服务，降低风险。
开发测试成本
这部分是指针对数据库更换后，应用需要需要完成的必要的开发测试成本。这部分成本差异很大，跟原有系统实现有较大关系。如果原有系统重度依赖数据库（大量功能是基于数据库自身功能实现的 ，那么存在的改造量较大。新型分布式数据库的功能，不能与传统数据库做一一对应，很多能力是需要在应用层重构完成。针对这种情况，是建议应用开发遵循数据库标准方式进行（如采用MySQL作为标准 开发，这样如有改型也很简单。此外，还有一类隐形成本包含在这部分，如果业务比较重要，是需要考虑双发支持 灰度迁移的方式，这会带来一部分工作量。总体来说，这部分成本是比较高的，可能占整体成本的大部分。
运营维护成本
这部分成本，包括了为满足更换数据库所带来的数据迁移成本和上线后的日常维护成本。针对前者，可以在应用侧解决 者外采商业软件解决；后者更多是人员管理成本。针对这部分成本，是有个相对较长的 入，且整体成本不少。
作为底层技术基础设施的更换，还需要考虑基础资源的使用。分布式数据库通常会采用廉价X86 PC服务器，搭配本地SSD固态盘、万兆网卡，单体硬件成本较低。但在服务器数量上，需要有更多考虑。一方面分布式数据库组件众多，且每个组件都需要高可用配置，即使部分可采用混部方式解决，但在整体数量上仍然会较多。此外，还需要考虑各组件的负载模型不同、关键组件独立部署、数据多副本等等问题。另一方面，结合重点关注的性能数据、例如支持的QPS等，从而计算出服务器数量需求。需要注意的是，分布式数据库厂商提供的性能测试采用的服务器参数，一般是高配服务器，如果实际生产使用服务器配置降低，则还要考虑性能数据损耗等问题。
从技术角度来看，在数据库选型中有哪些要素需要考虑呢？下面以近期比较关注的分布式数据库的选型为例，说明下重点考量的技术要素。
分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。
由于分布式数据库通常使用的二阶段提交和各节点之间的网络交互会有性能损耗，分布式数据库优势不是单个简单SQL的性能，而是大数据量的SQL查询，每个节点会将过滤之后的数据集进行返回，会提升性能，并且分布式数据库的优势是并发，大量的SQL并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会受到影响。建议尽量改造存在跨节点数据流动的SQL语句（主要是多表关联 的事务。
分布式数据库的一致性保证通过内部时钟机制所提供的全局时间 ，所有节点都会遵循该机制，所以备份恢复的增量也是基于全局时间 ，但是分布式数据库的备份解决方案最重要的标志为是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐大很多，还有就是是否支持一些分布式备份方案，比如S3协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志 ，恢复的时候指定节点进行恢复到指定时间点，整个过程可配置自动任务、自动执行。
分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署。如果同城主备可以采用集群级的异步复制，异地建议采用集群级的binlog异步复制，建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件T+1恢复到异地灾备。
分布式数据库大多都是通过获取全局时钟时间 ，采用二阶段提交，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。部分分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间 的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。
分布式数据库，多采用存算分离架构。针对数据分析场景，需要对数据从下层存储节点上移到计算节点，这对分布式数据库提出了更高的要求。一方面可通过算子下推等技术，减少需传输到计算节点的数量；一方面针对汇聚后的结果需要通过流式处理等方式，规避诸如OOM的问题；此外也可采用如MPP等并行处理技术，加速数据分析过程。
引入一种新架构，势必会带来一系列的改造适配工作，此时对选型产品的兼容性提出了跟高的要求。一方面要求对复杂业务逻辑问题，包括数据库技术基因匹配性（如 数据库本身锁机制、隔离级别问题 ，包括技术兼任性（如存储过程、视图兼容性 ；另一方面是对应用的适配度问题，传统应用大多基于单机关系型数据库机制设计的，例如大部分场景都是串行机制，发挥不出来分布式数据库的强大并发处理技术，反而分布式数据库本身的二阶段提交机制，对简单事务的延时增加问题，造成串行事务执行性能低下等。
分布式数据库，作为数据库发展的趋势之一，近些年来发展迅猛。其在应对海量数据规模、高并发数据访问、混合业务负载支持、弹性可伸缩等方面，有着明显的优势；正在被越来越多的用户所接纳。然而，作为一种尚在高速发展阶段的新兴技术，其发展路线还未收敛，存在诸多未来发展变数。用户在做数据库选型中，需要做更多角度的评估来规避风险。此外，作为底层基础设施，数据库的更换涉及到架构、研发、运维等诸多方面，如何做好科学、严谨、规范、全面的评估非常重要。本文就技术路线、评估维度、技术要点等为切入点，描述分布式数据库选型的诸多要点，为数据库从业者的科学选型提供参考。
此内容为“云原生应用创新实践联盟——数据库自主可控方向课题组”中用户专属内容，更多内容可扫描下方二维码查看，申请 “云原生应用创新实践联盟”后可以获取课题组全部内容阅读权限。
云原生为企业数字化转型提供了强大助力，企业越来越多的重要生产业务将迁移至云原生环境。大中型企业IT系统面临以云原生为秩序进行重构。当前，企业IT正处于重构的阵痛期。在信息缺失、矛盾、污染的情况下，用户决策难度大、风险高，严重威胁企业安全生产和 资保护。在众多行业用户强烈呼吁和牵引下，由twt代表用户群体成立“云原生应用创新实践联盟”。联盟聚集各行业先进企业用户专家成立课题专家组，课题专家组与行业用户群体充分协作，集众智、汇众力，为行业用户提供项目落地可信、可靠、可用的关键决策工具和应用参考，最终帮助行业企业群体性地改善云原生应用过程中的困难态势、加速实现数字化转型。
Powered by 小羊羔外链网 8.3.12
©2015 - 2024 小羊羔外链网
您的IP:3.144.84.155,2024-04-26 01:42:34,Processed in 0.05294 second(s).
