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

转自: http://mp.weixin.qq.com/s/q4DmWjhVmMMSzIP3K_n4Hw    架构师之路

有网友对《假如让你来设计数据库中间件》一文中，数据库中间件仅仅支持四类SQL存有疑问：

• partition key普通查询

• partition key上的IN查询

• 非partition key上的查询

• 有限功能的排序+分页查询

这四类SQL就能满足公司业务的需求么，这个结论是怎么来的？

看来《假如让你来设计数据库中间件》的架构结论并不能让刨根究底的网友们满意，于是把13年底，需求调研的过程细节也说一说，作为一个一线架构师，治学还是得严谨。

 

一、业务侧的分库后SQL需求

先说结论，通过初步的调研，发现58各业务线对有分库需求的应用场景为：

• partition key上的简单查询

  WHERE key=xxx AND xxx

• partition key上的IN查询

  WHERE key IN(xxx, yyy) AND xxx

• 非partition key上的简单查询

  WHERE notkey=xxx AND xxx

• 排序+分页的需求

  ORDER BY xxx OFFSET xxx LIMIT xxx

大部分需求集中在前三条，排序+分页的需求由于分布式实现困难，各业务线往往也采用了一些限制或者变通手段实现，例如：

• 建立索引表以避免遍历库再内部排序

• 使用额外的id查询条件来避免大数据量的查询

 

调研结果显示，各业务线暂没有下列需求：

• 夸库join

• 夸库事务

• 夸库子查询

• 其他奇形怪状的SQL

二、搜索研发部调研

从搜索研发部高级架构师@longc 处了解到，暂时没有数据库分库需求。

画外音：@龙神 做搜索内核，压根瞧不起我这个用MySQL搞业务的人呀。

 

三、即时通讯部调研

和@sunx 进行了沟通，帮帮技术部没有水平分库，只有水平分表，业务需求为常见需求中的“partition key上的普通查询”。

对于58帮帮的“用户登陆表”，数据量较大，目前分为32个表，以uid作为partition key，所有的查询都会带上partition key，故可以直接定位到数据所属的partition。

如上例，假设58帮帮对某数据量较大的表以id为partition key分了3个表，上游的所有查询都会带上id=xxx这个查询条件（当然，亦可以同时带上其他查询条件）。

画外音：@玄姐 设计的系统，架构考虑得极其完善。

 

四、移动研发部调研

从@liunz 了解到，无线分库使用场景和帮帮技术部类似，都是“partition key 上的普通查询”。

 

五、架构部调研

从@liuzw 了解到，架构部在imc，umc等服务使用水平分库，业务需求为常见需求中的“patition key 上的普通查询”，“partition key上的IN查询”，“非partition key上的查询”。

对于“partition key上的IN查询”，架构部采用的是将各个partition key定位到相关的库，最后将查询结果集汇总，再返回上游的方式来实现。注意，如上图所示，带partition key的IN查询并不一定会遍历所有的库。

 

对于“非partition key上的查询”，根据不同的业务，架构部有两种处理方式：

方式一

业务方不需要精确数据，随机取一个库的数据，即可满足业务方要求，例如“查询10个有头像的用户”

当业务方不需要关注结果集的精确性时，可以随机取一个库查询。

画外音：这是一个很好的设计，典型的“根据业务需求确定技术方案”的good case。

方式二

业务方需要精确数据，就必须遍历所有的库，例如“查询用户名为shenjian的用户”。

画外音：uid的生成没有采用“基因法”，非常遗憾。关于“基因法”的方案详见《单KEY业务，数据库水平切分架构实践 | 架构师之路》。

六、会员技术部调研

从@wangzt 了解到，会员技术部使用水平分库，调研结论里对分库的四种SQL需求在业务中都有用到。

对“非partition key上的查询”，除了使用架构部使用的全库查询方案，会员技术部还是用了冗余数据法来解决这个问题：

这种查询方式使用冗余数据来避免全库查询，缺点是可能存在数据一致性问题。

 

“夸库分页查询”，会员技术部的处理方式是索引表：

使用订单分库，买家的查询查询索引表，索引表的本质也是冗余。

画外音：关于“帖子业务的水平切分”的方案详见《1对多业务，数据库水平切分架构一次搞定 | 架构师之路》。

七、支付平台部调研

从@hudp 了解到，分库的数据访问，货币系统部所有的线上实时业务都必须携带partition key，故其访问模式和即时通讯的数据访问模式相同。

 

但对于支撑系统/统计需求，在分库数据上，他们计划引入cobar来解决他们的问题。

 

八、前端业务部调研

从@wangjk 了解到，前端业务部这边，四种分库SQL都有，对于夸库分页，前端业务部这边的业务上要求必须带上一个特殊的id作为where字段，以避免拉取大量的数据重新排序。

九、结论

58如果要做数据库中间件，一期支持四类SQL：

• partition key普通查询

• partition key上的IN查询

• 非partition key上的查询

• 有限功能的排序+分页查询

能够满足业务线绝大部分分库的需求。

一切脱离业务的架构设计，都是耍流氓。

做技术要严谨，除了上述需求调研，也做了充分的技术调研：

《数据库中间件TDDL调研笔记》

《数据库中间件cobar调研笔记》

《数据库中间件mysql-proxy调研笔记》

才有了后来的概要设计：

《假如让你来设计数据库中间件》