分布式数据访问服务之1

      业界主流的互联网架构中,分布式服务框架、分布式数据访问服务、消息队列服务、服务网关(API)、分布式事务等都是核心的组件和框架。

当我们的系统规模越来越大,从几台服务器扩展到几十台、几百台、上千台,传统的烟囱式的、大集中式系统架构,逐步演进为服务化SOA、分布式的系统架构:

在数据层面,应用层面,访问层面和查询方面,全都以分布式的结构来搭建,使整个系统不存在性能和横向扩展的瓶颈,实现系统的弹性伸缩和横向扩展,

以支撑我们超大规模的系统。

      最近研究了业界主流的分布式数据访问服务,做了一次横向对比和分析。基于对比做技术选型、验证,目的就是要设计一套.Net版本的分布式数据访问组件。

      搞了这么多年.Net,ORMapping(EF、Hibernate、MyBatis),有必要搞一个“分布式数据访问服务”的技术专题,作为总结和技术分享。

      这个系列的第一篇以"华山论剑" 开始吧,细数各门各派的看家本领(分布式数据访问服务框架),一较高低!

一、微软Azure SQL 

使用 Azure SQL 数据库的可缩放工具和功能,可以轻松地横向扩展数据库。特别是可以使用弹性数据库客户端库来创建和管理扩大的数据库。

此功能支持使用成百上千个 AzureSQL 数据库,轻松地开发数据分区应用程序。然后,可以使用弹性作业帮助简化这些数据库的管理。

它包含了三个核心组件:分片映射管理、数据路由、多分片查询

1. 分片映射管理器:分片映射管理器是一个特殊的数据库,它维护一个分片集中有关所有分片 (数据库)的全局映射信息。

2. 数据路由:使用查询中的数据将请求路由到相应数据库的功能

假设将一个请求传入应用程序。基于请求的分区键值,应用程序必须根据该键值判断正确的数据库。接着,它会与数据库建立连接来处理请求。借助数据依赖路由

能够通过对应用程序的分片映射的单个简单调用打开连接,进行数据操作:

3.  多分片查询:多分片查询用于诸如数据收集/报告等需要跨多个分片运行查询的任务。(相比之下,数据相关的路由会在单个分片上执行所有操作。)

当一个请求涉及多个(或所有)分片时,多分片查询将生效。多分片查询在所有分片或一组分片上执行相同的 T-SQL 代码。使用 UNION ALL 语义,

将参与分片中的结果合并到一个总结果集中。该功能是通过该客户端库处理多个任务公开的,其中包括连接管理、线程管理、故障处理和中间结果处理。

最多可以查询数百个分片

总结:微软的Azure SQL是一个PaaS层的数据访问服务,需要将本地数据库迁移到Azure SQL,即云端SQLServer中,

整个Azure SQL支持对SQLServer的横向扩展,在SDK层面简化屏蔽了分库分表带来的一些编程问题,如果采用Azure SQL的话,

分库分表的部署、管理、集成的确非常方便,原生支持。但是本地化私有云环境下,SQLServer的分库分表就需要自己搞了。

二、阿里分布式关系型数据库服务DRDS——云端数据库PaaS服务

DRDS 目前定位成一个中间件(前身是TDDL),在业务应用和RDS(关系型数据库服务器)之间,本身不承担数据存储,

只负责解决分布式情况下数据操作路由、执行、数据处理等功能。主要支持的数据库是MySQL。

DRDS的使用与MySQL非常接近,建实例、建库、建表、SQL操作,唯一比较大的区别在于水平拆分模式下,DRDS对于建表需要指定拆分字段(类似索引),

只要带上这个拆分字段,SQL只会在部分数据分片上执行,从而加速SQL执行速度。

DRDS有着比较完整的MySQL SQL兼容性

DRDS 对于单机事务完整支持,也就是业务中一个事务中的各个SQL最终都落到同一个数据库即可保障强一致,

对于跨数据库的分布式事务,DRDS提供最终一致分布式事务给业务使用,目前处于内测阶段。

1. DRDS基本原理-读写分离:

对于sql进行类型判定,如果判定为读取操作,则按照用户设置的读权重进行sql路由,到主实例或者到只读上进行sql操作。

