分布式数据库产品.ppt

《分布式数据库产品.ppt》由会员分享，可在线阅读，更多相关《分布式数据库产品.ppt（27页珍藏版）》请在第壹文秘上搜索。

1、分布式数据库数据持久层产品线关系型数据库产品关系型数据库集群组件数据传输工具（同步、备份恢复）分布式数据库访问层K/V数据库（NoSQL）分布式文件系统大数据平台产品2分布式数据库3数据库体系结构4数据库系统的体系结构受其运行所在的计算机系统的影响很大，尤其受计算体系结构中的联网、并行和分布式的影响：l 集中式数据库系统：运行在一台计算机上，不与其他计算机系统交互的数据库系统；l 客户-服务器数据库系统：计算机的的联网使的任务可以分别划分在服务器和客户端上执行；l 并行数据库系统：通过网络连接多个CPU和磁盘来提高处理速度和I/O速度；l 分布式数据库系统：分布式数据库系统用来处理地理上或者管

2、理上分布在多个数据库系统中的数据；并行数据库5并行数据库系统（Parallel Database System）是新一代高性能的数据库系统，是在MPP和集群并行计算环境的基础上建立的数据库系统。并行数据库系统的目标是高性能（High Performance）和高可用性（High Availability），通过多个处理节点并行执行数据库任务，提高整个数据库系统的性能和可用性。并行数据库系统基于多处理节点的物理结构，将数据库管理技术与并行处理技术有机结合，来实现系统的高性能。并行数据库分为：l共享内存l共享磁盘（例如：Oracle Rac）l无共享（例如：Teradata产品、IBM DB2 P

3、urceScale）分布式数据库6分布式数据库系统（distributed database system），数据存储在多台计算机中，通过网络相互通信，计算机之间不共享主存储器或磁盘。分布式数据系统由一些松耦合的计算机组成，不共享任何物理部件。集中式数据与分布式数据库的主要区别在于，前者数据存储在一台计算机中，后者数据存储在多台分散的计算机中。数据的分散给事务处理和查询处理带来新的难题；也就是所谓的分布式事务如何保证，跨库查询如何执行。分布式数据库-透明性7分布式数据库系统的用户不需要知道数据的物理位置，也不需要知道如何访问某个数据库节点的数据；l切片透明性：用户不需要知道数据是如何进行切片的

4、；l复制透明性：用户不需要关心数据或者切片的如何复制的，也不需要关心副本存放的位置；l位置透明性：用户不需要关心数据的物理位置，也不需要关心如何找到数据；分布式数据库-应用场景8取代传统企业级架构中商业数据库产品（Oracle、DB2），替换掉小型服务器和FC存储和网络交换设备。通过分布式的水平扩展（Scale-out）能力，提高数据的IO访问性能和安全性，实现数据的管理、拆分、路由、扩容、迁移等工作。应用场景：l 单节点数据库数据量大l 单节点数据库的并发很高l 商业数据库的许可费用高l 应用层和服务层的业务逻辑变化很快，对于扩展性要求较高分布式数据库-数据拆分9ID账户密码区域状态用户姓名

5、手机家庭电话联系地址邮箱性别垂直拆分，拆分业务把一个表结构拆分为两个表结构例如：把下表拆分为账户表和用户信息表水平拆分，拆分数据把一个表中的数据拆分为两个表，两表结构相同l 水平拆分，拆分数据l 垂直拆分，拆分业务分布式数据库-分库分表10通过切片对集中式数据库进行分库分表，把一个数据库的业务数据分成多个物理数据库。系统经sharding（切片）改造之后，原来单一的数据库会演变成多个数据库，如何确保多数据源同时操作的原子性和一致性是不得不考虑的一个问题；实现Sharding需要解决一系列关键的技术问题，主要包括：切分策略、节点路由、全局主键生成、跨节点排序/分组/表关联、多数据源事务处理和数据

