有网友对《假如让你来设计数据库中间件》一文有疑问，数据库中间件只支持四种SQL：分区键普通查询分区键上的IN查询非分区键查询功能有限排序+分页查询等四种SQL能否满足公司业务的需求？这个结论是怎么得来的？似乎《假如让你来设计数据库中间件》的架构结论并不能满足追问的网友们，所以2013年底的需求调研我也来说说过程的细节吧。作为一线架构师，学业还是要严谨的。1、业务端分库后的SQL需求先总结。通过初步调研发现58条业务线对应用场景有分库需求：分区键简单查询：WHEREkey=xxxANDxxxonpartitionkeyINquery:WHEREkeyIN(xxx,yyy)ANDxxx简单查询onnon-partitionkey:WHEREnotkey=xxxANDxxx排序+分页需求：ORDERBYxxxOFFSETxxxLIMITxxx的需求大部分集中在前三项，排序+分页需求分布式实现难度大，每个业务线往往会采取一些限制或workaround，例如：建立索引表，避免遍历库和内部排序使用额外的id查询条件，避免大量数据的查询研究结果显示，每个业务线目前没有需求如下：KuakujoinKuakutransactionKuakusub-query其他奇形怪状的SQL2.搜索研发部Research学习@longc，资深架构师搜索研发部，暂时不需要数据库分库。画外音：@龙神是个搜索内核，根本看不起用MySQL做生意的人。3、即时通讯部门的研究与@sunx沟通，帮助技术部门无横向分库，只有横向分表，业务需求为普通需求中的“分区键普通查询”。58帮的“用户登录表”，数据量较大，目前分为32张表。Uid用作分区键。所有的查询都会携带partitionkey，所以可以直接定位到数据所属的partition。如上例，假设58帮将一个数据量较大的表拆分为三个以id为分区键的表，则所有上游查询都会携带id=xxx的查询条件（当然其他查询条件也可以也可以同时携带）。画外音：@玄姐设计的系统，架构设计的很周到。4、移动研发部的研究从@liunz处了解到，无线分库的使用场景和帮助技术部的类似，都是“partitionkey上的普通查询”。5.架构部的研究从@liuzw处了解到，架构部在imc、umc等业务中使用水平分库，业务需求为“patitionkey上的公共查询”、“partitionkey上的IN查询”、“查询非分区键”。对于“INqueryonpartitionkey”，架构部采用了将每个partitionkey定位到相关库，最终汇总查询结果集，再返回上游的方式实现。注意，如上图所示，带分区键的IN查询不一定遍历所有库。对于“非分区键的查询”，根据不同的业务，架构部有两种处理方式：1、方式1、业务方不需要准确的数据，从数据库中随机取数据即可满足业务的要求边。比如“查询10个有头像的用户”，当业务方不需要关注结果集的准确性时，可以随机选择一个库查询。画外音：这是一个很好的设计，典型的“根据业务需求确定技术方案”的好案例。2、方法二、如果业务方需要准确的数据，则必须遍历所有的库，例如“查询用户名为shenjian的用户”。画外音：很遗憾uid的生成没有使用“遗传法”。“基因法”计划详见《单KEY业务，数据库水平切分架构实践 | 架构师之路》。6.会员技术部研究从@wangzt了解到，会员技术部使用水平分库，研究结论中对分库的4个SQL需求在业务中都有使用。对于“非分区键的查询”，除了使用架构部使用的全库查询方案外，会员技术部还采用了冗余数据的方式来解决这个问题：这种查询方式使用冗余数据来避免全库查询，缺点是可能存在数据一致性问题。“隔离库分页查??询”，会员技术部的处理方式是索引表：使用订单分库，采购商查询查询索引表，索引表的本质也是多余的。画外音：《邮政业务横向细分》方案见《1对多业务，数据库水平切分架构一次搞定 | 架构师之路》。7、支付平台部的研究从@hudp了解到，分库的数据访问和币系统部的所有在线实时业务都必须携带partitionkey，所以访问方式和即时通讯是一样的.但是为了支持系统/统计需求，他们打算引入cobar来解决他们在分库数据上的问题。8.前端业务部研究从@wangjk处了解到，前端业务部有4条分库SQL。对于跨酷分页，前端业务部的业务要求必须包含一个特殊的id作为where字段，避免拉取大量数据重新排序。九。结论58如果要做数据库中间件，一期支持四种SQL：partitionkeycommonqueryINqueryonpartitionkeyqueryonnon-partitionkeylimitedfunctionsorting+pagingquery可以满足大部分业务的分库线路需求。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
