ppt免费模板大全网站,免费wordpress中文博客主题,知名网站都是什么系统做的,4399小游戏网页版在线1.概述
1.1.分库分表是什么
小明是一家初创电商平台的开发人员#xff0c;他负责卖家模块的功能开发#xff0c;其中涉及了店铺、商品的相关业务#xff0c;设计如下 数据库#xff1a; 通过以下SQL能够获取到商品相关的店铺信息、地理区域信息#xff1a;
SELECT p.*…1.概述
1.1.分库分表是什么
小明是一家初创电商平台的开发人员他负责卖家模块的功能开发其中涉及了店铺、商品的相关业务设计如下 数据库 通过以下SQL能够获取到商品相关的店铺信息、地理区域信息
SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]
FROM [商品信息] p
LEFT JOIN [地理区域] r ON p.[产地] r.[地理区域编码]
LEFT JOIN [店铺信息] s ON p.id s.[所属店铺]
WHERE p.id ?
形成类似以下列表展示
随着公司业务快速发展数据库中的数据量猛增访问性能也变慢了优化迫在眉睫。分析一下问题出现在哪儿呢 关系型数据库本身比较容易成为系统瓶颈单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后由于查询维度较多即使添加从库、优化索引做很多操作时性能仍下降严重。
方案1 通过提升服务器硬件能力来提高数据处理能力比如增加存储容量 、CPU等这种方案成本很高并且如果瓶颈在MySQL本身那么提高硬件也是有很的。
方案2 把数据分散在不同的数据库中使得单一数据库的数据量变小来缓解单一数据库的性能问题从而达到提升数据库性能的目的如下图将电商数据库拆分为若干独立的数据库并且对于大表也拆分为若干小表通过这种数据库拆分的方法来解决数据库的性能问题。 分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题将原来独立的数据库拆分成若干数据库组成将数据大表拆分成若干数据表组成使得单一数据库、单一数据表的数据量变小从而达到提升数据库性能的目的。
1.2.分库分表的方式
分库分表包括分库和分表两个部分在生产中通常包括垂直分库、水平分库、垂直分表、水平分表四种方式。
1.2.1.垂直分表
下边通过一个商品查询的案例讲解垂直分表 通常在商品列表中是不显示商品详情信息的如下图 用户在浏览商品列表时只有对某商品感兴趣时才会查看该商品的详细描述。因此商品信息中商品描述字段访问频次较低且该字段存储占用空间较大访问单个数据IO时间较长商品信息中商品名称、商品图片、商品价格等其他字段数据访问频次较高。
由于这两种数据的特性不一样因此他考虑将商品信息表拆分如下
将访问频次低的商品描述信息单独存放在一张表中访问频次较高的商品基本信息单独放在一张表中。
商品列表可采用以下sql
SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]
FROM [商品信息] p
LEFT JOIN [地理区域] r ON p.[产地] r.[地理区域编码]
LEFT JOIN [店铺信息] s ON p.id s.[所属店铺]
WHERE...ORDER BY...LIMIT...
需要获取商品描述时再通过以下sql获取
SELECT *
FROM [商品描述]
WHERE [商品ID] ?
小明进行的这一步优化就叫垂直分表。 垂直分表定义将一个表按照字段分成多表每个表存储其中一部分字段。
它带来的提升是 1.为了避免IO争抢并减少锁表的几率查看详情的用户与商品信息浏览互不影响 2.充分发挥热门数据的操作效率商品信息的操作的高效率不会被商品描述的低效率所拖累。
一般来说某业务实体中的各个数据项的访问频次是不一样的部分数据项可能是占用存储空间比较大的BLOB或 是TEXT。例如上例中的商品描述。所以当表数据量很大时可以将表按字段切开将热门字段、冷门字段分开放 置在不同库中这些库可以放在不同的存储设备上避免IO争抢。垂直切分带来的性能提升主要集中在热门数据的 操作效率上而且磁盘争用情况减少。
通常我们按以下原则进行垂直拆分:
把不常用的字段单独放在一张表;把textblob等大字段拆分出来放在附表中;经常组合查询的列放在一张表中;
1.2.2.垂直分库
通过垂直分表性能得到了一定程度的提升但是还没有达到要求并且磁盘空间也快不够了因为数据还是始终限制在一台服务器库内垂直分表只解决了单一表数据量过大的问题但没有将表分布到不同的服务器上因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。 经过思考他把原有的SELLER_DB(卖家库)分为了PRODUCT_DB(商品库)和STORE_DB(店铺库)并把这两个库分散到不同服务器如下图 由于商品信息与商品描述业务耦合度较高因此一起被存放在PRODUCT_DB(商品库)而店铺信息相对独立因此单独被存放在STORE_DB(店铺库)。
小明进行的这一步优化就叫垂直分库。
垂直分库是指按照业务将表进行分类分布到不同的数据库上面每个库可以放在不同的服务器上它的核心理念是专库专用。
它带来的提升是
解决业务层面的耦合业务清晰能对不同业务的数据进行分级管理、维护、监控、扩展等高并发场景下垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈
垂直分库通过将表按业务分类然后分布在不同数据库并且可以将这些数据库部署在不同服务器上从而达到多个服务器共同分摊压力的效果但是依然没有解决单表数据量过大的问题。
1.2.3.水平分库
经过垂直分库后数据库性能问题得到一定程度的解决但是随着业务量的增长PRODUCT_DB(商品库)单库存储数据已经超出预估。粗略估计目前有8w店铺每个店铺平均150个不同规格的商品再算上增长那商品数量得往1500w上预估并且PRODUCT_DB(商品库)属于访问非常频繁的资源单台服务器已经无法支撑。此时该如何优化
再次分库但是从业务角度分析目前情况已经无法再次垂直分库。 尝试水平分库将店铺ID为单数的和店铺ID为双数的商品信息分别放在两个库中。 也就是说要操作某条数据先分析这条数据所属的店铺ID。如果店铺ID为双数将此操作映射至RRODUCT_DB1(商品库1)如果店铺ID为单数将操作映射至RRODUCT_DB2(商品库2)。此操作要访问数据库名称的表达式为RRODUCT_DB[店铺ID%2 1] 。
小明进行的这一步优化就叫水平分库。
水平分库是把同一个表的数据按一定规则拆到不同的数据库中每个库可以放在不同的服务器上。
它带来的提升是
解决了单库大数据高并发的性能瓶颈。提高了系统的稳定性及可用性。
当一个应用难以再细粒度的垂直切分或切分后数据量行数巨大存在单库读写、存储性能瓶颈这时候就需要进 行水平分库了经过水平切分的优化往往能解决单库存储量及性能瓶颈。但由于同一个表被分配在不同的数据 库需要额外进行数据操作的路由工作因此大大提升了系统复杂度。
1.2.4.水平分表
按照水平分库的思路对他把PRODUCT_DB_X(商品库)内的表也可以进行水平拆分其目的也是为解决单表数据量大 的问题如下图 与水平分库的思路类似不过这次操作的目标是表商品信息及商品描述被分成了两套表。如果商品ID为双数将此操作映射至商品信息1表如果商品ID为单数将操作映射至商品信息2表。此操作要访问表名称的表达式为商品信息**[商品ID%2 1] 。**
小明进行的这一步优化就叫水平分表。
水平分表是在同一个数据库内把同一个表的数据按一定规则拆到多个表中。
它带来的提升是
优化单一表数据量过大而产生的性能问题避免IO争抢并减少锁表的几率
库内的水平分表解决了单一表数据量过大的问题分出来的小表中只包含一部分数据从而使得单个表的数据量变小提高检索性能。
1.2.5 小结
本章介绍了分库分表的各种方式它们分别是垂直分表、垂直分库、水平分库和水平分表
垂直分表可以把一个宽表的字段按访问频次、是否是大字段的原则拆分为多个表这样既能使业务清晰还能提升部分性能。拆分后尽量从业务角度避免联查否则性能方面将得不偿失。
垂直分库可以把多个表按业务耦合松紧归类分别存放在不同的库这些库可以分布在不同服务器从而使访问压力被多服务器负载大大提升性能同时能提高整体架构的业务清晰度不同的业务库可根据自身情况定制优化方案。但是它需要解决跨库带来的所有复杂问题。
水平分库可以把一个表的数据(按数据行)分到多个不同的库每个库只有这个表的部分数据这些库可以分布在不同服务器从而使访问压力被多服务器负载大大提升性能。它不仅需要解决跨库带来的所有复杂问题还要解决数据路由的问题(数据路由问题后边介绍)。
水平分表可以把一个表的数据(按数据行)分到多个同一个数据库的多张表中每个表只有这个表的部分数据这样做能小幅提升性能它仅仅作为水平分库的一个补充优化。
一般来说在系统设计阶段就应该根据业务耦合松紧来确定垂直分库垂直分表方案在数据量及访问压力不是特别大的情况首先考虑缓存、读写分离、索引技术等方案。若数据量极大且持续增长再考虑水平分库水平分表方案。
1.3.分库分表带来的问题
分库分表能有效的缓解了单机和单库带来的性能瓶颈和压力突破网络IO、硬件资源、连接数的瓶颈同时也带来了一些问题。
1.3.1.事务一致性问题
由于分库分表把数据分布在不同库甚至不同服务器不可避免会带来分布式事务问题。
1.3.2.跨节点关联查询
在没有分库前我们检索商品时可以通过以下SQL对店铺信息进行关联查询
SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]
FROM [商品信息] p
LEFT JOIN [地理区域] r ON p.[产地] r.[地理区域编码]
LEFT JOIN [店铺信息] s ON p.id s.[所属店铺]
WHERE...ORDER BY...LIMIT...
但垂直分库后[商品信息]和[店铺信息]不在一个数据库甚至不在一台服务器无法进行关联查询。
可将原关联查询分为两次查询第一次查询的结果集中找出关联数据id然后根据id发起第二次请求得到关联数据最后将获得到的数据进行拼装。
1.3.3.跨节点分页、排序函数
跨节点多库进行查询时limit分页、order by排序等问题就变得比较复杂了。需要先在不同的分片节点中将数据进行排序并返回然后将不同分片返回的结果集进行汇总和再次排序。
如进行水平分库后的商品库按ID倒序排序分页取第一页 以上流程是取第一页的数据性能影响不大但由于商品信息的分布在各数据库的数据可能是随机的如果是取第N页需要将所有节点前N页数据都取出来合并再进行整体的排序操作效率可想而知。所以请求页数越大系统的性能也会越差。
在使用Max、Min、Sum、Count之类的函数进行计算的时候与排序分页同理也需要先在每个分片上执行相应的函数然后将各个分片的结果集进行汇总和再次计算最终将结果返回。
1.3.4.主键避重
在分库分表环境中由于表中数据同时存在不同数据库中主键值平时使用的自增长将无用武之地某个分区数据库生成的ID无法保证全局唯一。因此需要单独设计全局主键以避免跨库主键重复问题。
1.3.5.公共表
实际的应用场景中参数表、数据字典表等都是数据量较小变动少而且属于高频联合查询的依赖表。例子中地理区域表也属于此类型。
可以将这类表在每个数据库都保存一份所有对公共表的更新操作都同时发送到所有分库执行。
由于分库分表之后数据被分散在不同的数据库、服务器。因此对数据的操作也就无法通过常规方式完成并且它还带来了一系列的问题。好在这些问题不是所有都需要我们在应用层面上解决市面上有很多中间件可供我们选择其中Sharding-JDBC使用流行度较高我们来了解一下它。
1.4 Sharding-JDBC介绍
1.4.1 Sharding-JDBC介绍
Sharding-JDBC是当当网研发的开源分布式数据库中间件从 3.0 开始Sharding-JDBC被包含在 Sharding-Sphere中之后该项目进入进入Apache孵化器4.0版本之后的版本为Apache版本。
ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈它由Sharding-JDBC、ShardingProxySharding-Sidecar计划中这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能可适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
官方地址https://shardingsphere.apache.org/document/current/cn/overview/
咱们目前只需关注Sharding-JDBC它定位为轻量级Java框架在Java的JDBC层提供的额外服务。 它使用客户端直连数据库以jar包形式提供服务无需额外部署和依赖可理解为增强版的JDBC驱动完全兼容JDBC和各种ORM框架。
Sharding-JDBC的核心功能为数据分片和读写分离通过Sharding-JDBC应用可以透明的使用jdbc访问已经分库分表、读写分离的多个数据源而不用关心数据源的数量以及数据如何分布。
适用于任何基于Java的ORM框架如 Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。基于任何第三方的数据库连接池如DBCP, C3P0, BoneCP, Druid, HikariCP等。支持任意实现JDBC规范的数据库。目前支持MySQLOracleSQLServer和PostgreSQL。 上图展示了Sharding-Jdbc的工作方式使用Sharding-Jdbc前需要人工对数据库进行分库分表在应用程序中加入Sharding-Jdbc的Jar包应用程序通过Sharding-Jdbc操作分库分表后的数据库和数据表由于Sharding-Jdbc是对Jdbc驱动的增强使用Sharding-Jdbc就像使用Jdbc驱动一样在应用程序中是无需指定具体要操作的分库和分表的。
1.4.2 与jdbc性能对比
性能损耗测试服务器资源充足、并发数相同比较JDBC和Sharding-JDBC性能损耗Sharding-JDBC相对JDBC损耗不超过7%。 性能对比测试服务器资源使用到极限相同的场景JDBC与Sharding-JDBC的吞吐量相当。性能对比测试服务器资源使用到极限Sharding-JDBC采用分库分表后Sharding-JDBC吞吐量较JDBC不分表有接近2倍的提升。 更多Java学习指南以及最新项目场景题需要的宝子 Java学习包传送门