6、库扩容等。分布式数据库-分库分表11通过切片对集中式数据库进行分库分表，把一个数据库的业务数据分成多个物理数据库。DB垂直拆分DB1DB2业务紧密，关联紧密的表分在一个切片里水平拆分数据量小，增量缓慢，则不需要再划分数据量大，增量迅速，则需要再进行水平拆分DB2_1DB2_2DB2_3DB2_41.将主表和其关联的表放到同一个切片中，避免跨切片查询。（拆分根据表的ID进行散列拆分）2.讲业务相近并且具有相同数据增长速率的两个或者多个切片放到同一个数据库中。目标：一次数据库业务数据的操作（查询、更改数据），在一个数据库中完成。对数据库进行分库分表(Sharding)前，需要开发人员充分了解系统业

7、务逻辑和数据库结构：l 建议是绘制一张数据库ER图或领域模型图，如果项目使用数据驱动的开发方式，团队以数据库ER图作为业务交流的基础，则自然会选择数据库ER图l 如果项目使用的是领域驱动的开发方式，并通过OR-Mapping构建了一个良好的领域模型，那么领域模型图无疑是最好的选择。更加倾向使用领域模型图，因为进行切分时更多的是以业务为依据进行分析判断，领域模型无疑更加清晰和直观。避免跨库操作。如需要，在应用层协调解决此问题。最后拆分到五个数据库中12分布式事务-两阶段提交12分布式事务处理（ Distributed Transaction Processing ， DTP ）涉及多个分布在不同

8、地方的数据库，但对数据库的操作必须全部被提交或者回滚。只要任一数据库操作时失败，所有参与事务的数据库都需要回滚。使用两阶段提交协议2PC。DB1DB2事务管理器预备（Prepare）预备（Prepare）就绪（Ready）就绪（Ready）第一阶段：准备阶段DB1DB2事务管理器预备（Prepare）预备（Prepare）异常（Abort）就绪（Ready）第一阶段：准备阶段DB1DB2事务管理器提交（Commit）提交（Commit）已提交确认已提交确认第二阶段：提交阶段DB1DB2事务管理器回滚（Rollback）回滚（Rollback）已回滚已回滚第二阶段：回滚阶段两阶段提交协议的问题：

9、l性能瓶颈，数据库在提交请求阶段应答后对很多资源处于锁定状态，要等到事务管理器收集齐所有数据库的应答后，才能发commit或者rollback消息结束这种锁定；（锁定时间的长度是由最慢的一个数据库制约）l分布式系统中节点越多，存在缓慢网络或者故障节点的概率也就越大，资源被长时间锁定的概率指数上升；l从业务功能划分的角度上，尽量避免使用分布式事务两阶段提交；分布式事务-事务补偿13在某些对数据一致的实时性要求并不高的系统环境中，只要在一个可以接受的时间周期内达到最终一致性即可，这使得事务补偿机制成为一种可行的方案。事务补偿的实现与系统业务紧密相关，并没有一种标准的处理方式，是大多数情况下最合适的

10、分布式事务的保障机制，只能适用于对事务性要求不高，允许数据“最终一致”即可的系统，牺牲实时一致性，但是能获得最大的性能回报。事务补偿分为两种机制，事务补偿机制和基于消息的最终一致性机制：事务补偿机制，基本可以是做到准实时的事务补偿（实时性较好），但需要大量的代码研发工作来保障事务的完整性；基于消息的最终一致性机制，对于实时性要求不高，可使用BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现一个事务的两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。 14分布式事务-事务补偿机制14在应用层或者服务层中，任何一个分布事务的正向操作都必须生成一个符合回滚规则的可逆向

11、操作。例如：一个用户跨银行的转账，该事务涉及到调用两个Service服务，一个是本地提供的取款服务，一个是异地目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。DB1支行ADB2支行B取款服务存款服务中间状态缓存1234671汇款转账分布式事务登记，开始一个分布式事务，生成分布式事务每一个操作的逆向操作和运行状态；从支行A的某账户中取款100元，账户余额减去100元，并冻结账户；通知事务中间状态缓存，取款事务操作提交完成，修改取款操作的状态；调用异地支行B中的存款服务，运行存款服务业务；为某账户存款100元，该账户余额增加100元；通知支行A的取款服务，汇款操作完成，并通

