(2)性能提升
- 解决了单库数据量大,高并发的瓶颈
- 提高了系统的稳定性和可用性
(3)何时使用
当一个应用难以再进行垂直切分,或垂直切分后数据量行数巨大,存在单库读写存储的性能瓶颈,这时候就可以考虑使用水平分库了。
(4)使用弊端
但水平分库的弊端也很明显,需要确定你所需要的数据在哪一个库中,因此大大提高了系统的复杂度。
5、小总结
- 垂直分表:热门数据、冷门数据分开存储,大字段放在冷门数据表中。
- 垂直分库:按业务拆分,放到不同的库中,这些库分别部署在不同的服务器,解决单一服务器性能的瓶颈,同时提升整体架构的业务清晰度。
- 水平分表:解决单一表数据量过大的问题
- 水平分库:把一个表的数据分别分到不同的库中,这些库分别部署在不同的服务器,解决单一服务器数据量过大的问题
三、分库分表带来的问题
1、学习成本问题
大多数初级开发者都不会分库分表,如果使用不得到,还不如直接使用单一数据库了。
2、事务问题
(1)解决方案1:使用分布式事务
① 优点
由数据库管理,简单有效。
② 缺点
性能代价高,特别是shard越来越多时。
(2)解决方案2:由应用程序和数据库共同控制
① 原理
将一个分布式的大事务分解成单个数据库的小事务,并通过应用程序来控制各个小事务。
② 优点
性能更佳
③ 缺点
需要应用程序在事务控制上做灵活设计,如果使用Spring的事务管理机制,改动起来面临一定困难。
3、跨节点join问题
解决方式是分两次查询。
4、跨节点的count、order by、group by以及聚合函数问题
与join的解决方案类似,分别在各个节点得到结果然后再合并。和join的差别在于,各节点的查询可以并行执行,因此很多时候它的速度会比单一大表快很多。但是,如果结果集很大,对应用程序内存的消耗也是一个问题。
5、数据迁移、容量规划、扩容问题
6、主键ID问题
因为分表的原因,主键自增策略wufa实现。
解决方案1:UUID
使用UUID作为主键是最简单的方案,但是缺点是UUID非常的长,会占用大量存储空间,在进行连表查询的问题上也存在性能问题。
解决方案2:多维护一个Sequence表
建立一个新表,字段包含table_name和next_id。
看见表结构之后,秒懂吧?
大概意思就是记录分表后的每张表的下一个ID是多少,缺点很明显,就是每次插入数据都要访问这张表获取插入数据的id,该表很容易称为系统性能的瓶颈,同时它也存在单点问题,一旦该表数据库失效,整个系统都无法正常工作。此时可能通过主备机同步机制,解决单点问题。
解决方案3:Twitter的分布式自增ID算法Snowflake
snowflake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用,接下来的41位为毫秒级时间(41位的长度可以使用69年),然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点) ,最后12位是毫秒内的计数(12位的计数顺序号支持每个节点每毫秒产生4096个ID序号)
一共加起来刚好64位,为一个Long型。(转换成字符串后长度最多19)
snowflake生成的ID整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由datacenter和workerId作区分),并且效率较高。经测试snowflake每秒能够产生26万个ID。
7、跨分片的排序分页
在不同的分片节点中将数据进行排序,并将结果机型汇总,再次排序。
四、分库数量
分库数量首先和单库处理能力息息相关,比如MySQL单库超过5000万记录,Oracle单库超过1亿条记录,数据库压力就很大了。
在满足上述前提下,如果分库数量少,达不到分散存储和减轻DB性能压力的目的;如果分库数量多,跨库访问也是个问题,如果是并发模式,要消耗宝贵的线程资源,如果是串行,偶数,执行时间急剧增加。
分库数量还会直接影响硬件的投入,所以要分多少个库,要进行综合评估,一般初次分库建议分为4-8个库。
五、分库分表第三方解决方案 – Apache ShardingSphere
Apache ShardingSphere是一套来源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这三款相互独立,却又能够混合部署配合使用的产品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。
ShardingShpere定位为关系型数据库中间件,旨在充分合理地在分布式场景下利用关系型数据库的计算和存储能力,而并非实现一个全新的关系型数据库。它通过关注不变,进而抓住事物本质。
Apache ShardingSphere 5.x版本开始致力于可插拔式架构,项目的功能组件能够灵活的以可插拔的方式进行扩展。目前,数据分片、读写分离、数据加密、影子库压测等功能,以及MySQL、postgresql、SQLServer、Oracle等SQL与协议的支持,均通过插件的方式织入项目。开发者能够像使用积木一样定制数据自己的独特系统。Apache ShardingSphere 目前已提供数十个SPI作为系统的扩展点,仍在不断增加中。
Apache ShardingSphere 产品定位为Database Plus,旨在构建多模数据库上层的标准和生态。它关注如何充分合理地利用数据库的计算和存储能力,而非实现一个全新的数据库。Apache ShardingSphere站在数据库的上层视角,关注它们之间的协作多于数据库本身。
六、Apache ShardingSphere的三个核心概念
1、连接
通过对数据库协议、SQL方言以及数据库存储的灵活适配,快速的连接应用与多模式的异构数据库。
2、增量
获取数据库的访问流量,并提供流量重定向(数据分片、读写分离、影子库)、流量变形