分布式数据库和Hadoop都不够好,于是我们设计分布式SQL计算系统
《分布式数据库和Hadoop都不够好,于是我们设计分布式SQL计算系统》要点: 设计思想为了解决分布式数据库下,复杂的 SQL(如全局性的排序、分组、join、子查询,特别是非均衡字段的这些逻辑操作)难以实现的问题;在有了一些分布式数据库和 Hadoop?实际应用经验的基础上,对比两者的优点和不足,加上自己的一些提炼和思考,设计了一套综合两者的系统,利用两者的优点,补充两者的不足.具体的说, 使用数据库水平分割的思想实现数据存储,使用 MapReduce的思想实现 SQL 计算. 这里的数据库水平分割的意思是只分库不分表,对于不同数量级别的表,分库的数量可以不一样,例如 1 亿的数据量分 10 个分库,10 亿的分 50 个分库.对于使用 MapReduce的思想实现计算 ; 对于一个需求,转换成一个或多个有依赖关系的SQL,其中的每个SQL分解成一个或多个 MapReduce任务,每个 MapReduce任务又包含 mapsql、洗牌(shuffle)、reducesql,这个过程可以理解为类似 hive,区别是连 MapReduce任务中的 map 和 reduce 操作也是通过?SQL?实现,而非 Hadoop?中的 map 和 reduce 操作. 这是基本的 MapReduce的思想,但是在 Hadoop 的生态圈中,第一代的MapReduce将结果存储于磁盘,第二代的 MapReduce根据内存使用情况将结果存储于内存或磁盘,类比一下用数据库来存储,那么 MapReduce 的结果就是存储在表中,而数据库的缓存机制天然支持根据内存情况决定存储在内存还是磁盘 ; 另外,Hadoop?生态圈中,计算模型也并非一种,这里的 MapReduce的计算思想,可以用类似 spark 的 RDD 迭代计算方式来替代 ; 本系统还是基于MapReduce来说明的. 架构根据以上的思想,系统的架构如下: 没有代理节点 ?有代理节点 ?模块说明 ?关于系统中的模块,由于和绝大部分的分布式系统类似,这里仅做简要说明: 两种架构的区别 ?无代理节点的时候,客户端担负着比较大的工作,包括:发送请求、解析 SQL、生成执行计划、申请资源、安排执行、获取结果等;有代理节点的时候,代理节点担负着接受请求、解析 SQL、生成执行计划、申请资源、安排执行、返回结果给客户端等大部分责任,另外代理节点提供支持外部协议的接口,如 mysql 的 c/s 协议,使用 mysql 的命令行可以直接连接进来执行 SQL,整个系统就像普通的 mysql server 一样. 应用架构 ?实际应用环境可能是正式环境一套,正式备份环境一套,线下环境一套,可以按照如下的架构进行部署. 基本概念 说明下面针对架构中的一些概念做些说明 下面说明常用的增删改查如何执行,特别是查询操作 增删改操作当插入数据的时候,根据均衡字段和均衡策略将记录插入到对应的数据库节点中. 当更新数据的时候,需要根据均衡策略判断数据更新前的和更新后的数据库节点是否变化:如果没有变化,直接更新;如果有变化,在更新前的数据库节点中删除老数据,在更新后的数据库节点中插入新数据. 当删除数据的时候,根据均衡策略在相应的数据库节点中删除. 这三种变更数据的操作,只要涉及到多个节点的数据变更,都需要使用分布式事务保证一致性、原子性等事务特性. 查询操作查询操作的原理类似 hive,大家可以对比来理解 ; 为了方便解释查询操作,首先来说明阶段树和阶段的结构,如下图所示: 阶段树 ?阶段查询步骤 结合上面的图,查询操作的具体过程如下:
例子 由于系统核心在于存储和计算,下面对存储和计算相关的概念举例说明 均衡策略 举例说明均衡策略,基本信息如下:表名字:tab_user_login表描述:用于存储用户登录信息节点数:4,分为 0、1、2、3 (编辑:ASP站长网) |