12、知事务中间状态缓存，修改存款操作的状态为成功，解锁支行A冻结的账户，并通知用户；如果第六步存款操作不成功，事务中间状态缓存会持续调用支行B存款服务，直到存款操作成功完成；如果多次调用存款服务，存款操作没有成功执行，事务中间状态缓存会回滚该汇款转账分布式事务，回滚支行A中的取款操作（根据取款操作的逆向操作）； 正向操作和逆向操作都有可能会出现多次调用；6234568785登记取款操作取款回滚修改状态调用存款操作结果通知再次调用准实时性，会增加分布式系统的复杂度15分布式事务-基于消息最终一致性机制15对于转账操作，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消

13、息中间件。消息中间件得到消息后对消息解析，然后调用异地银行提供的存款服务进行存款，如果服务调用失败则进行重试以保证事务的最终一致性。只要两个操作都成功即可以返回客户成功。在本地取款到异地存款两个服务调用之间，会存在一个真空期，这段时间相关现金不在任何一个账户，而只是在一个事务的中间状态，但是客户并不关心这个，只要在约定的时间保证事务最终的一致性即可。 DB1支行ADB2支行B取款服务存款服务215674取款回滚取款操作取款回滚调用存款操作结果通知再次调用发送存款消息37消息中间件实时性较差，但对系统性能开销很小16分布式数据库-跨库Join查询16分布式查询处理，从应用层或者服务层的角度，应用

14、业务功能划分的越清晰，越能避免在分布式数据库环境中出现跨库Join查询的情况。l由应用层或者服务层进行跨库Join的分布式查询的SQL分解，并在内存中保存中间数据结果并做最终的数据查询的结果合并；l由查询发起的数据库进行数据收集，其他节点的数据库把相关的数据传输到发起数据库后，进行查询处理；目标：一个好的分布式查询，应该使数据的传输量和通信次数最少，这样才能使查询所花费的数据传输和通信时间最少，从而减少查询的总代价；分布式数据库-跨库Join查询17产品表（Pid，Pname，type，price）用户表（Uid，Uname）订单表（Oid，Uid，TotalPrices）订单明细表（id，O

15、id，Pid，amount，prices）产品表订单明细表用户表订单表数据库A数据库B查看用户名User1的购买的订单中产品类型为“电子类”的金额总数；SELECT 用户表.Uname，产品表.type，count(订单明细表.Pries) AS 购买金额总数 FROM 产品表，用户表，订单表，订单明细表 Where 用户表.Uname =User1 AND 产品表.type = 电子类AND 用户表.Uid = 订单表.Uid AND 订单表.Oid = 订单明细表.OidAND 产品表.Pid = 订单明细表.PidProxyApplication用户名用户名产品类型产品类型购买金额总数购

16、买金额总数User1电子类16800元策略1：把用户表和产品表的数据传输到数据库A中进行查询，性能很差，浪费网络带宽；策略2：把数据库A的数据传输到数据库B中进行查询，性能很差，浪费网络带宽；策略3：在Proxy中进行SQL拆分，例如在数据库B中，先查询 用户“User1”的所有订单编号，把该用户的订单编号传输到数据库A中执行进一步数据查询，性能快，网络带宽开销很小；策略4：在Application层，对SQL查询进行分解查询，在Application层的内存中进行数据的合并统计，并产生最终查询结果，对数据库的性能和网络带宽开销很小，但会增加应用层的性能开销，不适合中间结果数据较大的查询；策略5：需要跨库查询的关系表，四个表复制到一个查询库，由查询库提供分布式查询；查询库分布式数据库18分布式数据库19分布式数据库产品把数据交互的工作封装成 数据访问层，服务层不直接与数据库交互，由数据访问层来提供数据的访问策略。帮助服务层完成数据的拆分以及整个数据的管理、扩容、迁移等工作。数据访问层帮助数据完成拆分，并对数据进行管理、扩容、迁移等工作。通过访问层让应用可以路由到已被分库分表的数据库主从