甘肃省水利工程建设网站,apt安装wordpress,[ 1500元做网站_验收满意再付款! ,网站建设维护为什么使用分库分表#xff1f;
传统的将数据集中存储至单一数据节点的解决方案#xff0c;在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。
1#xff09;性能
从性能方面来说#xff0c;由于关系型数据库大多采用 B 树类型的索引#xff0c;在数…为什么使用分库分表
传统的将数据集中存储至单一数据节点的解决方案在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。
1性能
从性能方面来说由于关系型数据库大多采用 B 树类型的索引在数据量超过阈值的情况下索引深度的增加也将使得磁盘访问的 IO 次数增加进而导致查询性能的下降。
同时高并发访问请求也使得集中式数据库成为系统的最大瓶颈。
2可用性
从可用性的方面来讲服务化的无状态型能够达到较小成本的随意扩容这必然导致系统的最终压力都落在数据库之上。而单一的数据节点或者简单的主从架构已经越来越难以承担。数据库的可用性已成为整个系统的关键。
3运维成本
从运维成本方面考虑当一个数据库实例中的数据达到阈值以上对于 DBA 的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲单一数据库实例的数据的阈值在 1TB 之内是比较合理的范围。 那么为什么不选择 NoSQL 呢
在传统的关系型数据库无法满足互联网场景需要的情况下将数据存储至原生支持分布式的 NoSQL 的尝试越来越多。 但 NoSQL 对 SQL 的不兼容性以及生态圈的不完善使得它们在与关系型数据库的博弈中始终无法完成致命一击而关系型数据库的地位却依然不可撼动 什么是分库分表
水平分库
概念以字段为依据按照一定策略hash、range等将一个库中的数据拆分到多个库中。
结果
每个库的结构都一样
每个库中的数据不一样没有交集
所有库的数据并集是全量数据
场景系统绝对并发量上来了分表难以根本上解决问题并且还没有明显的业务归属来垂直分库的情况下。
分析库多了IO 和 CPU 的压力自然可以成倍缓解。 水平分表
概念以字段为依据按照一定策略hash、range 等讲一个表中的数据拆分到多个表中。
结果
每个表的结构都一样。
每个表的数据不一样没有交集所有表的并集是全量数据。
场景系统绝对并发量没有上来只是单表的数据量太多影响了 SQL 效率加重了 CPU 负担以至于成为瓶颈可以考虑水平分表。
分析单表的数据量少了单次执行 SQL 执行效率高了自然减轻了 CPU 的负担。 垂直分库
概念以表为依据按照业务归属不同将不同的表拆分到不同的库中
结果
每个库的结构都不一样。
每个库的数据也不一样没有交集。
所有库的并集是全量数据。
场景系统绝对并发量上来了并且可以抽象出单独的业务模块的情况下。
分析到这一步基本上就可以服务化了。例如随着业务的发展一些公用的配置表、字典表等越来越多这时可以将这些表拆到单独的库中甚至可以服务化。再者随着业务的发展孵化出了一套业务模式这时可以将相关的表拆到单独的库中甚至可以服务化。 垂直分表 概念以字段为依据按照字段的活跃性将表中字段拆到不同的表中主表和扩展表。
结果
每个表的结构不一样。
每个表的数据也不一样一般来说每个表的字段至少有一列交集一般是主键用于关联数据。
所有表的并集是全量数据。
场景系统绝对并发量并没有上来表的记录并不多但是字段多并且热点数据和非热点数据在一起单行数据所需的存储空间较大以至于数据库缓存的数据行减少查询时回去读磁盘数据产生大量随机读 IO产生 IO 瓶颈
分析
可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据可能经常会查询的数据放在一起作为主表非热点数据放在一起作为扩展表这样更多的热点数据就能被缓存下来进而减少了随机读 IO。拆了之后要想获取全部数据就需要关联两个表来取数据。但记住千万别用 Join因为 Join 不仅会增加 CPU 负担并且会将两个表耦合在一起必须在一个数据库实例上。关联数据应该在 Service 层进行分别获取主表和扩展表的数据然后用关联字段关联得到全部数据。 什么时候考虑分库分表
能不分就不分
并不是所有表都需要切分主要还是看数据的增长速度。切分后在某种程度上提升了业务的复杂程度。不到万不得已不要轻易使用分库分表这个“大招”避免“过度设计”和“过早优化”。
分库分表之前先尽力做力所能及的优化升级硬件、升级网络、读写分离、索引优化等。当数据量达到单表瓶颈后在考虑分库分表。
数据量过大正常运维影响业务访问
这里的运维是指
对数据库备份如果单表太大备份时需要大量的磁盘 IO 和网络 IO。
对一个很大的表做 DDLMySQL会锁住整个表这个时间会很长这段时间业务不能访问此表影响很大。
大表经常访问和更新就更有可能出现锁等待。
随着业务发展需要对某些字段垂直拆分
这里就不举例了在实际业务中都可能会碰到有些不经常访问或者更新频率低的字段应该从大表中分离出去。 数据量快速增长
随着业务的快速发展单表中的数据量会持续增长当性能接近瓶颈时就需要考虑水平切分做分库分表了。 分库分表带来的问题
事务一致性问题
①分布式事务
当更新内容同时存在于不同库找那个不可避免会带来跨库事务问题。跨分片事务也是分布式事务没有简单的方案一般可使用“XA 协议”和“两阶段提交”处理。
分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点推后了提交事务的时间点延长了事务的执行时间导致事务在访问共享资源时发生冲突或死锁的概率增高。
随着数据库节点的增多这种趋势会越来越严重从而成为系统在数据库层面上水平扩展的枷锁。 ②最终一致性
对于那些性能要求很高但对一致性要求不高的系统往往不苛求系统的实时一致性只要在允许的时间段内达到最终一致性即可可采用事务补偿的方式。
与事务在执行中发生错误立刻回滚的方式不同事务补偿是一种事后检查补救的措施一些常见的实现方法有对数据进行对账检查基于日志进行对比定期同标准数据来源进行同步等。
跨节点关联查询 Join 问题
切分之前系统中很多列表和详情表的数据可以通过 Join 来完成但是切分之后数据可能分布在不同的节点上此时 Join 带来的问题就比较麻烦了考虑到性能尽量避免使用 Join 查询。
解决的一些方法
①全局表
全局表也可看做“数据字典表”就是系统中所有模块都可能依赖的一些表为了避免库 Join 查询可以将这类表在每个数据库中都保存一份。这些数据通常很少修改所以不必担心一致性的问题。 ②字段冗余
一种典型的反范式设计利用空间换时间为了性能而避免 Join 查询。
例如订单表在保存 userId 的时候也将 userName 也冗余的保存一份这样查询订单详情顺表就可以查到用户名 userName就不用查询买家 user 表了。
但这种方法适用场景也有限比较适用依赖字段比较少的情况而冗余字段的一致性也较难保证。
③数据组装
在系统 Service 业务层面分两次查询第一次查询的结果集找出关联的数据 id然后根据 id 发起器二次请求得到关联数据最后将获得的结果进行字段组装。这是比较常用的方法。 ④ER 分片 分片键的选择
分库分表后分片键的选择非常重要。一般来说是这样的
信息表使用 id 进行分片。例如说文章、商品信息等等。
业务表使用 user_id 进行分片。例如说订单表、支付表等等。
日志表使用 create_time 进行分片。例如说访问日志、登陆日志等等。
分片算法的选择
选择好分片键之后还需要考虑分片算法。一般来说有如下两种
取余分片算法。例如说有四个库那么 user_id 为 10 时分到第 10 % 4 2 个库。
当然如果分片键是字符串则需要先进行 hash 的方式转换成整形这样才可以取余。
当然如果分片键是整数也可以使用 hash 的方式。
范围算法。
例如说时间范围。
上述两种算法各有优缺点。
对于取余来说
好处可以平均分配每个库的数据量和请求压力。
坏处在于说扩容起来比较麻烦会有一个数据迁移的过程之前的数据需要重新计算 hash 值重新分配到不同的库或表。
对于 range 来说
好处扩容的时候很简单因为你只要预备好给每个月都准备一个库就可以了到了一个新的月份的时候自然而然就会写新的库了。
缺点但是大部分的请求都是访问最新的数据。实际生产用 range要看场景。 分库分表中间件
1Cobar
阿里 b2b 团队开发和开源的属于 Proxy 层方案。
早些年还可以用但是最近几年都没更新了基本没啥人用差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。
2MyCAT
基于 Cobar 改造的属于 Proxy 层方案支持的功能非常完善而且目前应该是非常火的而且不断流行的数据库中间件社区很活跃也有一些公司开始在用了。但是确实相比于 Sharding Sphere 来说年轻一些经历的锤炼少一些。
3Atlas
360 开源的属于 Proxy 层方案以前是有一些公司在用的但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以现在用的公司基本也很少了。
4TDDL
淘宝团队开发的属于 client 层方案。支持基本的 crud 语法和读写分离但不支持 join、多表查询等语法。目前使用的也不多因为还依赖淘宝的 diamond 配置管理系统。
5Sharding Sphere
Sharding Sphere 可能是目前最好的开源的分库分表解决方案目前已经进入 Apache 孵化。
