抱歉,您的浏览器无法访问本站
本页面需要浏览器支持(启用)JavaScript
了解详情 >

概述

什么是分库分表

随着业务的发展,数据库中的数据量也将猛增,访问的性能也会变慢,优化数据库也成了不可或缺的一环。当单表的数据容量达到一千万或者100G之后,由于查询维度较多,即使添加从库、优化索引性能仍下降严重。当然你也可以去升级服务器的配置,比如存储容量、cpu等等,只不过这种方式成本较高,而且这类的问题瓶颈与MySQL本身相关,提升有限。这就可以考虑使用分库分表了,把数据分散到不同的数据库中,以减少单一数据库的数据量,从而缓解数据库的性能问题。

Sharding-JDBC

适用

  • 适用于任何基于JDBC的ORM框架,如:JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC
  • 支持任何第三方的数据库连接池,如:DBCP、C3P0、BoneCP、Druid、Hikaricp等
  • 支持任意实现JDBC规范的数据库。目前支持MySQL、Oracle、SQL server、PostgreSQL以及任何遵循SQL92标准的数据库。

功能列表

  • 数据分片
    • 分库 & 分表
    • 读写分离
    • 分片策列定制化
    • 无中心化分布式主键
  • 分布式事务
    • 标准化事务接口
    • XA强一事务
    • 柔性事务
  • 数据库治理
    • 配置动态化
    • 编排 & 治理
    • 数据脱敏
    • 可视化链路追踪

概念 & 功能

数据分片

背景

  • 性能方面

    从性能方面来说,由于关系型数据库大多采用B+树类型的索引,在数据量超过阈值的情况下,索引深度的增加也将使得磁盘访问的I/O次数增加,进而导致查询性能的下降;同时高并发访问请求也使得集中式数据库称为系统的最大瓶颈。

  • 可用性方面

    从可用性方面来说,服务化的无无状态型,能够达到较小成本的随意扩容,这必然导致系统的最终压力都落到数据库之上。而单一的数据节点或者简单的主从结构,已经越来越难以承担。数据库的可靠性,已成为整个系统的关键。

  • 运维成本方面

    从运维成本方面考虑,当一个数据库实例中的数据达到阈值以上,对于DBA的运维压力就会增大。数据备份和恢复的时间成本都将虽则数据量的大小而愈发不可收拾。一般来说,单一数据实例的数据阈值在1TB之内,是比较合理的范围。

数据分片指的是按照某个维度将存放的单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可能性的效果。数据分片的有效手段是对关系型数据库进行分库和分表。分库分表均可以有效的避免由于数据量超过可承受阈值而产生的查询瓶颈。

分库还能够用于有效的分散对数据库单点的访问量。

分表虽然无法缓解数据库的压力,但却能够提供尽量将分布式事务转化为本地事务的可能,一旦涉及到跨库的更新操作,分布式事务往往会使问题变得复杂。 使用多主多从的分片方式,可以有效的避免数据单点,从而提升数据架构的可用性。

通过分库和分表进行数据的拆分来使得各个表的数据量保持在阈值一下,以及对流量进行疏导应对高访问量,是应对高并发和海量数据系统的有效手段。数据分片的拆分方式分为垂直分片和水平分片两种。

垂直分片

垂直分片又称纵向拆分,其核心理念是专库专用。

  • 拆分之前,一个数据库由多个数据表构成,每个表对应不同的业务。
  • 拆分之后,按照业务将表进行归类,分布在不同的数据库中,从而将压力分散至不同的数据库。

垂直分片往往需要对架构和设计进行调整,通常来讲,是来不及应对互联网业务需求快速变化的;而且,它也并无法真正的解决单点瓶颈。垂直拆分可以缓解数据量和访问量带来的问题,但无法根治。如果垂直拆分之后,表中的数据量依然超过单点所能承载的阈值,则需要水平分片来进一步处理。

水平分片

水平分片,又称横向分片。相对与垂直分片,它不把数据按业务逻辑分类,而是通过某个(或多个)字段,根据某种规则将数据分散至多个库或表中,每个分片京包含数据的一部分。

例如:根据主键分片,偶数主键的记录放入0库(或表),奇数主键的记录放入1库(或表),如下图所示。

水平分片从理论上突破了单机数据量处理的瓶颈,并且扩展相对自由,是分库分表的标准解决方案。

读写分离

背景

随着业务发展,系统访问量日益剧增,数据库的吞吐量面临巨大瓶颈。对于同一时刻有大量并发读操作和较少写操作的应用系统,将数据库拆分成主库和从库,主库负责处理事务性的增删改操作,从库负责处理查询操作,能够有效的避免有数据更新导致的行锁,使整个系统的查询性能得到极大的改善。

通过一主多从模式,可以将查询请求均匀的分散到多个数据副本,能够进一步提升系统的处理能力。使用多主多从模式,不但能提升系统的吞吐量,还能提高系统可用性,达到在任意一个数据库宕机甚至是磁盘物理损坏的情况下仍然不影响系统的正常运行。

与将数据根据分片键打散至各个数据节点的水平分片不同,读写分离则是根据SQL语义的分析,将读操作和写操作分别路由至主库与从库。

读写分离的数据节点中的数据内容是一致的,而水平分片的每个数据节点的数据内容却并不相同。将水平分片和读写分离联合使用,能够更加有效的提升系统性能。

存在的问题

读写分离虽然可以提升系统的吞吐量和可用性,但同时也带来了数据不一致的问题。 这包括多个主库之间的数据一致性,以及主库与从库之间的数据一致性的问题。 并且,读写分离也带来了与数据分片同样的问题,它同样会使得应用开发和运维人员对数据库的操作和运维变得更加复杂。 下图展现了将分库分表与读写分离一同使用时,应用程序与数据库集群之间的复杂拓扑关系。


参考: ShardingSphere官方手册

评论