专栏首页架构师之路数据库中间件cobar调研笔记

数据库中间件cobar调研笔记

13年底负责数据库中间件设计时的调研笔记,拿出来和大家分享,轻拍。文章很长,可提前收藏,转发。

一,cobar是什么

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

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

二,cobar应用场景举例

逻辑上:

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

物理上:

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

三,cobar使用方式

命令行:连dbtest虚拟库

JDBC:也是连dbtest虚拟库

查看db

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

查看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支持什么

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

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

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

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

HA:通过到mysql的心跳实现

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

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

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

SQL路由

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

示例

tb1(id INT)

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

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

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

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

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

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

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

COBAR自定义语句

  • 查询cobar节点的状态

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

  • 查询cobar集群的状态

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

  • 查询SQL语句的路由情况

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

事务的支持

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

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

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

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

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

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

六,cobar系统架构

系统模块图

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

  • 前端对上游的连接池
  • 后端对下游mysql的连接池
  • 对每一个请求,会经过: SQL分析 SQL路由 SQL执行 投递给后端mysql
  • 对每一个响应,需要做结果合并

数据流图

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

网络模型

采用异步网络模型:

结果合并

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

八,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的转发

带partition key单记录查询

直接根据partition key路由。

带partition key的IN查询

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

不带partition key的where查询

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

二维partition key

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

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

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

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

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

SELECT * FROM visit WHERE product=‘ColaCola’

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

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

小结

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

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

十,cobar的高级特性

JOIN有限的处理

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

SELECT * FROM tb1 INNER JOIN tb2

ON tb1.MEMBER_ID=tb2.NAME

结果集理应如下:

方案一:迭代查询

FOR row1 IN select * FROM tb1{

ADD(

SELECT* FROM tb2 WHERE

tb2.name = row1.member_id

)TO RESULT

}

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

方案二:夸库索引

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

  • 直接JOIN查询:建立了夸库索引后,对于JOIN的直接查询,就是idx索引表内的数据的合并就是结果
  • JOIN后带WHERE条件

SELECT * FROM tb1 INNER JOIN tb2

ON tb1.MEMBER_ID=tb2.NAME

WHEREtb1.id=5

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

SELECT * FROM idx WHERE id1=5

此处需要注意:

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

GROUP BY的处理

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

SELECT SUM(price) FROM tb1 GROUP BY c1;

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

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

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

小结

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

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

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

本文分享自微信公众号 - 架构师之路(road5858),作者:58沈剑

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-11-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 数据库中间件为何不支持join

    有网友对《假如让你来设计数据库中间件》一文中,数据库中间件仅仅支持四类SQL存有疑问: partition key普通查询 partition key上的IN查...

    架构师之路
  • 构建基于ServiceMesh的中台架构

    微服务架构中,随着数据量不断增大,吞吐量不断增加,业务越来越复杂,服务的个数会越来越多,分层会越来越细,除了数据服务层,还会衍生出业务服务层,前后端分离等各种层...

    架构师之路
  • 细聊冗余表数据一致性(架构师之路)

    本文主要讨论四个问题: (1)为什么会有冗余表的需求 (2)如何实现冗余表 (3)正反冗余表谁先执行 (4)冗余表如何保证数据的一致性 一、需求缘起 互联网很多...

    架构师之路
  • 【iOS】关联对象详解前言参考文章

    VV木公子
  • HashMap? ConcurrentHashMap? 相信看完这篇没人能难住你!

    Map 这样的 Key Value 在软件开发中是非常经典的结构,常用于在内存中存放数据。

    端碗吹水
  • SQL Tuning 基础概述05 - Oracle 索引类型及介绍

    外键上建立索引:不但可以提升查询效率,而且可以有效避免锁的竞争(外键所在表delete记录未提交,主键所在表会被锁住)。

    Alfred Zhao
  • 王老板Python面试(2): 常见的Python爬虫面试题,让你轻松拿offer!

    有些自学爬虫(python)的同学因为没有经历过专业面试,所以在找工作之前难免有些抓不住重点。即便掌握技术熟练,却因为发挥不好而错失工作机会。今天就和大家分享几...

    Python之道
  • Redis - sort set类型操作

    Aichen
  • 今天要去清华听LeCun演讲?你需要这份笔记(另附:视频+PPT)

    若朴 发自 凹非寺 量子位·QbitAI 报道 ? △ 这张票有点抢手 早就没票了。 今天下午,Facebook人工智能研究院院长Yann LeCun,将在清华...

    量子位
  • Python 基础(二十一):argparse 模块

    argparse 模块主要用于处理 Python 命令行参数和选项,程序定义好所需参数后,该模块会通过 sys.argv 解析出那些参数;除此之外,argpar...

    Python小二

扫码关注云+社区

领取腾讯云代金券