2. DRDS基本原理-水平拆分

对于sql进行类型判定,如果判定为读取操作,则按照用户设置的读权重进行sql路由,到主实例或者到只读上进行sql操作。

DRDS中的数据是按照拆分字段值,加上特定的算法进行计算,根据结果存储数据到对应分片。

3. DRDS基本原理-SQL路由

当用户SQL到DRDS时,DRDS会解析整个SQL含义,然后按照拆分字段的值和执行策略将SQL路由到对应分区进行执行。

4. DRDS基本原理-数据合并:

如果一个SQL对应多个分片数据执行,DRDS会将各个分片返回的数据按照原始SQL语义进行合并。

5. DRDS支持的SQL语法

6. DRDS不支持的SQL语法:

    受限于分布式事务

  • 跨分片操作, UPDATE/DELETE [ORDER BY] LIMIT
  • 跨分片操作, UPDATE A,B set A.s = B.s+1 WHERE A.ID = B.NAME , 非拆分字段之间的跨库JOIN
  • 拆分键变更, UPDATE A SET A.ID = 1 WHERE XXX, ID为拆分字段
  • 跨分片操作, INSERT A SELECT B WHERE B.ID > XX , 跨库导入导出数据
  • 跨库事务, 比如两次UPDATE不在一个分片上

   子查询限制

  • 暂不支持非where条件的correlate subquery
  • 暂不支持sql中带聚合条件和correlate subquery

7. DRDS是否支持分布式join以及复杂SQL如何支持?

   不是所有的join都能够支持,例如对于大表之间的join,就因为执行代价过高,速度过慢而被DRDS限制,但大部分的join的语义,支持以最高效的方式完成。

   DRDS处理join的原则非常简单:尽可能让join发生在单机

   7.1. 按照同一个维度进行切分:如果能够让join物理上发生在单台机器上,那么任何一类的复杂查询都是可以直接支持的。一般而言,

这就意味着参与join的多张表按照同一个维度进行切分。例如,一个用户有多个商品,每个商品都有自己的商品特征。这时候,如果需要join,可以将所有数据按照用户,

或者按照商品进行切分,那么join就会物理上的发生在同一个机器上,DRDS能够很轻松的保证所有在单机发生的join查询,物理上都能够查出数据,

对于非常复杂的SQL,可以通过注释的方式,直接告知DRDS切分条件,这样就可以绕开SQL解析器进行查询。

  7.2. 小表复制(主数据复制同步):同时可以有选择的将一些不经常更新的,数据量比较小的元数据表复制到全部的节点上。

这样,大表join小表的时候,就从一个分布式join变为了本地join,当然,这种过程需要一定的代价,也就是元数据表内的数据更新,

可能在一小段时间(50~100ms)后才能在分库内看到。

  7.3. 在线查询与离线查询分离:对于复杂的大表和大表的分析和统计类查询,阿里内部推荐采取专门的分析引擎来获取报表数据,比如使用ODPS等,

这类查询使用传统数据库架构,在数据量非常巨大的时候,很可能会影响线上的应用,因此阿里建议将在线和离线查询分开。

总结:阿里的DRDS还是非常强大的,依靠MySQL原生的Replica技术+SQL路由解析+内存数据合并,日常的MySQL分库分表、读写分离等大部分场景都能支持。

三、当当Sharding-JDBC

Sharding-JDBC是当当应用框架ddframe中,关系型数据库模块dd-rdb中分离出来的数据库水平扩展框架,即透明化数据库分库分表访问。

从框架名字看,肯定是Java技术路线的,官方的说明中,Sharding-JDBC功能灵活且全面:

  • 分片策略灵活,可支持=,BETWEEN,IN等多维度分片,
  • 也可支持多分片键共用
  • SQL解析功能完善,支持聚合,分组,排序,Limit,OR等查询,并且支持Binding Table以及笛卡尔积的表查询。
  • 支持柔性事务(目前仅最大努力送达型)。
  • 支持读写分离

Sharding-JDBC定位于日常数据库CRUD操作,目前仅针对DQL和DML语句进行支持

编程示例:

