分库分表简介
常规未进行分库分表的情况,随着时间的推移,表中的数据越来越多,表越来越庞大,那随之而来的影响就是:
- 一台服务器的资源有限
- 数据库中的数据量不可控
- 库中的表会越来越多
- 表中的数据量也会越来越大
- 增删改查的开销会越来越大
如何优化
分区表
根据所使用的不同分区规则可以分成几大分区类型:
- Range分区
- List分区
- Hash分区
- Key分区
- 复合分区
垂直切分
一个数据库由很多表的构成,每个表对应着不同的业务,垂直切分是指按照业务将表进行分类,分布到不同的数据库上面,这样也就将数据或者说压力分担到不同的库上面。
垂直划分数据库是根据业务进行划分,例如将shop库中涉及商品、订单、用户的表分别划分出成一个库,通过降低单库(表)的大小来提高性能,但这种方式并没有解决高数据量带来的性能损耗。同样的,分表的情况就是将一个大表根据业务功能拆分成一个个子表,例如用户表可根据业务分成基本信息表和详细信息表等。
缺点:
- 不解决数据量大带来的性能损耗,读写压力依旧很大
- 不同的业务无法跨库关联(join),只能通过业务来关联
水平切分
相对于垂直拆分,水平拆分不是将表做分类,而是按照某个字段的某种规则来分散到多个库之中,每个表中包含一部分数据。简单来说,我们可以将数据的水平切分理解为是按照数据行的切分,就是将表中的某些行切分到一个数据库,而另外的某些行又切分到其他的数据库中。
水平划分是根据一定规则,例如时间或id序列值等进行数据的拆分。比如根据年份来拆分不同的数据库。每个数据库结构一致,但是数据得以拆分,从而提升性能。又比如根据用户id的值,根据规则分成若干个表。每个表结构一致,(这点与垂直分库分表相反)。
优点:
- 单库(表)的数据量得以减少,提高性能
- 提高了系统的稳定性和负载能力
- 切分出的表结构相同,程序改动较少
垂直切分对比水平切分
垂直切分 | 水平切分 | |
---|---|---|
特点 | 规则简单,实施方便 业务之间的耦合度非常低,相互影响很小 根据不同的表来进行拆分,对应用程序的影响也更小 | 将同一个表中的不同数据拆分到不同的数据库 对于应用程序来说,表的命名比垂直拆分复杂 后期的数据维护也会复杂 |
优点 | 系统之间整合或扩展容易 拆分后业务清晰,拆分规则明确 数据维护简单 | 拆分规则抽象好,Join操作基本可以做 不存在单库大数据,高并发的性能瓶颈 应用端改造较少 提高了系统的稳定性跟负载能力 |
缺点 | 部分业务表无法Join,只能通过接口方式解决,提高了系统复杂度 受每种业务不同的限制存在单库性能瓶颈,不易数据扩展跟性能提高 事务处理复杂 | 拆分规则难以抽象 分片事务一致性难以解决 数据多次扩展难度跟维护量极大 跨库Join性能较差 |
分库分表组件
为什么使用分库分表
分库分表目的:分散单台设备负载
随着时间和业务的发展,数据库中的数据量增长是不可控的,库和表中的数据会越来越大,随之带来的是更高的磁盘、IO、系统开销,甚至性能上的瓶颈,而一台服务的资源终究是有限的,因此需要对数据库和表进行拆分,从而更好的提供数据服务。
分库分表组件
组件分类
- 类似Sharding-JDBC 及 TDDL的应用集成型
- 类似Mycat 在中间层进行分库分表的中间代理型
应用集成型优点:
- 轻量级,仅仅是JDBC增强,不包括 HA、事务以及数据库元数据管理
- 开发的工作量较小,无需关注NIO,各个数据库协议等
- 运维无需改动,无需关注中间件本身的 HA
- 性能高,JDBC 直连数据库,无需二次转发
- 可支持各种基于 JDBC 协议的数据库,如:MySQL,Oralce,SQLServer
中间代理型优点:
- 可以负责更多的内容,将数据迁移,分布式事务等纳入 Proxy 的范畴
- 更有效的管理数据库的连接
- 整合大数据思路,将 OLTP 和 OLAP 分离处理
开源组件
Atlas
Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上,对其进行了优化,增加了一些新的功能特性。Atlas是一个位于应用程序与MySQL之间,它实现了MySQL的客户端与服务端协议,作为服务端与应用程序通讯,同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节,同时为了降低MySQL负担,它还维护了连接池。
Cobar
阿里巴巴(B2B)部门开发的一种关系型数据的分布式处理系统,它可以在分布式的环境下看上去像传统数据库一样为您提供海量数据服务。
Mycat
开源的分布式数据库系统,实现了MySQL协议的服务器。前端用户可以把它看作是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信。
Oceanus
58同城数据库中间件。
ShardingSphere
当当应用框架ddframe中,从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架,实现透明化数据库分库分表访问。
TDDL
淘宝根据自己的业务特点开发了TDDL(Taobao Distributed Data Layer 外号:头都大了)框架,主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制,它是一个基于集中式配置的 jdbc datasource实现,具有主备,读写分离,动态数据库配置等功能。
vitess
YouTube数据库基础结构的核心组件,并且已经发展到包含数万个MySQL节点。
开源组件对比
对比项 | Cobar | TDDL | ShardingSphere-JDBC | Mycat |
---|---|---|---|---|
分库支持 | Yes | Yes | Yes | Yes |
分表支持 | No | Yes | Yes | Yes |
框架类型 | Proxy | 应用集成 | 应用集成 | Proxy |
中间层 | Yes | No | No | Yes |
ORM支持 | 任意 | 多种 | 多种 | 多种 |
数据库支持 | 仅MySQL | 多种 | 多种 | 多种 |
外部依赖 | No | Diamond | No | No |
社区活跃度 | 停滞 | 停滞 | 活跃 | 较活跃 |
文档丰富 | Yes | N/A | Yes | Yes |
持续更新 | No | N/A | Yes | Yes |
ShardingSphere要点
数据分片难点
虽然数据分片解决了性能、可用性以及单点备份恢复等问题,但分布式的架构在获得了收益的同时,也引入了新的问题.
分布式全局唯一ID
在很多中小项目中,往往直接使用数据库自增特性来生成主键ID。而在分库分表的环境中,数据分布在不同的分片上,再借助数据库自增长特性直接生成会造成不同分片上的数据表主键会重复。
数据库自增
- UUID/GUID(一般应用程序和数据库均支持)
- Redis Increment
- MongoDB ObjectID(类似UUID的方式)
- Zookeeper分布式锁
- Twitter的Snowflake(又名“雪花算法”)
- Ticket Server(数据库生成方式,Flickr采用的就是这种方式)
分片规则和策略
- 分片的规则和策略,在某些时候直接决定了数据访问的效率问题
- 分片规则决定了需要知道数据需要从哪个具体的数据库的分表中获取
- 分片规则决定了能够正确的运行在单节点数据库中的SQL,在分片之后的数据库中并不一定能够正确运行。因为分片可能导致名称的修改,或者分页、排序、聚合分组等操作的不正确处理
跨分片技术问题
分片技术还会遇到下面几个难题:
- 跨分片的排序分页
- 跨分片的函数处理
- 跨分片Join
跨分片事务问题
跨库事务也是分布式的数据库集群要面对的棘手事情。跨分片事务也是分布式事务,想要了解分布式事务,就需要了解“XA接口”和“两阶段提交”,以及Base事务。
ShardingSphere是什么
Apache ShardingSphere(Incubator) 是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这3款相互独立,却又能够混合部署配合使用的产品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
ShardingSphere-JDBC
ShardingSphere-JDBC是ShardingSphere的第一个产品,也是ShardingSphere的前身。 它定位为轻量级Java框架,在Java的JDBC层提供的额外服务。它使用客户端直连数据库,以jar包形式提供服务,无需额外部署和依赖,可理解为增强版的JDBC驱动,完全兼容JDBC和各种ORM框架。
ShardingSphere-Proxy
透明化的数据库代理端,提供封装后的数据库二进制协议的服务端版本,用于完成对异构语言的支持。目前支持MySQL/PostgreSQL版本,使用它可以任何兼容MySQL/PostgreSQL协议的访问客户端
ShardingSphere-UI
ShardingSphere-UI是ShardingSphere的一个简单而有用的web管理控制台。它用于帮助用户更简单的使用ShardingSphere的相关功能,目前提供注册中心管理、动态配置管理、数据库编排等功能
ShardingSphere-Scaling
可以提供给用户通用的ShardingSphere数据接入,迁移,及弹性伸缩解决方案
ShardingSphere基本概念
逻辑表
水平拆分的数据库(表)的相同逻辑和数据结构表的总称
真实表
在分片的数据库中真实存在的物理表
绑定表
指分片规则一致的主表和子表
广播表
所有的分片中都存在的表,表结构和表中的数据在每个数据库中均完全一致。适用于数据量不大且需要与海量数据的表进行关联查询的场景,如:字典表
数据节点
数据分片的最小单元