数据库中间件cobar调研笔记

开发 开发工具
分库后,join怎么实现,group by怎么实现?13年底负责数据库中间件设计时的调研笔记,拿出来和大家分享,轻拍。

13年底负责数据库中间件设计时的调研笔记,拿出来和大家分享、轻拍。

一、cobar是什么

  • 阿里开源的mysql的中间件服务
  • 使用mysql协议
  • 对上游,cobar就是传统mysql数据库
  • 对上游,它屏蔽后端分布式mysql集群

画外音:数据库中间件有基于服务端的,也有基于客户端的,cobar属于前者。

二、cobar应用场景举例

obar应用场景举例

逻辑上:

  • 数据库dbtest(虚拟的)
  • 表tb1和tb2

物理上:

  • tb1表的数据在dbtest1(物理的)的tb1上
  • tb2表的一部分数据在dbtest2(物理的)的tb2上,另外一部分在dbtest3(物理的)的tb2上

三、cobar使用方式

  • 命令行:连dbtest虚拟库
  • JDBC:也是连dbtest虚拟库

cobar使用方式

查看db:

查看db

可看到dbtest1、dbtest2、dbtest3对用户透明。

查看table:

查看table

可看到有tb1和tb2两张表。

插入一些数据,对用户而言,后端的分布式mysql是透明的:

  • 对tb1,数据实际上存在dbtest1的tb1中
  • 对tb2,数据实际上存储在dbtest2和dbtest3的tb2中

画外音:从其官网上看,自12年12月之后,cobar就没有再更新过,官方微博也非常不活跃,不清楚现在它在阿里的使用情况,知道的同学请说一说。

四、cobar不支持什么

  • 不支持夸库join,分页,排序,子查询
  • set语句会被忽略(事务和字符集设置除外)
  • 如果分库,insert必须包含patition key(否则麻烦大了)
  • 如果分库,patition key不能被update
  • 不支持读写分离
  • 不支持存储过程
  • 如果使用JDBC,rewriteBatchedStatements,useServerPrepStmts,BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()

五、cobar支持什么

1. 分布式数据库:通过分库实现

  • 支持一张表放到不同的库
  • 支持不同的表放入不同的库

需要注意:不支持将test拆分成test_1,test_2,test_3并放入同一个库中这样的拆分方式。

画外音:后者正是360的atals的做法(atlas只支持单实例单库分表)。

2. HA:通过到mysql的心跳实现

  • 主机挂了会自动切换回备机,但主机恢复,需要手动切回
  • 只检测主备异常,不关心主备数据同步(需要dba手动配)

画外音:需要注意,cobar是需要用户自己来实现负载均衡的,方式有三种:

  • 自己使用软件例如LVS
  • 自己使用硬件例如F5
  • cobar提供了命令获取集群信息,用户可以根据这些信息做负载均衡;当然,淘宝已经实现了一个具有负载均衡功能的cobar客户端产品-cobar.driver

3. SQL路由

在分库的情况下,cobar会从sql中提取partition key列,来判断SQL被路由到哪一个分库进行执行;如果没有带partition key,则会将SQL分发到所有分库执行。

4. 示例

tb1(id INT)

假设以id切分数据,后端分了N个库:

  1. insert into tb1 values(1); 
  2. => N个库都会执行插入,因为没有带partition key; 
  1. insert into tb1(id) values(1); 
  2. => 只会路由到1个库,带了partition key; 
  1. update tb1 set id=2 where id=1
  2. => 不支持,不能修改partition key; 

画外音:SQL带上partition key对cobar来说,非常非常重要,并且partition key不支持修改(修改了库就不对了哟)。

cobar不允许在同一个连接中切换库。

画外音:数据库连接和库是绑定关系。

不建议通过cobar来执行DDL语句。

画外音:所以建库,建索引什么的,还是直连mysql自己搞吧。

5. COBAR自定义语句

(1) 查询cobar节点的状态

