分库分表的技术演进

现在人工智能非常火爆,很多朋友都想学,但是一般的教程都是为博硕生准备的,太难看懂了。最近发现了一个非常适合小白入门的教程,不仅通俗易懂而且还很风趣幽默。所以忍不住分享一下给大家

 

每个优秀的程序员和架构师都应该掌握分库分表,这是我的观点。

移动互联网时代,海量的用户每天产生海量的数量,比如:

  • 用户表

  • 订单表

  • 交易流水表

以支付宝用户为例,8亿;微信用户更是10亿。订单表更夸张,比如美团外卖,每天都是几千万的订单。淘宝的历史订单总量应该百亿,甚至千亿级别,这些海量数据远不是一张表能Hold住的。事实上MySQL单表可以存储10亿级数据,只是这时候性能比较差,业界公认MySQL单表容量在1KW以下是最佳状态,因为这时它的BTREE索引树高在3~5之间。

既然一张表无法搞定,那么就想办法将数据放到多个地方,目前比较普遍的方案有3个:

  1. 分区;

  2. 分库分表;

  3. NoSQL/NewSQL;

说明:只分库,或者只分表,或者分库分表融合方案都统一认为是分库分表方案,因为分库,或者分表只是一种特殊的分库分表而已。NoSQL比较具有代表性的是MongoDB,es。NewSQL比较具有代表性的是TiDB。

Why Not NoSQL/NewSQL?

首先,为什么不选择第三种方案NoSQL/NewSQL,我认为主要是RDBMS有以下几个优点:
- RDBMS生态完善;
- RDBMS绝对稳定;
- RDBMS的事务特性;

NoSQL/NewSQL作为新生儿,在我们把可靠性当做首要考察对象时,它是无法与RDBMS相提并论的。RDBMS发展几十年,只要有软件的地方,它都是核心存储的首选。

目前绝大部分公司的核心数据都是:以RDBMS存储为主,NoSQL/NewSQL存储为辅!互联网公司又以MySQL为主,国企&银行等不差钱的企业以Oracle/DB2为主!NoSQL/NewSQL宣传的无论多牛逼,就现在各大公司对它的定位,都是RDBMS的补充,而不是取而代之!

Why Not 分区?

我们再看分区表方案。了解这个方案之前,先了解它的原理:

分区表是由多个相关的底层表实现,这些底层表也是由句柄对象表示,所以我们也可以直接访问各个分区,存储引擎管理分区的各个底层表和管理普通表一样(所有的底层表都必须使用相同的存储引擎),分区表的索引只是在各个底层表上各自加上一个相同的索引,从存储引擎的角度来看,底层表和一个普通表没有任何不同,存储引擎也无须知道这是一个普通表还是一个分区表的一部分。

事实上,这个方案也不错,它对用户屏蔽了sharding的细节,即使查询条件没有sharding column,它也能正常工作(只是这时候性能一般)。不过它的缺点很明显:很多的资源都受到单机的限制,例如连接数,网络吞吐等!虽然每个分区可以独立存储,但是分区表的总入口还是一个MySQL示例。从而导致它的并发能力非常一般,远远达不到互联网高并发的要求!

至于网上提到的一些其他缺点比如:无法使用外键,不支持全文索引。我认为这都不算缺点,21世纪的项目如果还是使用外键和数据库的全文索引,我都懒得吐槽了!

所以,如果使用分区表,你的业务应该具备如下两个特点:

  1. 数据不是海量(分区数有限,存储能力就有限);

  2. 并发能力要求不高;

Why 分库分表?

最后要介绍的就是目前互联网行业处理海量数据的通用方法:分库分表

虽然大家都是采用分库分表方案来处理海量核心数据,但是还没有一个一统江湖的中间件,笔者这里列举一些有一定知名度的分库分表中间件:

  • 阿里的TDDL,DRDS和cobar,

  • 开源社区的sharding-jdbc(3.x已经更名为sharding-sphere);

  • 民间组织的MyCAT;

  • 360的Atlas;

  • 美团的zebra;

其他比如网易,58,京东等公司都有自研的中间件。总之各自为战,也可以说是百花齐放。

但是这么多的分库分表中间件全部可以归结为两大类型:

  • CLIENT模式

  • PROXY模式

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

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

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

 

posted @ 2019-03-27 09:39 汪强胜 Views(...) Comments(...) Edit 收藏