随着科学技术的不断进步,计算机的计算及存储能力取得了实质性的发展,进而推动关系型数据库技术不断完善及发展。传统的集中式关系型数据库技术日趋成熟,在各行各业的核心业务系统中扮演举足轻重的作用。但我们也清楚的认识到,虽然底层硬件的能力在不断发展,数据层面却体现出“广、大、快、杂”的发展趋势,且发展速度远超底层硬件的增长速度。如何处理不断产生的大量的数据,将是摆在传统集中式关系型数据库面前的一个难题。为了解决这个难题,行业内大都采用将承载数据库的底层硬件替换成更稳定、更高计算能力的设备、分库分表、读写分离这些方案。这些技术方案虽然在一定时间内解决了部分问题,但终究只是过渡方案,且实施复杂,治标不治本,无法在数据库架构层面提供根本性的解决方案。
幸运的是,计算、存储和网络能力的快速发展,带来了高IO、低延迟的传输体验,分布式关系型数据库逐渐登上历史舞台。随着阿里、腾讯等互联网公司的高并发核心业务逐步搬移至分布式关系型数据库,分布式关系型数据库已经成了高并发业务系统的数据库重要解决方案。分布式关系型数据库系统是由若干个节点集合而成,它们通过网络联接在一起,每个节点都是一个独立的数据库系统,它们都拥有各自的数据库、中央处理机、存储,以及各自的局部数据库管理系统。因此分布式数据库系统可以看作是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统,但在物理结构上是分布式的,“形散神聚”是对分布式数据库架构组织形式最恰当的描述!
目前金融行业绝大多数核心系统的数据库依旧采用传统的集中式架构(高端小型机+集中式关系型数据库+集中式SAN存储)为主的实现方式。数据库作为IT建设必备的基础软件,集中式关系型数据库越来越不适应海量数据以及高并发环境下对数据处理能力的要求,成为整体IT建设的瓶颈。“业务+技术”双轮驱动公司发展的方式,会因为技术的滞后显得没那么协调,阻碍企业快速、健康可持续发展。随着国家战略的转变、业务规模的扩展以及IT技术水平的发展,对数据库提出了更高的要求:
传统的集中式关系型数据库在应对业务需求方面能力不足,选择分布式关系型数据库是大势所趋。各企业可根据自己的实际业务需要,决定是否对数据库进行分布式改造。下面从三方面来说明选择分布式关系型数据库的必要性,供大家参考:
任何事情都不是完美的,虽然分布式数据库能解决很多业务的问题,但对我们的开发以及运维工作带来了更多的挑战:
1、对开发的挑战:
(1) 库表结构设计:分布式关系型数据库下的库表结构设计有别于传统的集中式关系型数据库,要结合业务来重新规划分库分表的方案,采用单元化的思路来限制数据库的跨节点、跨域访问,提升处理效率。
(2) 开发思路转变:在传统数据库中常用的存储过程、触发器、外键以及序列等对象在分布式关系型数据库支持并不友好,需尽量规避。这对开发人员提出了更高的要求。以存储过程为例,开发人员应通过服务拆分及编排的方式来实现传统存储过程实现的功能,降低耦合度,便于系统移植并降低系统升级影响范围。
(3) 制定新的开发规范:为规范并提升代码质量,通常企业都会制定对应的数据库开发规划,原有的集中式数据库开发规范已经不适应分布式数据库,需要重新引入分布式关系型数据库开发规划并开发相应的脚本工具对代码进行检查来确保开发人员按照新的开发规范进行开发。
(4) 新技术学习成本:引入一个新的数据库产品,需要先了解其特点与优势,这需要开发人员持续不断的对新技术进行学习,才能充分发挥出产品优势,提升系统的运行效率。
2、对运维的挑战:
(1) 运维复杂度提升:分布式关系型数据库架构体系复杂,备份恢复技术也较集中式数据库难度更大,且分布式数据库运维标的数量远高于传统的集中式数据库。这样对于DBA而言,运维标的的运维难度和数量都有明显增加,给整体运维工作带来了更大的压力。
(2) 新技术引入及学习成本:DBA需要在实践中不断摸索并学习分布式数据库的运维技能,形成标准化运维手册,提升故障处理能力。这需要持续不断的培训投入,带来试错成本,在新架构转型的初始阶段,可能会对业务系统的稳定运行造成一定的影响。
目前市场上有开源及商业分布式关系型数据库产品,因数据库承载着企业最为核心的数据资产,数据库的高效、稳定、安全运行至关重要,所以在进行分布式关系型数据库选型时,首要的原则就是不考虑开源产品,而选择成熟、稳定的商业产品。
针对商业产品,分布式数据库的选型还需要考虑其可靠性、稳定性、可扩展性、安全性以及服务能力等诸多因素,下面就这几个方面的选型原则简述如下:
(1) 可靠性:要确保数据库产品能够保证数据不丢失,可以进行正常的备份以及恢复,当某个节点发生故障时,对用户体验无明显影响等。
(2) 稳定性:数据库与底层硬件不存在兼容性问题,可基于底层物理环境稳定运行。具备高并发环境下的应用案例,能提供稳定的数据库服务能力,提供可在线升级的能力等。
(3) 可扩展性:可通过增加计算节点来提升事务处理能力,且支持计算节点线性扩展,数据可在各个节点间均衡分布等。
(4) 安全性:支持应用到数据库的访问加密,支持多种密码策略,支持数据脱敏,访问白名单、数据库审计等。
(5) 服务能力:数据库产品提供商具备极强的产品开发能力,有标准化、体系化的产品路线图以及服务支持能力等。
基于以上原则,通过市场深度调研及分析,最终确认了技术路线的选择范围为市场上技术能力雄厚的三家厂商提供的产品。
本文并不是对三家产品做谁好谁坏的论断,而是结合企业自身的实际,来对选型的思路及具体过程进行描述,希望能对目前正在进行分布式关系型数据库选型的企业提供参考,降低选型的复杂度和工作。
市场上的分布式关系型数据库产品各有千秋,都有自己的核心技术优势,对于处于第一梯队的产品,没有最好,只有最合适。因分布式关系型数据库的选型最终是服务自身需求的,需要通过多轮的技术沟通、市场调研、用户需求讨论筛选出最适合自身需求的技术能力匹配度清单,然后按照清单对厂商的产品进行比较深入的了解及打分,以便对厂商产品有量化的评估依据。
下面为技术能力匹配度参考表单及样式(部分内容),具体内容请各企业根据自己实际情况定制:
编号 | 分类 | 能力 | 是否具备能力 | 产品名称 | 产品功能描述 | 产品依赖性 |
---|---|---|---|---|---|---|
1 | 功能要求 | 支持ACID规则, 支持分布式强一致事务,保证事务的实时一致性 | ||||
2 | 功能要求 | 支持分布式全局唯一自增标识生成 | ||||
3 | 功能要求 | 具备高效的异构数据迁移工具 | ||||
4 | 功能要求 | 可视化监控管理界面 | ||||
5 | 功能要求 | 支持JDBC,ODBC接口 | ||||
6 | 功能要求 | 支持SQL2003标准 | ||||
7 | 功能要求 | 支持在线全量备份、增量备份,支持时间点恢复 | ||||
8 | 功能要求 | 支持多种数据同步方式:多副本直接采用流复制标准协议保证数据强同步,半同步,异步多种同步级别 | ||||
9 | 功能要求 | 支持多种的数据切片技术 | ||||
10 | 功能要求 | 支持小表广播 | ||||
11 | 功能要求 | 支持并发计算:支持节点间和节点内的并发计算 | ||||
12 | 功能要求 | 支持数据重新分布过程中,业务不中断 | ||||
13 | 功能要求 | 支持简捷的数据库升级方式,在线参数修改等功能 | ||||
14 | 功能要求 | 支持读写分离,提升读写效率同一份数据的不同副本支持读写操作 | ||||
15 | 功能要求 | 支持集群级别的DDL、DML、DCL、DQL等SQL语句 | ||||
16 | 功能要求 | 支持集群级的冷备份,定时备份,支持根据备份恢复到任意时间点 | ||||
17 | 功能要求 | 数据复制能力:支持数据库集群内单表级别数据复制,可支持库级、表级向异构或同构数据库连续复制 | ||||
18 | 功能要求 | 根据数据的使用频率,可以把一部分热数据存储到SSD电子存储介质中,以此提升整个系统的I/O性能 | ||||
19 | 功能要求 | 能够将存储节点集群缩容 | ||||
20 | 功能要求 | 集群节点可以在线水平扩展提升存储和计算能力 | ||||
21 | 功能要求 | 支持多个副本数据同步(可指定也或任意多副本) | ||||
22 | 功能要求 | 支持Oracle、MySQL等不同数据库的数据平滑迁移至目标数据库 | ||||
23 | 功能要求 | 支持数据分离存储 | ||||
24 | 功能要求 | 支持数据库在线升级 | ||||
25 | 非功能性要求 | 单节点故障后其它节点可自动接管且对应用透明 | ||||
26 | 非功能性要求 | 支持MVCC多版本控制 | ||||
27 | 非功能性要求 | 支持事务隔离确保读写/写写事务不冲突 | ||||
28 | 非功能性要求 | 整个集群具备防脑裂功能 | ||||
29 | 非功能性要求 | 计算节点数据均衡分布,计算节点可以线水平扩展 | ||||
30 | 高安全性 | 从网络层面到协议层面的各级安全保障,支持应用到数据库的访问的传输加密 | ||||
31 | 高安全性 | 做到加密操作应用程序无感知 | ||||
32 | 高安全性 | 支持业界通用AES加密算法 | ||||
33 | 高安全性 | 支持内存区,存储文件透明加密 | ||||
34 | 高安全性 | 支持多种密码策略 | ||||
35 | 高安全性 | 支持安全、审计和数据管理三权分立 | ||||
36 | 高安全性 | 支持用户级别+列级别的对应用透明的数据脱敏功能 | ||||
37 | 高安全性 | 支持行列混合矩阵式权限控制 | ||||
38 | 高安全性 | 支持访问白名单控制 | ||||
39 | 高安全性 | 支持语句审计、用户审计、对象审计功能,FGA细粒度审计全方位多级别审计功能 | ||||
40 | 多活和高可用 | 存在多副本数据,当原来主节点发生故障时,备节点自动切换为主分片 | ||||
41 | 多活和高可用 | 各个计算节点都是对等不存在主备节点之分 | ||||
42 | 性能 | 可以通过增加计算节点可以提高事务处理能力 | ||||
43 | 性能 | 支持计算节点线性扩展 | ||||
44 | 性能 | 支持各个节点数据的并行导入,导出 |
S为总分
n为领域能力总数。
P为能力的权值。
V为能力分值。
Bi用于表示当前能力具备情况。如果具备该能力则取1,反之取0。
分布式关系型数据库选型必须考虑的一点是后续的实施难度,从传统的集中式数据库到分布式数据库,涉及到核心系统重新开发,工作量非常大。这时候企业可拿出急需改造的一个业务系统,针对入围产品来做一对一的改造测试,通过改造过程厂商的支持力度,改造后的功能满足情况以及系统性能来对厂商及其产品进行进一步的了解,进而对各家产品进行排序及分档。
成本包括软件许可费用、原厂技术服务、软件维保服务及关联的硬件资源投入成本。不同企业引入分布式关系型数据库的目的不同,比如我们比较关注多中心多活的实现,因此对副本数量的多少、分级存储这些会直接影响硬件投入的因素十分敏感,也是我们在成本分析上需要重点考虑的。
一个成熟的商业产品,必须要有成熟案例的支撑,这方面我们主要考虑入围的厂商是否有在大型金融机构有成熟的支撑案例,相关案例的规模以及支撑的系统类型。
为确保入围的分布式关系型数据库产品能满足企业的实际需求,POC测试是必不可少的一环,因此需要有针对性的对测试方案进行设计。测试方案的设计主要包括五大部分:
(1) 引言:对测试文档、测试背景以及测试目标进行说明。测试背景部分描述测试活动的背景,包括现状、未来预期,以及相关领域的背景信息,整理出原始需求和POC测试的对应关系;测试目标部分描述本次测试活动的测试目标,按照基本能力验证和其它特性验证的划分原则,将重要需求和一票否决项放入基本能力验证部分,优先进行测试。
(2) 测试策略:涵盖基本测试策略、人员及职责、测试时间安排及测试环境说明等内容。其中基本测试策略描述测试阶段的划分原则,以及每阶段的准入准出标准。
(3) 测试方案:包括基本能力验证及专项特性验证测试两部分及其具体的测试用例。
(4) 测试执行:按照测试方案进行测试,并记录相关测试结果。
(5) 测试结论:对测试过程中发现的问题及测试的结果进行总结说明。
在POC整体测试中,最重要也是最耗时的并不是测试执行环节,而是确定测试方案,这个需要对测试的内容和测试用例进行详细设计。针对分布式关系型数据库而言,测试主要涉及了三个大的场景:
(1) 基本能力验证:包括功能性验证、语法、高可用、运维管理、数据安全、数据导入导出、多租户以及容灾等方面。
(2) 数据复制能力:测试从传统的集中式数据库中将数据取出来并迁移至分布式关系型数据库,这个场景直接关系到分布式改造能否顺利进行。
(3) 实际业务测试:选择至少2个业务系统,针对其中复杂的SQL和业务场景进行改写,然后在分布式数据库上进行功能及性能测试。
经过详细的测试,最终针对入围产品的整体结果进行测试汇总,并看看是否有产品会触发一票否决事宜。从实践经验来看,在选定入围产品时,我们就已做了大量的技术摸排工作,因此POC测试的结论是全部通过。
分布式关系型数据库选型是一个非常复杂的问题,除非有必要,不建议对数据库进行分布式改造。但一旦做了分布式改造的决定,就必须对技术路线的选型进行合理、充分的论证,以便保证分布式改造的目标顺利实现。企业在进行分布式改造的时候,一定要从内部梳理最真实、最迫切,最关注的需求,然后据此选型。目前不存在完美的产品可以解决所有需求,我们需要的仅仅是从众多的产品中选择最适合企业自身的产品然后应用它,快速有效的适应业务需求的变化,提升企业核心竞争力,在残酷的竞争中保持核心技术优势。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞7
添加新评论2 条评论
2019-05-13 10:22
2019-05-08 09:56