前篇:
13年底负责数据库中间件设计时的调研笔记,拿出来和大家分享,轻拍。
一,TDDL是什么
画外音:数据库中间件有基于服务端的,也有基于客户端的,TDDL属于后者;而cobar是一个中间层服务,使用mysql协议,属于前者。
二,TDDL不支持什么SQL
画外音:分布式数据库中间件,join都是很难支持的,cobar号称的对join的支持即有限,又低效。
三,TDDL支持什么SQL
画外音:分布式数据库中间件,支持的语法都很有限,但对于与联网的大数据/高并发应用,足够了,服务层应该做更多的事情。
画外音:可以看到,其实TDDL很多东西都不支持,那么为什么它还如此流行呢?它解决的根本痛点是“分布式”“分库分表”等。
加入了解决“分布式”“分库分表”的中间件后,SQL功能必然受限,但是,我们应该考虑到:MYSQL的CPU和MEM都是非常珍贵的,我们应该将MYSQL从复杂的计算(事务,JOIN,自查询,存储过程,视图,用户自定义函数,,,)中释放解脱出来,将这些计算迁移到服务层。
当然,有些后台系统或者支撑系统,数据量小或者请求量小,没有“分布式”的需求,为了简化业务逻辑,写了一些复杂的SQL语句,利用了MYSQL的功能,这类系统并不是分布式数据库中间件的潜在用户,也不可能强行让这些系统放弃便利,使用中间件。
层次 | 说明 | 其他 |
---|---|---|
matrix | 可以理解为数据源的全部,它由多个group组成 | |
group | 可以理解为一个分组,它由多个atom组成 | |
atom | 可以理解为一个数据库,可能是读库,也可能是写库 |
对应上面图例:matrix数据水平分为了两个group,每个group有主备atom组成。
matrix层
group层
atom层
整个SQL执行过程
画外音:感觉难点在SQL的解析上。
画外音:这里我展开一下这个使用场景。
以电商的买家卖家为例,业务方既有基于买家的查询需求,又有基于卖家的查询需求,但通常只能以一个纬度进行数据的分库(patition),假设以买家分库, 那卖家的查询需求如何实现呢?
如上图所示:查询买家所有买到的订单及商品可以直接定位到某一个分库,但要查询卖家所有卖出的商品,业务方就必须遍历所有的买家库,然后对结果集进行合并,才能满足需求。
所谓的“数据增量复制”“表结构冗余”“减少网络次数”,是指所有的数据以买家卖家两个纬度冗余存储两份,如下图:
采用一个异步的消息队列机制,将数据以另一个纬度增量复制一份,在查询的时候,可以直接以卖家直接定位到相应的分库。
这种方式有潜在的数据不一致问题。
继续tddl最佳实践:
画外音:相比数据库中间件内核,最佳实践与存储模型,对我们有更大的借鉴意义。
七、TDDL的未来?
画外音:潜台词是,在大数据量高并发下,SQL不是大势所趋,no-sql和定制化的协议+存储才是未来方向?
13年底的调研笔记,文中的“画外音”是我当时的批注,希望能让大家对TDDL能有一个初步的认识,有疑问之处,欢迎交流。