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

有网友对《假如让你来设计数据库中间件》一文中,数据库中间件仅仅支持四类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上的查询
  • 有限功能的排序+分页查询

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

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

原文发布于微信公众号 - 架构师之路(road5858)

原文发表时间:2017-11-29

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏牛客网

迟到的贝壳面经

上周末在北京贝壳的一面+二面经历,很遗憾,二面没有通过,与其埋怨面试官问的太深太细,不如找找自己的原因。 

1162
来自专栏牛客网

(19实习)51信用卡Java面经

1865
来自专栏牛客网

阿里 & 酷家乐:实习生面试

最近海投了十家公司,暂时有阿里两面(已凉)、酷家乐两面(大概凉了)、网易一面。前两个都是基础知识发挥得还可以,两家公司二面都凉凉。 阿里一面(3.21 26mi...

5524
来自专栏PPV课数据科学社区

用R进行文本挖掘与分析:分词、画词云

要分析文本内容,最常见的分析方法是提取文本中的词语,并统计频率。频率能反映词语在文本中的重要性,一般越重要的词语,在文本中出现的次数就会越多。词语提取后,还可以...

5124
来自专栏牛客网

今日头条测试实习生面经#  一面#二面#三面

2133
来自专栏菜鸟前端工程师

react-开发经验分享-async与生命周期函数

1052
来自专栏Hadoop数据仓库

HAWQ取代传统数仓实践(九)——维度表技术之退化维度

        退化维度技术减少维度的数量,简化维度数据仓库模式。简单的模式比复杂的更容易理解,也有更好的查询性能。         有时,维度表中除了业务主键...

2405
来自专栏北京马哥教育

MySQL入门书籍和方法分享

前言:在chinaunix上总是有很多同学咨询想学习数据库,或者是为入行DBA做些准备。几年来作为一个MySQL DBA的成长过程有一些积累和感悟,特此拿出来...

3694
来自专栏用户2442861的专栏

如何面试Python后端工程师?

http://blog.csdn.net/yueguanghaidao/article/details/49638261

2611
来自专栏更流畅、简洁的软件开发方式

关于Int自增字段和GUID字段的性能测试。只有测试,没有分析,呵呵

      最近有两篇关于GUID和Int自增的文章,我是一直使用Int自增的,不习惯使用GUID,感觉GUID很麻烦,用着不方便,性能也比不上Int自增。但是...

25910

扫码关注云+社区

领取腾讯云代金券