其他分享
首页 > 其他分享> > 分库分表下跨库join解决方案

分库分表下跨库join解决方案

作者:互联网

携程酒店订单Elastic Search实战:http://www.lvesu.com/blog/main/cms-610.html

为什么分库分表后不建议跨分片查询:https://www.jianshu.com/p/1a0c6eda6f63

分库分表技术演进(阿里怎么分):https://mp.weixin.qq.com/s/3ZxGq9ZpgdjQFeD2BIJ1MA

 

1.需求背景

移动互联网时代,海量的用户每天产生海量的数量,这些海量数据远不是一张表能Hold住的。比如

2.选择方案

(1)NoSQL/NewSQL(不选择)

     选择RDBMS,不选择NoSQL/NewSQL,主要是因为NoSQL/NewSQL可靠性无法与RDBMS相提并论。RDBMS有以下几个优点:

     目前绝大部分公司的核心数据都是:以RDBMS存储为主,NoSQL/NewSQL存储为辅!互联网公司又以MySQL为主,国企&银行等不差钱的企业以Oracle/DB2为主!NoSQL比较具有代表性的是MongoDB,es。NewSQL比较具有代表性的是TiDB。

(2)分区(不选择)

(3)分库分表(选择)

 互联网行业处理海量数据的通用方法:分库分表。 分库分表中间件全部可以归结为两大类型:

 CLIENT模式代表有阿里的TDDL,开源社区的sharding-jdbc(sharding-jdbc的3.x版本即sharding-sphere已经支持了proxy模式)。架构如下:

PROXY模式代表有阿里的cobar,民间组织的MyCAT。架构如下:

 

 无论是CLIENT模式,还是PROXY模式。几个核心的步骤是一样的:SQL解析,重写,路由,执行,结果归并。

 3.分库分表思路(MYSQL)

阿里:选用orderid分表,那我用userid来查询的很多,那不是所有的分表都要查?怎么处理

以阿里订单系统为例(参考《企业IT架构转型之道:阿里巴巴中台战略思想与架构实现》),它选择了三个column作为三个独立的sharding column,即:order_id,user_id,merchant_code。user_id和merchant_code就是买家ID和卖家ID,因为阿里的订单系统中买家和卖家的查询流量都比较大,并且查询对实时性要求都很高。而根据order_id进行分库分表,应该是根据order_id的查询也比较多。

4.分库分表落地(MYSQL)

(1)选择合适的sharding column

   分库分表第一步也是最重要的一步,即sharding column的选取,sharding column选择的好坏将直接决定整个分库分表方案最终是否成功。sharding column的选取跟业务强相关。

(2)冗余全量表和冗余关系表选择(订单表)

例如将一张订单表t_order拆分成三张表t_order、t_user_order、t_merchant_order。分别使用三个独立的sharding column,即order_id(订单号),user_id(用户ID),merchant_code(商家ID)。

冗余全量表:每个sharding列对应的表的数据都是全量的

 

 冗余关系表:只有一个sharding column的分库分表的数据是全量的,其他分库分表只是与这个sharding column的关系表。实际使用中可能会冗余更多常用字段,如用户名称、商户名称等。

冗余全量表 VS 冗余关系表

总结:选择冗余全量表还是索引关系表,这是一种架构上的trade off(权衡),两者的优缺点明显,阿里的订单表是冗余全量表。

 (3)单个sharding column分库分表示例(账户表)

一般账户相关API使用account_no为sharding column

(4)多个sharding column分库分表示例(用户表)

用户可以通过mobile_no,email和username进行登录,一些用户相关API又常使用user_id,所以sharding column选这4个字段。

 (5)sharding column分库分表 + ES检索(模糊查询)

上面提到的都是条件中有sharding column的SQL执行。但是,总有一些查询条件是不包含sharding column的,同时,我们也不可能为了这些请求量并不高的查询,无限制的冗余分库分表。那么这些查询条件中没有sharding column的SQL怎么处理?以sharding-jdbc为例,有多少个分库分表,就要并发路由到多少个分库分表中执行,然后对结果进行合并。这种条件查询相对于有sharding column的条件查询性能很明显会下降很多。

更有甚者,尤其是有些运营系统中的模糊条件查询,或者上十个条件筛选。例如淘宝我的所有订单页面,筛选条件有多个,且商品标题可以模糊匹配,这即使是单表都解决不了的问题,更不用谈分库分表了。

sharding column + es的模式,将分库分表所有数据全量冗余到es中,将那些复杂的查询交给es处理。(ElasticSearch,搜索引擎)以订单表为例:

 PS:多sharding column不到万不得已的情况下最好不要使用,建议采用单sharding column + es的模式简化架构。

5.全文索引思路(HBase)

可能参与条件检索的字段索引到ES中,所有字段的全量数据保存到HBase中,这就是经典的ES+HBase组合方案,即索引与数据存储隔离的方案。Hadoop体系下的HBase存储能力我们都知道是海量的,而且根据它的rowkey查询性能那叫一个快如闪电。而es的多条件检索能力非常强大。这个方案把es和HBase的优点发挥的淋漓尽致,同时又规避了它们的缺点,可以说是一个扬长避免的最佳实践。

它们之间的交互大概是这样的:先根据用户输入的条件去es查询获取符合过滤条件的rowkey值,然后用rowkey值去HBase查询,后面这一查询步骤的时间几乎可以忽略,因为这是HBase最擅长的场景,交互图如下所示: 

 

6.总结

最后,对几种方案总结如下(sharding column简称为sc):

对于海量数据,且有一定的并发量的分库分表,绝不是引入某一个分库分表中间件就能解决问题,而是一项系统的工程。需要分析整个表相关的业务,让合适的中间件做它最擅长的事情。例如有sharding column的查询走分库分表,一些模糊查询,或者多个不固定条件筛选则走es,海量存储则交给HBase。

做了这么多事情后,后面还会有很多的工作要做,比如数据同步的一致性问题,还有运行一段时间后,某些表的数据量慢慢达到单表瓶颈,这时候还需要做冷数据迁移。

 

MySQL单表可以存储10亿级数据,只是这时候性能比较差,业界公认MySQL单表容量在1KW以下是最佳状态,因为这时它的BTREE索引树高在3~5之间。

 

参考文档:

分库分表技术演进&最佳实践-修订篇

HBase应用实践专场-HBase for Solr

分库分表思路

基于Solr的HBase多条件查询测试

 

转自:https://www.cnblogs.com/badboy200800/p/9790395.html

转载于:https://www.cnblogs.com/twoheads/p/10715498.html

标签:分库,join,column,跨库,查询,分表,sharding,冗余
来源: https://www.cnblogs.com/anhaogoon/p/15153641.html