分布式数据库产品.ppt

,分布式数据库,数据持久层产品线,关系型数据库产品关系型数据库集群组件数据传输工具（同步、备份恢复）分布式数据库访问层K/V数据库（NoSQL）分布式文件系统大数据平台产品,2,分布式数据库,3,数据库体系结构,4,数据库系统的体系结构受其运行所在的计算机系统的影响很大，尤其受计算体系结构中的联网、并行和分布式的影响：,集中式数据库系统：运行在一台计算机上，不与其他计算机系统交互的数据库系统；客户-服务器数据库系统：计算机的的联网使的任务可以分别划分在服务器和客户端上执行；并行数据库系统：通过网络连接多个CPU和磁盘来提高处理速度和I/O速度；分布式数据库系统：分布式数据库系统用来处理地理上或者管理上分布在多个数据库系统中的数据；,并行数据库,5,并行数据库系统（ParallelDatabaseSystem）是新一代高性能的数据库系统，是在MPP和集群并行计算环境的基础上建立的数据库系统。并行数据库系统的目标是高性能（HighPerformance）和高可用性（HighAvailability），通过多个处理节点并行执行数据库任务，提高整个数据库系统的性能和可用性。并行数据库系统基于多处理节点的物理结构，将数据库管理技术与并行处理技术有机结合，来实现系统的高性能。并行数据库分为：共享内存共享磁盘（例如：OracleRac）无共享（例如：Teradata产品、IBMDB2PurceScale）,分布式数据库,6,分布式数据库系统（distributeddatabasesystem），数据存储在多台计算机中，通过网络相互通信，计算机之间不共享主存储器或磁盘。,分布式数据系统由一些松耦合的计算机组成，不共享任何物理部件。集中式数据与分布式数据库的主要区别在于，前者数据存储在一台计算机中，后者数据存储在多台分散的计算机中。,数据的分散给事务处理和查询处理带来新的难题；也就是所谓的分布式事务如何保证，跨库查询如何执行。,分布式数据库-透明性,7,分布式数据库系统的用户不需要知道数据的物理位置，也不需要知道如何访问某个数据库节点的数据；,切片透明性：用户不需要知道数据是如何进行切片的；复制透明性：用户不需要关心数据或者切片的如何复制的，也不需要关心副本存放的位置；位置透明性：用户不需要关心数据的物理位置，也不需要关心如何找到数据；,分布式数据库-应用场景,8,取代传统企业级架构中商业数据库产品（Oracle、DB2），替换掉小型服务器和FC存储和网络交换设备。通过分布式的水平扩展（Scale-out）能力，提高数据的IO访问性能和安全性，实现数据的管理、拆分、路由、扩容、迁移等工作。,应用场景：单节点数据库数据量大单节点数据库的并发很高商业数据库的许可费用高应用层和服务层的业务逻辑变化很快，对于扩展性要求较高,分布式数据库-数据拆分,9,垂直拆分，拆分业务把一个表结构拆分为两个表结构,例如：把下表拆分为账户表和用户信息表,水平拆分，拆分数据把一个表中的数据拆分为两个表，两表结构相同,水平拆分，拆分数据垂直拆分，拆分业务,分布式数据库-分库分表,10,通过切片对集中式数据库进行分库分表，把一个数据库的业务数据分成多个物理数据库。系统经sharding（切片）改造之后，原来单一的数据库会演变成多个数据库，如何确保多数据源同时操作的原子性和一致性是不得不考虑的一个问题；,实现Sharding需要解决一系列关键的技术问题，主要包括：切分策略、节点路由、全局主键生成、跨节点排序/分组/表关联、多数据源事务处理和数据库扩容等。,分布式数据库-分库分表,11,通过切片对集中式数据库进行分库分表，把一个数据库的业务数据分成多个物理数据库。,DB,垂直拆分,DB1,DB2,业务紧密，关联紧密的表分在一个切片里,水平拆分,数据量小，增量缓慢，则不需要再划分,数据量大，增量迅速，则需要再进行水平拆分,DB2_1,DB2_2,DB2_3,DB2_4,将主表和其关联的表放到同一个切片中，避免跨切片查询。（拆分根据表的ID进行散列拆分）讲业务相近并且具有相同数据增长速率的两个或者多个切片放到同一个数据库中。,目标：一次数据库业务数据的操作（查询、更改数据），在一个数据库中完成。,对数据库进行分库分表(Sharding)前，需要开发人员充分了解系统业务逻辑和数据库结构：建议是绘制一张数据库ER图或领域模型图，如果项目使用数据驱动的开发方式，团队以数据库ER图作为业务交流的基础，则自然会选择数据库ER图如果项目使用的是领域驱动的开发方式，并通过OR-Mapping构建了一个良好的领域模型，那么领域模型图无疑是最好的选择。更加倾向使用领域模型图，因为进行切分时更多的是以业务为依据进行分析判断，领域模型无疑更加清晰和直观。,避免跨库操作。如需要，在应用层协调解决此问题。,最后拆分到五个数据库中,12,分布式事务-两阶段提交,12,分布式事务处理（DistributedTransactionProcessing，DTP）涉及多个分布在不同地方的数据库，但对数据库的操作必须全部被提交或者回滚。只要任一数据库操作时失败，所有参与事务的数据库都需要回滚。使用两阶段提交协议2PC。,DB1,DB2,事务管理器,预备（Prepare）,预备（Prepare）,就绪（Ready）,就绪（Ready）,第一阶段：准备阶段,DB1,DB2,事务管理器,预备（Prepare）,预备（Prepare）,异常（Abort）,就绪（Ready）,第一阶段：准备阶段,DB1,DB2,事务管理器,提交（Commit）,提交（Commit）,已提交确认,已提交确认,第二阶段：提交阶段,DB1,DB2,事务管理器,回滚（Rollback）,回滚（Rollback）,已回滚,已回滚,第二阶段：回滚阶段,两阶段提交协议的问题：性能瓶颈，数据库在提交请求阶段应答后对很多资源处于锁定状态，要等到事务管理器收集齐所有数据库的应答后，才能发commit或者rollback消息结束这种锁定；（锁定时间的长度是由最慢的一个数据库制约）分布式系统中节点越多，存在缓慢网络或者故障节点的概率也就越大，资源被长时间锁定的概率指数上升；从业务功能划分的角度上，尽量避免使用分布式事务两阶段提交；,分布式事务-事务补偿,13,在某些对数据一致的实时性要求并不高的系统环境中，只要在一个可以接受的时间周期内达到最终一致性即可，这使得事务补偿机制成为一种可行的方案。事务补偿的实现与系统业务紧密相关，并没有一种标准的处理方式，是大多数情况下最合适的分布式事务的保障机制，只能适用于对事务性要求不高，允许数据“最终一致”即可的系统，牺牲实时一致性，但是能获得最大的性能回报。,事务补偿分为两种机制，事务补偿机制和基于消息的最终一致性机制：,事务补偿机制，基本可以是做到准实时的事务补偿（实时性较好），但需要大量的代码研发工作来保障事务的完整性；基于消息的最终一致性机制，对于实时性要求不高，可使用BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现一个事务的两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。,14,分布式事务-事务补偿机制,14,在应用层或者服务层中，任何一个分布事务的正向操作都必须生成一个符合回滚规则的可逆向操作。例如：一个用户跨银行的转账，该事务涉及到调用两个Service服务，一个是本地提供的取款服务，一个是异地目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。,DB1,支行A,DB2,支行B,取款服务,存款服务,中间状态缓存,1,2,3,4,6,7,1,汇款转账分布式事务登记，开始一个分布式事务，生成分布式事务每一个操作的逆向操作和运行状态；从支行A的某账户中取款100元，账户余额减去100元，并冻结账户；通知事务中间状态缓存，取款事务操作提交完成，修改取款操作的状态；调用异地支行B中的存款服务，运行存款服务业务；为某账户存款100元，该账户余额增加100元；通知支行A的取款服务，汇款操作完成，并通知事务中间状态缓存，修改存款操作的状态为成功，解锁支行A冻结的账户，并通知用户；如果第六步存款操作不成功，事务中间状态缓存会持续调用支行B存款服务，直到存款操作成功完成；如果多次调用存款服务，存款操作没有成功执行，事务中间状态缓存会回滚该汇款转账分布式事务，回滚支行A中的取款操作（根据取款操作的逆向操作）；正向操作和逆向操作都有可能会出现多次调用；,6,2,3,4,5,6,8,7,8,5,登记,取款操作,取款回滚,修改状态,调用,存款操作,结果通知,再次调用,准实时性，会增加分布式系统的复杂度,15,分布式事务-基于消息最终一致性机制,15,对于转账操作，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消息中间件。消息中间件得到消息后对消息解析，然后调用异地银行提供的存款服务进行存款，如果服务调用失败则进行重试以保证事务的最终一致性。只要两个操作都成功即可以返回客户成功。在本地取款到异地存款两个服务调用之间，会存在一个真空期，这段时间相关现金不在任何一个账户，而只是在一个事务的中间状态，但是客户并不关心这个，只要在约定的时间保证事务最终的一致性即可。,DB1,支行A,DB2,支行B,取款服务,存款服务,2,1,5,6,7,4,取款回滚,取款操作,取款回滚,调用,存款操作,结果通知,再次调用,发送存款消息,3,7,消息中间件,实时性较差，但对系统性能开销很小,16,分布式数据库-跨库Join查询,16,分布式查询处理，从应用层或者服务层的角度，应用业务功能划分的越清晰，越能避免在分布式数据库环境中出现跨库Join查询的情况。由应用层或者服务层进行跨库Join的分布式查询的SQL分解，并在内存中保存中间数据结果并做最终的数据查询的结果合并；由查询发起的数据库进行数据收集，其他节点的数据库把相关的数据传输到发起数据库后，进行查询处理；,目标：一个好的分布式查询，应该使数据的传输量和通信次数最少，这样才能使查询所花费的数据传输和通信时间最少，从而减少查询的总代价；,分布式数据库-跨库Join查询,17,产品表（Pid，Pname，type，price）用户表（Uid，Uname）订单表（Oid，Uid，TotalPrices）订单明细表（id，Oid，Pid，amount，prices）,产品表,订单明细表,用户表,订单表,数据库A,数据库B,查看用户名User1的购买的订单中产品类型为“电子类”的金额总数；SELECT用户表.Uname，产品表.type，count(订单明细表.Pries)AS购买金额总数FROM产品表，用户表，订单表，订单明细表Where用户表.Uname=User1AND产品表.type=电子类AND用户表.Uid=订单表.UidAND订单表.Oid=订单明细表.OidAND产品表.Pid=订单明细表.Pid,Proxy,Application,策略1：把用户表和产品表的数据传输到数据库A中进行查询，性能很差，浪费网络带宽；策略2：把数据库A的数据传输到数据库B中进行查询，性能很差，浪费网络带宽；策略3：在Proxy中进行SQL拆分，例如在数据库B中，先查询用户“User1”的所有订单编号，把该用户的订单编号传输到数据库A中执行进一步数据查询，性能快，网络带宽开销很小；策略4：在Application层，对SQL查询进行分解查询，在Application层的内存中进行数据的合并统计，并产生最终查询结果，对数据库的性能和网络带宽开销很小，但会增加应用层的性能开销，不适合中间结果数据较大的查询；策略5：需要跨库查询的关系表，四个表复制到一个查询库，由查询库提供分布式查询；,查询库,分布式数据库,18,分布式数据库,19,分布式数据库产品把数据交互的工作封装成数据访问层，服务层不直接与数据库交互，由数据访问层来提供数据的访问策略。帮助服务层完成数据的拆分以及整个数据的管理、扩容、迁移等工作。,数据访问层帮助数据完成拆分，并对数据进行管理、扩容、迁移等工作。通过访问层让应用可以路由到已被分库分表的数据库主从节点上；,分布式数据库场景需要关系型数据库产品和Proxy数据访问层产品来进行搭建。,功能列表,20,数据库读写分离，双机容灾热备根据业务拆分数据库，水平和垂直拆分业务数据（分库分表）数据访问层自定义数据访问路由策略，数据访问路由自动选择支持三种分布式事物保障机制，两阶段提交、事物补偿机制、基于消息的最终一致性支持分布式查询处理全局主键生成机制数据库自动扩容、迁移开放API，与云计算IaaS平台结合并构建云数据库服务，支持一键申请、数据库环境HA、自动备份恢复等功能,易用云数据库,提供一键申请、自动备份、故障自动迁移、误删数据可恢复，高可靠的MySQL、MariaDB、MongoDB云服务。,应用场景：需要使用关系型和K/V类型数据库服务的各种业务。,高可用：自动对数据库进行高可用部署，保障服务在不可用时自动完成切换数据备份：实时将数据库镜像及日志备份至云存储、实现针对数据库实例的镜像恢复和时间点恢复安全隔离：通过使用安全组功能，增强原有数据库的访问权限控制,Client,Proxy,Proxy,DB,DB,DB,DB,DB,DB,MySQL实例,MariaDB实例,MongoDB实例,22,数据库读写分离,22,订单,应用服务器,用户,商品,商品表,数据库,从库（读）,用户表,订单表,应用服务器,从数据库服务器,负载均衡器,订单,应用服务器,用户,商品,负载均衡器,主数据库服务器,写库：需要写入数据库的事务操作读库：缓存访问不命中、缓存过期、需要读取数据库的事务操作,分布式缓存集群,商品表,数据库,主库（写）,用户表,订单表,分布式缓存集群,主从库数据同步,分布式数据库,23,EonDB数据访问层Proxy,订单,用户,商品,负载均衡器,订单,用户,商品,用户（主）,分布式缓存集群,商品（主）,用户（从）,交易（从）,商品（从）,交易（主）,服务层,应用层,应用服务器,应用服务器,数据复制,数据复制,数据复制,读写分离（主从）分库分表水平分割，将相同业务不同的数据放到不同的数据库中垂直分割，将不同的业务数据放到不同的数据库中访问路由策略自动扩容，增加