cobar允许管理员通过管理命令上线和下线cobar节点。

(2) 查询cobar集群的状态

查询cobar集群的状态

被定义在一个cobar集群中的cobar节点之间都会发送心跳,所谓的心跳就是上面提到的show cobra_status; 这样的话,就为每一个cobar节点提供了知道同一个集群内的所有cobar信息的机会。当然,被下线,或者心跳超时的cobar节点的信息不会被显示出来。

(3) 查询SQL语句的路由情况

查询SQL语句的路由情况

SQL语句前加上explain即可知道SQL语句的路由情况。

6. 事务的支持

cobar对单库保持事务的强一致性。

对分库保持事务的弱一致性。

分库后事务提交包含两个阶段:

  • 执行阶段:SQL按照规则被路由到多个分库,此时发生错误,还能回滚
  • 提交阶段:提交阶段出错,无法正确回滚

事务的支持

两个阶段之间,执行与提交串行处理,阶段内部各个分库并行处理。

画外音:额,基本就是不支持分布式事务。

六、cobar系统架构

1. 系统模块图

系统模块图

画外音:从模块图来看,cobar的结构还是挺清晰的:

(1) 前端对上游的连接池

(2) 后端对下游mysql的连接池

(3) 对每一个请求,会经过:

  • SQL分析
  • SQL路由
  • SQL执行
  • 投递给后端mysql

(4) 对每一个响应,需要做结果合并

2. 数据流图

数据流图和上述模块图对应:

数据流图和上述模块图对应

3. 网络模型

采用异步网络模型:

采用异步网络模型

4. 结果合并

会把多个物理库的结果集合并,再返回给上游:

会把多个物理库的结果集合并,再返回给上游

七、cobar路由算法

  • partition key是int时:好办,直接取模
  • partition key是string时:f(string) = hash(string) % 1024

假设分4个库:

  • 哈希结果0-255 -> 库1
  • 哈希结果256-511 -> 库2
  • 哈希结果512-767 -> 库3
  • 哈希结果768-1024 -> 库4

如何扩容:

  • 哈希结果0-255 -> 库1

拆分后:

  • 哈希结果0-127 -> 库1.1
  • 哈希结果128-255 -> 库1.2

数据非均匀分布路由:

  • 哈希结果0-511(513范围) -> 库1
  • 哈希结果512-767(256范围) -> 库2
  • 哈希结果768-895(128范围) -> 库3
  • 哈希结果896-1023(128范围) -> 库4

八、cobar对于SQL的转发

1. 带partition key单记录查询

带partition key单记录查询

直接根据partition key路由。

2. 带partition key的IN查询

带partition key的IN查询

将IN进行拆分,请求发到对应多个分库,然后将结果集合并。

3. 不带partition key的where查询

不带partition key的where查询

假设partition key是user字段,在product字段上的where查询,会将请求广播到所有分库,然后将结果集合并。

4. 二维partition key

一张表的多个字段同时作为定位库的拆分字段,仍以上图的visit(product, user, info)为例,可以以product和user两个字段来同时来定位库。

二维partition key

横坐标product属性取hash,纵坐标user属性取hash。

二维partition key

 

  1. SELECT * FROM visit WHERE product=‘ColaCola’ AND user=‘A’ 

对于上述业务需求,同时带有两个列作为查询条件,可以直接定位到库7。

但是,此时如果只有其中的一个字段作为查询条件,反而得查询多个库,再做聚合:

聚合

  1. SELECT * FROM visit WHERE product=‘ColaCola’ 

对于上述业务需求,就必须查询库3,7,11,15了。

画外音:不懂为什么要按照双key来做路由,单key路由,对于双key的查询,也没有增加多少数据扫描量啊,加入双key反而使得某些情况下策略复杂了,带来的收益也不高。

5. 小结

