分布式数据库产品.ppt
《分布式数据库产品.ppt》由会员分享,可在线阅读,更多相关《分布式数据库产品.ppt(27页珍藏版)》请在课桌文档上搜索。
1、,分布式数据库,数据持久层产品线,关系型数据库产品关系型数据库集群组件数据传输工具(同步、备份恢复)分布式数据库访问层K/V数据库(NoSQL)分布式文件系统大数据平台产品,2,分布式数据库,3,数据库体系结构,4,数据库系统的体系结构受其运行所在的计算机系统的影响很大,尤其受计算体系结构中的联网、并行和分布式的影响:,集中式数据库系统:运行在一台计算机上,不与其他计算机系统交互的数据库系统;客户-服务器数据库系统:计算机的的联网使的任务可以分别划分在服务器和客户端上执行;并行数据库系统:通过网络连接多个CPU和磁盘来提高处理速度和I/O速度;分布式数据库系统:分布式数据库系统用来处理地理上或
2、者管理上分布在多个数据库系统中的数据;,并行数据库,5,并行数据库系统(Parallel Database System)是新一代高性能的数据库系统,是在MPP和集群并行计算环境的基础上建立的数据库系统。并行数据库系统的目标是高性能(High Performance)和高可用性(High Availability),通过多个处理节点并行执行数据库任务,提高整个数据库系统的性能和可用性。并行数据库系统基于多处理节点的物理结构,将数据库管理技术与并行处理技术有机结合,来实现系统的高性能。并行数据库分为:共享内存共享磁盘(例如:Oracle Rac)无共享(例如:Teradata产品、IBM DB2
3、 PurceScale),分布式数据库,6,分布式数据库系统(distributed database system),数据存储在多台计算机中,通过网络相互通信,计算机之间不共享主存储器或磁盘。,分布式数据系统由一些松耦合的计算机组成,不共享任何物理部件。集中式数据与分布式数据库的主要区别在于,前者数据存储在一台计算机中,后者数据存储在多台分散的计算机中。,数据的分散给事务处理和查询处理带来新的难题;也就是所谓的分布式事务如何保证,跨库查询如何执行。,分布式数据库-透明性,7,分布式数据库系统的用户不需要知道数据的物理位置,也不需要知道如何访问某个数据库节点的数据;,切片透明性:用户不需要知道
4、数据是如何进行切片的;复制透明性:用户不需要关心数据或者切片的如何复制的,也不需要关心副本存放的位置;位置透明性:用户不需要关心数据的物理位置,也不需要关心如何找到数据;,分布式数据库-应用场景,8,取代传统企业级架构中商业数据库产品(Oracle、DB2),替换掉小型服务器和FC存储和网络交换设备。通过分布式的水平扩展(Scale-out)能力,提高数据的IO访问性能和安全性,实现数据的管理、拆分、路由、扩容、迁移等工作。,应用场景:单节点数据库数据量大单节点数据库的并发很高商业数据库的许可费用高应用层和服务层的业务逻辑变化很快,对于扩展性要求较高,分布式数据库-数据拆分,9,垂直拆分,拆分
5、业务把一个表结构拆分为两个表结构,例如:把下表拆分为账户表和用户信息表,水平拆分,拆分数据把一个表中的数据拆分为两个表,两表结构相同,水平拆分,拆分数据垂直拆分,拆分业务,分布式数据库-分库分表,10,通过切片对集中式数据库进行分库分表,把一个数据库的业务数据分成多个物理数据库。系统经sharding(切片)改造之后,原来单一的数据库会演变成多个数据库,如何确保多数据源同时操作的原子性和一致性是不得不考虑的一个问题;,实现Sharding需要解决一系列关键的技术问题,主要包括:切分策略、节点路由、全局主键生成、跨节点排序/分组/表关联、多数据源事务处理和数据库扩容等。,分布式数据库-分库分表,
6、11,通过切片对集中式数据库进行分库分表,把一个数据库的业务数据分成多个物理数据库。,DB,垂直拆分,DB1,DB2,业务紧密,关联紧密的表分在一个切片里,水平拆分,数据量小,增量缓慢,则不需要再划分,数据量大,增量迅速,则需要再进行水平拆分,DB2_1,DB2_2,DB2_3,DB2_4,将主表和其关联的表放到同一个切片中,避免跨切片查询。(拆分根据表的ID进行散列拆分)讲业务相近并且具有相同数据增长速率的两个或者多个切片放到同一个数据库中。,目标:一次数据库业务数据的操作(查询、更改数据),在一个数据库中完成。,对数据库进行分库分表(Sharding)前,需要开发人员充分了解系统业务逻辑和
7、数据库结构:建议是绘制一张数据库ER图或领域模型图,如果项目使用数据驱动的开发方式,团队以数据库ER图作为业务交流的基础,则自然会选择数据库ER图如果项目使用的是领域驱动的开发方式,并通过OR-Mapping构建了一个良好的领域模型,那么领域模型图无疑是最好的选择。更加倾向使用领域模型图,因为进行切分时更多的是以业务为依据进行分析判断,领域模型无疑更加清晰和直观。,避免跨库操作。如需要,在应用层协调解决此问题。,最后拆分到五个数据库中,12,分布式事务-两阶段提交,12,分布式事务处理(Distributed Transaction Processing,DTP)涉及多个分布在不同地方的数据库
8、,但对数据库的操作必须全部被提交或者回滚。只要任一数据库操作时失败,所有参与事务的数据库都需要回滚。使用两阶段提交协议2PC。,DB1,DB2,事务管理器,预备(Prepare),预备(Prepare),就绪(Ready),就绪(Ready),第一阶段:准备阶段,DB1,DB2,事务管理器,预备(Prepare),预备(Prepare),异常(Abort),就绪(Ready),第一阶段:准备阶段,DB1,DB2,事务管理器,提交(Commit),提交(Commit),已提交确认,已提交确认,第二阶段:提交阶段,DB1,DB2,事务管理器,回滚(Rollback),回滚(Rollback),已回
9、滚,已回滚,第二阶段:回滚阶段,两阶段提交协议的问题:性能瓶颈,数据库在提交请求阶段应答后对很多资源处于锁定状态,要等到事务管理器收集齐所有数据库的应答后,才能发commit或者rollback消息结束这种锁定;(锁定时间的长度是由最慢的一个数据库制约)分布式系统中节点越多,存在缓慢网络或者故障节点的概率也就越大,资源被长时间锁定的概率指数上升;从业务功能划分的角度上,尽量避免使用分布式事务两阶段提交;,分布式事务-事务补偿,13,在某些对数据一致的实时性要求并不高的系统环境中,只要在一个可以接受的时间周期内达到最终一致性即可,这使得事务补偿机制成为一种可行的方案。事务补偿的实现与系统业务紧密
10、相关,并没有一种标准的处理方式,是大多数情况下最合适的分布式事务的保障机制,只能适用于对事务性要求不高,允许数据“最终一致”即可的系统,牺牲实时一致性,但是能获得最大的性能回报。,事务补偿分为两种机制,事务补偿机制和基于消息的最终一致性机制:,事务补偿机制,基本可以是做到准实时的事务补偿(实时性较好),但需要大量的代码研发工作来保障事务的完整性;基于消息的最终一致性机制,对于实时性要求不高,可使用BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现一个事务的两个服务的真正解耦,解耦的关键就是异步消息和消息持久化机制。,14,分布式事务-事务补偿机制,14,在应用层或者服务层
11、中,任何一个分布事务的正向操作都必须生成一个符合回滚规则的可逆向操作。例如:一个用户跨银行的转账,该事务涉及到调用两个Service服务,一个是本地提供的取款服务,一个是异地目标银行提供的存款服务,该两个服务本身无状态且独立,构成一个完整的事务。,DB1,支行A,DB2,支行B,取款服务,存款服务,中间状态缓存,1,2,3,4,6,7,1,汇款转账分布式事务登记,开始一个分布式事务,生成分布式事务每一个操作的逆向操作和运行状态;从支行A的某账户中取款100元,账户余额减去100元,并冻结账户;通知事务中间状态缓存,取款事务操作提交完成,修改取款操作的状态;调用异地支行B中的存款服务,运行存款服
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 分布式 数据库 产品
链接地址:https://www.desk33.com/p-246521.html