复制代码
1 ShardingRule shardingRule = ShardingRule.builder()
    .dataSourceRule(dataSourceRule)
    .tableRules(tableRuleList)
    .databaseShardingStrategy(new DatabaseShardingStrategy("sharding_column", new XXXShardingAlgorithm())) 
    .tableShardingStrategy(new TableShardingStrategy("sharding_column", new XXXShardingAlgorithm()))) 
    .build(); 
2 DataSource dataSource = ShardingDataSourceFactory.createDataSource(shardingRule); 
  String sql = "SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.user_id=? AND o.order_id=?"; 
4     Connection conn = dataSource.getConnection(); 
5     PreparedStatement preparedStatement = conn.prepareStatement(sql)) {           
      preparedStatement.setInt(1, 10); 
6     preparedStatement.setInt(2, 1001); 
      ResultSet rs = preparedStatement.executeQuery();
8       {
                while(rs.next()) {
                System.out.println(rs.getInt(1));  
                System.out.println(rs.getInt(2));
        } 
      } 
9     
复制代码

对于复制的综合查询,咨询了当当的架构师团队,他们也在计划通过离线分析和大数据分析来实现,不过其实时性和数据的准确性是一个挑战。

四、Shark:分布式的MySQL分库分表中间件

此Shark非工作流Shark,是云集主要的分布式数据访问框架,也是Java技术路线,它是一个应用程序层的数据访问框架。

Shark的技术优点:

  • 完善的技术文档支持;
  • 动态数据源的无缝切换;
  • 丰富、灵活的分布式路由算法支持;
  • 非proxy架构,应用直连数据库,降低外围系统依赖所带来的宕机风险;
  • 业务零侵入,配置简单;
  • 站在巨人的肩膀上(springjdbc、基于druid的sqlparser完成sql解析任务),执行性能高效、稳定;
  • 提供多机sequenceid的API支持,解决多机sequenceid难题;
  • 缺省支持基于zookeeper、redis3.x cluster作为集中式资源配置中心;
  • 基于velocity模板引擎渲染内容,支持sql语句独立配置和动态拼接,与业务逻辑代码解耦;
  • 提供内置验证页面,方便开发、测试及运维人员对执行后的sql进行验证;
  • 提供自动生成配置文件的API支持,降低配置出错率;

同样,也有很多限制:

  • 不支持强一致性的分布式事务,建议在业务层依赖MQ,保证最终数据一致性;
  • 不建议、不支持多表查询,所有多表查询sql,务必全部打散为单条sql逐条执行;
  • sql语句的第一个参数务必是shard key;
  • shard key必须是整数类型;

项目的Git:https://github.com/gaoxianglong/shark,个人要支持一下,希望能继续增强改进。

五、总结

通过上面四个主要的分布式数据访问服务/框架的比较,我们深入研究了分布式数据访问技术,有以下收获分享给大家:

1. 分布式数据访问组件基于物理上的数据库分库分表,主要解决数据库的横向扩展问题

2. 业界主流的分布式数据访问组件主要面向CRUD操作,复杂查询的实现依赖于数据仓库、分析型数据库、大数据分析等技术来实现

3. Sharding策略和SQL路由是实现分库分表的关键技术,其中Sharding的粒度:主要有两种:Database(数据库) 和 Table(表),即分库和分表

4. Sharding策略主要有以下几种:时间范围、ID哈希、地理区域、Hash分区、枚举分区、表达式计算分区等等

5. 分区键的设计非常重要,阿里的实践值得借鉴:用户和商品两个维度,满足不同用户的需求

6. 分库分表后的复杂查询是一个大的技术挑战:需要解决跨库Join、跨多个Shard查询合并、存储过程、综合BI查询等等,可能需要引入数据仓库和大数据技术来实现

7. 还有分布式事务问题需要解决,阿里有个TXC,可以学习了解借鉴。

综合起来说,分布式数据访问服务是大规模分布式应用的必备中间件,技术复杂度和难度都很高,涉及的技术栈比较多,同时比较深,我们会继续深入研究,

目标是设计一套.Net版本的分布式数据访问服务。有兴趣的小伙伴,可以一起搞。

 

 

周国庆

2017/4/20

 

阅读更多
换一批

没有更多推荐了,返回首页