对的,对于where,cobar就是这样的处理方式:

  • 根据字段的一致性hash分布数据
  • 多维拆分
  • 根据where中的partition key分发查询
  • SQL语句变换,分发至各个分库执行,对结果进行合并

九、cobar的高级特性

1. JOIN有限的处理

JOIN有限的处理

如上,两个表都进行了分库,JOIN需求如下:

  1. SELECT * FROM tb1 INNER JOIN tb2 
  2.     ON tb1.MEMBER_ID=tb2.NAME 

结果集理应如下:

方案一:迭代查询

  1. FOR row1 IN select * FROM tb1{ 
  2.     ADD( 
  3.         SELECT* FROM tb2 WHERE 
  4.           tb2.name = row1.member_id 
  5.     )TO RESULT 

画外音:我去,外层循环是对tb1中的所有记录,在tb2来一遍扫描,bt1数据量大的情况下,这哪里受得了?

方案二:夸库索引

对于tb1和tb2存在的潜在JOIN需求,对JOIN列建立夸库索引。

  • 直接JOIN查询:建立了夸库索引后,对于JOIN的直接查询,就是idx索引表内的数据的合并就是结果
  • JOIN后带WHERE条件:
    1. SELECT * FROM tb1 INNER JOIN tb2 
    2. ON tb1.MEMBER_ID=tb2.NAME 
    3.       WHEREtb1.id=5 

此时需要改写SQL语句,直接在索引表上进行查询:

  1. 此时需要改写SQL语句,直接在索引表上进行查询: 
  2. SELECT * FROM idx WHERE id1=5 

此处需要注意:

  • 索引表的partition key:WHERE条件所在表的partition key,作为索引表的partition key
  • 索引必须包含参与JOIN相关表的主键,JOIN字段,包含WHERE条件的字段
  • 索引的更新:需要分布式事务的支持

2. GROUP BY的处理

GROUP BY的处理

以上表为例,patition key是ID,要在C1上进行GROUP BY操作:

  1. SELECT SUM(price) FROM tb1 GROUP BY c1; 

改写SQL语句,先在各个分库上GROUP BY一次,并将sum计算出来:

  1. SELECT SUM(price), c1 FROM tb1 GROUP BY c1 ORDER BY c1; 

各分库进行GROUP BY + ORDER BY + sum之后,根据排序后的c1及对应sum结果,归并一遍后即得到最终结果。

3. 小结

对于复杂语句,可以这样处理:

  • 对于JOIN,可以迭代查询,或者使用分布式索引
  • 对于GROUP BY,需要增加查询列,以及ORDER BY

13年底的调研笔记,文中的“画外音”是我当时的批注,希望能让大家对cobar能有一个初步的认识,有疑问之处,欢迎交流。

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2017-11-27 05:36:16

数据库中间件TDDL

2017-12-01 05:04:32

数据库中间件Atlas

2018-02-24 19:37:33

Java8数据库中间件

2017-05-23 18:55:05

mysql-proxy数据库架构

2011-08-10 13:03:58

CJDBC数据库集群

2017-07-26 09:41:28

MyCATSQLMongoDB

2017-11-30 08:56:14

数据库中间件架构师

2017-07-18 17:35:16

数据库MyCATPreparedSta

2017-11-03 11:02:08

数据库中间件

2017-12-11 13:30:49

Go语言数据库中间件

2017-12-01 05:40:56

数据库中间件join

2017-11-27 06:01:37

数据库中间件中间层

2017-07-18 17:07:40

数据库 MyCATJoin

2009-01-20 10:45:55

Oracle数据库中间件

2020-10-15 08:34:32

数据库中间件漫谈

2021-07-27 05:49:59

MySQL数据库中间件

2018-11-07 15:30:19

数据库NewSQLNoSQL

2009-11-10 16:48:23

中间件操作系统数据库

2022-04-01 10:55:30

数据库混合云建设

2014-01-16 13:35:35

OracleVerizon
点赞
收藏

51CTO技术栈公众号