前言:最近公司要讨论分库分表,正好一起参加了培训。一般mysql单表数据库容量达到一定的极限,性能会急剧下降,之前工作的时候已经大佬们高喊几次了分库分表,但是最终没能实现或者落地的方案不佳。在这里一篇很好的文章指出了当前开源的分库分表的框架的不足,并介绍了使用TiDb作为新的分布式数据库的各种优点传送门。
目前的常用的分库分表概述
一种是中间件代理,例如mycat和sharding-proxy,对于应用是比较透明的,支持的语言也多;第二种是侵入式,也就是数据库直连,例如sharding-jdbc。sharding-proxy和sharding-jdbc都已经整合到sharding-Sphere里,中文文档可以点击这里
sharding-sphere作为分库分表的实现短板。
sharding-sphere包含三个项目:sharding-jdbc、sharding-proxy和Sharding-Sidecar。如果有兴趣大家可一查看demo,里面包含各种应用场景。我仅仅以后台人员的角度来看局限性。
- shrdingkey粘连 例如sharding-jdbc里面需要指出分库键和分表键,如果你的业务很复杂,意味着你要建立很多shrdingkey;即使你认为这没有啥,最要命的是你增删改查都必须带上这个shrdingkey才能路由到你要去的那张表,这就好比回娘家,还真得左右一只鸡右手一只鸭,不然娘家不认你。
- 数据冷热均衡、高可用复杂度很高 一般分表分库数据,热点数据我就需要设计非常复杂的算法,提前规划好几张库几张表;例如购物记录表,你设计2个库,每个库水平切4张表,再为这些表设计一套均衡的数据分流,但是人员表你最多一个库两张表,再为这冲业务维度设计一套数据均衡。最后,你要为这些来个主从、读写分离保证高可用,...同志,你确定你能行吗?牛逼的话希望可以给口饭吃。
- 扩容非常困难 如果你已经提前规划好了几个库几个表,并且为每个业务表都设计好一套牛逼的算法,保证一百年性能不出问题,并且也给了我一口汤喝,百年之后老板的儿子要扩容。运维人员需要根据你的算法,再来扩容,4库变成8个库,每个库再来切一下,再来弄个高可用,再来迁移数据。运维黑人问号脸:我去你***%……%%35433454
- sql不支持关联查询、分布式事务复杂度高、一致性差。不过这些都是分布式都面临的问题,已阅。
TIDB原理简介
- TiDB Server :解析SQL 请求,最后通过 PD 找到存储计算所需数据的 TiKV (键值对)然后返回。TiDB 是无状态的,也就是无脑传话机,本身不存储任何数据。
- PD Server: TiKV存储集群的元信息;对 TiKV 集群进行调度和负载均衡;分配全局唯一且递增的事务 ID。他是集群,集群是要选举的,必须是奇数个哦! PD Server是指挥官,负责调度。
- TiKV Server: 负责存储数据,基本单元就是Region,也就是一个K-V。多个Region组成一个TiKV 节点,多个节点组成一个GROUP。
TiDB作为分布式数据库的优点
- 对于现有得应用非常透明化。Tidb的原理是解析sql语句,进入自己的key-value存储单元获取数据,使得现有得应用可以平滑过渡,挂的是关系型数据库的皮,做的是NOSQL数据库的事,我们叫他不是个东...new SQL。他借用了mysql引擎,所以你直接在NAVICAT上就可以直接界面化操作啦。
- 可以非常快捷的伸缩,实现冷热数据的均衡。例如使用sharding-jdbc,要实现热点数据的分布存储,抛开复杂的分库分表算法不说,每次扩容对于运维人员非常繁琐。但是TIDB就不存在啦,只要扩展TiDB Server 节点增加计算能力,扩展TIKV节点增加存储能力就可以。这是一场战争,号角吹响,补兵不行补兵,传话的不够加传话的,指挥官挂了选新的。男人不能说自己不xing.
- 支持分布式事务,数据强一致性,百亿级存储。根据官网吹牛(shihua)逼(shishuo)说,金融级高可用。
TiDB作为分布式数据库的缺点
- 存储过程、触发器、事件、外键约束不支持,但是这个是人家谦(chenqie)虚的说法(zuobudao),分布式数据库谁还用这些鸡肋玩意儿,特别是触发器。
-
硬件要求高,不多说的,反正就是高,你想想人家这么快肯定IO轻松不了,人家大神都说了,最好全换成SSD。
TiDB的安装
作为后台人员,我们就是用最快捷的docker快速安装搭建TIDB,Tidb官网已经给出了非常完整的文档,这里不再详述。这也是我第一次在简书写,毕竟支持MARKDOWN还是很爽的,工作繁忙,下一章我会示例一下docker安装TIDB快速整合后台应用的DEMO。
参看文章
- docker-compose安装TIDB:官方安装
- tiDB SQL优化:TiDB 的正确使用姿势
- 十问 TiDB