分布式数据库和Hadoop都不够好，于是我们设计分布式SQL计算系统

首先明确 join 的字段类型为数字类型和字符串类型,其他类型如日期可以转换为这两种.数字类型的排序很简单,字符串类型的数据排序需要确定规则,类似 mysql 中的 collation,比较常用的是按照 unicode 编码顺序,按照实际存储节点的大小等；其次 join 的方式有等值 join 和非等值 join；以如下常用且比较简单的情况为例.

以如下 sql 为例,某一注册时间范围内的用户的所有登录信息：

select t1.u_id,t1.u_name,t2.login_product

from tab_user_info t1 join tab_login_info t2

on (t1.u_id=t2.u_id and t1.u_reg_dt>=? and t1.u_reg_dt<=?)

执行计划可能为：

Map：

由于是 join,所有的表都要进行查询操作,并且为每张表打上自己的标签,具体实施的时候可以加个表名字字段,在所有存储节点上执行

select u_id,u_name from tab_user_info t where u_reg_dt>=? and t1.u_reg_dt<=?

select u_id,login_product from tab_login_info t

Shuffle：这种情况下由于需要按照 u_id 进行数据洗牌,考虑到 u_id 的唯一值比较多,所以各个存储节点上需要按照 u_id 进行划分,例如有 N 个计算节点,划分到同一个计算节点上.

Reduce：

select t1.u_id,t2.login_product

from tab_user_info t1 join tab_login_info t2

on (t1.u_id=t2.u_id)

子查询

由于子查询可以分解成具有依赖关系的不包含子查询的 SQL,所以生成的执行计划,就是多个 SQL?的执行计划按照一定的依赖关系进行依次执行.

与已有系统的区别和优点

• 相比 hdfs 来说,数据的分布是有规则的,hdfs 需要启动之后执行命令去查询文件具体在什么节点上；元数据的较小,记录规则即可,管理成本较低,在启动速度方面很快.
• 数据是放在数据库中的,可以很好的使用索引和数据库本身的缓存机制,大大提高数据查询的效率,特别是在大量数据的情况下,利用索引查询返回少量的数据.
• 数据可以进行删除和修改,这在基于 hdfs 的系统中一般比较麻烦和低效.
• 在计算方面,和 MapReduce ?或者其他的分布式计算框架(如 spark)并没有本质的区别(需要进行 shuffle).但是由于数据的分布是有规则的,在有些地方可以做的更好,在分布式全文索引体现.
• 由于线上系统一般使用数据库作为最终的存储位置,而把数据库同步到 hdfs 中是比较麻烦的,并且对于有删除和更新的情况,同步数据麻烦低效,速度较慢；相比之下,这个方案可以使用数据库本身提供的镜像复制功能来同步,基本没有额外的麻烦和低效的工作.
• 基于以上,可以把线上系统(主系统)和线下的数据分析挖掘(从系统)做成统一的方案,参见应用架构图.

应用场景 ?

最后列举一些应用场景

作者：江和慧,目前就职税友软件,曾经任职网易,专注数据处理领域MySQL、Hadoop,分布式数据库

文章来自微信公众号：高效开发运维

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!