用discuz建设企业网站,湛江做网站电话,哪里有网站建设培训班,公司找人做的网站到现在还没出来不急于上手实战 ShardingSphere 框架#xff0c;先来复习下分库分表的基础概念#xff0c;技术名词大多晦涩难懂#xff0c;不要死记硬背理解最重要#xff0c;当你捅破那层窗户纸#xff0c;发现其实它也就那么回事。
什么是分库分表
分库分表是在海量数据下#xff0…不急于上手实战 ShardingSphere 框架先来复习下分库分表的基础概念技术名词大多晦涩难懂不要死记硬背理解最重要当你捅破那层窗户纸发现其实它也就那么回事。
什么是分库分表
分库分表是在海量数据下由于单库、表数据量过大导致数据库性能持续下降的问题演变出的技术方案。
分库分表是由分库和分表这两个独立概念组成的只不过通常分库与分表的操作会同时进行以至于我们习惯性的将它们合在一起叫做分库分表。 通过一定的规则将原本数据量大的数据库拆分成多个单独的数据库将原本数据量大的表拆分成若干个数据表使得单一的库、表性能达到最优的效果响应速度快以此提升整体数据库性能。
为什么分库分表
单机数据库的存储能力、连接数是有限的它自身就很容易会成为系统的瓶颈。当单表数据量在百万以里时我们还可以通过添加从库、优化索引提升性能。
一旦数据量朝着千万以上趋势增长再怎么优化数据库很多操作性能仍下降严重。为了减少数据库的负担提升数据库响应速度缩短查询时间这时候就需要进行分库分表。
为什么需要分库
容量
我们给数据库实例分配的磁盘容量是固定的数据量持续的大幅增长用不了多久单机的容量就会承载不了这么多数据解决办法简单粗暴加容量
连接数
单机的容量可以随意扩展但数据库的连接数却是有限的在高并发场景下多个业务同时对一个数据库操作很容易将连接数耗尽导致 too many connections 报错导致后续数据库无法正常访问。
可以通过 max_connections 查看 MySQL 最大连接数。
show variables like %max_connections%将原本单数据库按不同业务拆分成订单库、物流库、积分库等不仅可以有效分摊数据库读写压力也提高了系统容错性。
为什么需要分表
做过报表业务的同学应该都体验过一条 SQL 执行时间超过几十秒的场景。
导致数据库查询慢的原因有很多SQL 没命中索引、like 扫全表、用了函数计算这些都可以通过优化手段解决可唯独数据量大是 MySQL 无法通过自身优化解决的。慢的根本原因是 InnoDB 存储引擎聚簇索引结构的 Btree 层级变高磁盘 IO 变多查询性能变慢详细原理自行查找一下这里不用过多篇幅说明。
阿里的开发手册中有条建议单表行数超 500 万行或者单表容量超过 2GB就推荐分库分表然而理想和实现总是有差距的阿里这种体量的公司不差钱当然可以这么用实际上很多公司单表数据几千万、亿级别仍然不选择分库分表。 什么时候分库分表 技术群里经常会有小伙伴问到底什么情况下会用分库分表呢 分库分表要解决的是现存海量数据访问的性能瓶颈对持续激增的数据量所做出的架构预见性。
是否分库分表的关键指标是数据量我们以 fire100.top 这个网站的资源表 t_resource 为例系统在运行初始的时候每天只有可怜的几十个资源上传这时使用单库、单表的方式足以支持系统的存储数据量小几乎没什么数据库性能瓶颈。
但某天开始一股神秘的流量进入系统每日产生的资源数据量暴增至十万甚至上百万级别这时资源表数据量到达千万级查询响应变得缓慢数据库的性能瓶颈逐渐显现。
以 MySQL 数据库为例单表的数据量在达到亿条级别通过加索引、SQL 调优等传统优化策略性能提升依旧微乎其微时就可以考虑做分库分表了。
既然 MySQL 存储海量数据时会出现性能瓶颈那么我们是不是可以考虑用其他方案替代它比如高性能的非关系型数据库 MongoDB
可以但要看存储的数据类型
现在互联网上大部分公司的核心数据几乎是存储在关系型数据库MySQL、Oracle 等因为它们有着 NoSQL 如法比拟的稳定性和可靠性产品成熟生态系统完善还有核心的事务功能特性也是其他存储工具不具备的而评论、点赞这些非核心数据还是可以考虑用 MongoDB 的。
如何分库分表 分库分表的核心就是对数据的分片Sharding并相对均匀的路由在不同的库、表中以及分片后对数据的快速定位与检索结果的整合。 分库与分表可以从垂直纵向和 水平横向两种纬度进行拆分。下边我们以经典的订单业务举例看看如何拆分。 垂直拆分
1、垂直分库
垂直分库一般来说按照业务和功能的维度进行拆分将不同业务数据分别放到不同的数据库中核心理念 专库专用。
按业务类型对数据分离剥离为多个数据库像订单、支付、会员、积分相关等表放在对应的订单库、支付库、会员库、积分库。不同业务禁止跨库直连获取对方业务数据一律通过 API 接口交互这也是微服务拆分的一个重要依据。 垂直分库很大程度上取决于业务的划分但有时候业务间的划分并不是那么清晰比如电商中订单数据的拆分其他很多业务都依赖于订单数据有时候界线不是很好划分。
垂直分库把一个库的压力分摊到多个库提升了一些数据库性能但并没有解决由于单表数据量过大导致的性能问题所以就需要配合后边的分表来解决。
2、垂直分表
垂直分表针对业务上字段比较多的大表进行的一般是把业务宽表中比较独立的字段或者不常用的字段拆分到单独的数据表中是一种大表拆小表的模式。
例如一张 t_order 订单表上有几十个字段其中订单金额相关字段计算频繁为了不影响订单表 t_order 的性能就可以把订单金额相关字段拆出来单独维护一个 t_order_price_expansion 扩展表这样每张表只存储原表的一部分字段通过订单号 order_no 做关联再将拆分出来的表路由到不同的库中。 数据库它是以行为单位将数据加载到内存中这样拆分以后核心表大多是访问频率较高的字段而且字段长度也都较短因而可以加载更多数据到内存中减少磁盘 IO增加索引查询的命中率进一步提升数据库性能。
水平拆分
上边垂直分库、垂直分表后还是会存在单库、表数据量过大的问题当我们的应用已经无法在细粒度的垂直切分时依旧存在单库读写、存储性能瓶颈这时就要配合水平分库、水平分表一起了。
1、水平分库
水平分库是把同一个表按一定规则拆分到不同的数据库中每个库可以位于不同的服务器上以此实现水平扩展是一种常见的提升数据库性能的方式。 例如db_orde_1、db_order_2 两个数据库内有完全相同的 t_order 表我们在访问某一笔订单时可以通过对订单的订单编号取模的方式 订单编号 mod 2 数据库实例数 指定该订单应该在哪个数据库中操作。
这种方案往往能解决单库存储量及性能瓶颈问题但由于同一个表被分配在不同的数据库中数据的访问需要额外的路由工作因此系统的复杂度也被提升了。
2、水平分表
水平分表是在同一个数据库内把一张大数据量的表按一定规则切分成多个结构完全相同表而每个表只存原表的一部分数据。
例如一张 t_order 订单表有 900 万数据经过水平拆分出来三个表t_order_1、t_order_2、t_order_3每张表存有数据 300 万以此类推。 水平分表尽管拆分了表但子表都还是在同一个数据库实例中只是解决了单一表数据量过大的问题并没有将拆分后的表分散到不同的机器上还在竞争同一个物理机的 CPU、内存、网络 IO 等。要想进一步提升性能就需要将拆分后的表分散到不同的数据库中达到分布式的效果。 数据存在哪个库的表
分库分表以后会出现一个问题一张表会出现在多个数据库里到底该往哪个库的哪个表里存呢
上边我们多次提到过一定规则 其实这个规则它是一种路由算法决定了一条数据具体应该存在哪个数据库的哪张表里。
常见的有 取模算法 、范围限定算法、范围取模算法 、预定义算法
1、取模算法
关键字段取模对 hash 结果取余数 hash (XXX) mod N)N 为数据库实例数或子表数量是最为常见的一种路由方式。
以 t_order 订单表为例先给数据库从 0 到 N-1 进行编号对 t_order 订单表中 order_no 订单编号字段进行取模 hash(order_no) mod N得到余数 i。i0 存第一个库i1 存第二个库i2 存第三个库以此类推。 同一笔订单数据会落在同一个库、表里查询时用相同的规则用 t_order 订单编号作为查询条件就能快速的定位到数据。
优点
实现简单数据分布相对比较均匀不易出现请求都打到一个库上的情况。
缺点
取模算法对集群的伸缩支持不太友好集群中有 N 个数据库实 ·hash(user_id) mod N当某一台机器宕机本应该落在该数据库的请求就无法得到处理这时宕掉的实例会被踢出集群。
此时机器数减少算法发生变化 hash(user_id) mod N-1同一用户数据落在了在不同数据库中等这台机器恢复用 user_id 作为条件查询用户数据就会少一部分。
2、范围限定算法
范围限定算法以某些范围字段如时间或 ID区拆分。
用户表 t_user 被拆分成 t_user_1、t_user_2、t_user_3 三张表后续将 user_id 范围为 1 ~ 1000w 的用户数据放入 t_user_11000~ 2000w 放入 t_user_22000~3000w 放入 t_user_3以此类推。按日期范围划分同理。 优点
单表数据量是可控的水平扩展简单只需增加节点即可无需对其他分片的数据进行迁移
缺点
由于连续分片可能存在数据热点比如按时间字段分片时如果某一段时间双 11 等大促订单骤增存 11 月数据的表可能会被频繁的读写其他分片表存储的历史数据则很少被查询导致数据倾斜数据库压力分摊不均匀。
3、范围 取模算法
为了避免热点数据的问题我们可以对上范围算法优化一下
这次我们先通过范围算法定义每个库的用户表 t_user 只存 1000w 数据第一个 db_order_1 库存放 userId 从 1 ~ 1000w第二个库 1000~2000w第三个库 2000~3000w以此类推。 每个库里再把用户表 t_user 拆分成 t_user_1、t_user_2、t_user_3 等对 userd 进行取模路由到对应的表中。
有效的避免数据分布不均匀的问题数据库水平扩展也简单直接添加实例无需迁移历史数据。
4、地理位置分片
地理位置分片其实是一个更大的范围按城市或者地域划分比如华东、华北数据放在不同的分片库、表。
5、预定义算法
预定义算法是事先已经明确知道分库和分表的数量可以直接将某类数据路由到指定库或表中查询的时候亦是如此。
分库分表出来的问题
了解了上边分库分表的拆分方式不难发现相比于拆分前的单库单表系统的数据存储架构演变到现在已经变得非常复杂。看几个具有代表性的问题比如
分页、排序、跨节点联合查询
分页、排序、联合查询这些看似普通开发中使用频率较高的操作在分库分表后却是让人非常头疼的问题。把分散在不同库中表的数据查询出来再将所有结果进行汇总合并整理后提供给用户。
比如我们要查询 11、12 月的订单数据如果两个月的数据是分散到了不同的数据库实例则要查询两个数据库相关的数据在对数据合并排序、分页过程繁琐复杂。 事务一致性
分库分表后由于表分布在不同库中不可避免会带来跨库事务问题。后续会分别以阿里的 Seata 和 MySQL 的 XA 协议实现分布式事务用来比较各自的优势与不足。
全局唯一的主键
分库分表后数据库表的主键 ID 业务意义就不大了因为无法在标识唯一一条记录例如多张表 t_order_1、t_order_2 的主键 ID 全部从 1 开始会重复此时我们需要主动为一条记录分配一个 ID这个全局唯一的 ID 就叫分布式ID发放这个 ID 的系统通常被叫发号器。
多数据库高效治理
对多个数据库以及库内大量分片表的高效治理是非常有必要因为像某宝这种大厂一次大促下来订单表可能会被拆分成成千上万个 t_order_n 表如果没有高效的管理方案手动建表、排查问题是一件很恐怖的事。
历史数据迁移
分库分表架构落地以后首要的问题就是如何平滑的迁移历史数据增量数据和全量数据迁移这又是一个比较麻烦的事情后边详细讲。
分库分表架构模式
分库分表架构主要有两种模式client 客户端模式和 proxy 代理模式
客户模式
client 模式指分库分表的逻辑都在你的系统应用内部进行控制应用会将拆分后的 SQL 直连多个数据库进行操作然后本地进行数据的合并汇总等操作。 代理模式
proxy 代理模式将应用程序与 MySQL 数据库隔离业务方的应用不在需要直连数据库而是连接 proxy 代理服务代理服务实现了 MySQL 的协议对业务方来说代理服务就是数据库它会将 SQL 分发到具体的数据库进行执行并返回结果。该服务内有分库分表的配置根据配置自动创建分片表。 如何抉择
如何选择 client 模式和 proxy 模式我们可以从以下几个方面来简单做下比较。
1、性能
性能方面 client 模式表现的稍好一些它是直接连接 MySQL 执行命令 proxy 代理服务则将整个执行链路延长了应用 - 代理服务 -MySQL可能导致性能有一些损耗但两者差距并不是非常大。
2、复杂度
client 模式在开发使用通常引入一个 jar 可以 proxy 代理模式则需要搭建单独的服务有一定的维护成本既然是服务那么就要考虑高可用毕竟应用的所有 SQL 都要通过它转发至 MySQL。
3、升级
client 模式分库分表一般是依赖基础架构团队的 Jar 包一旦有版本升级或者 Bug 修改所有应用到的项目都要跟着升级。小规模的团队服务少升级问题不大如果是大公司服务规模大且涉及到跨多部门那么升级一次成本就比较高
proxy 模式在升级方面优势很明显发布新功能或者修复 Bug只要重新部署代理服务集群即可业务方是无感知的但要保证发布过程中服务的可用性。
4、治理、监控
client 模式由于是内嵌在应用内应用集群部署不太方便统一处理proxy 模式在对 SQL 限流、读写权限控制、监控、告警等服务治理方面更优雅一些。
