wordpress改编码,广州网站优化推广方案,汕头网站推广多少钱,北京网站优化网目录
为什么会分表分库#xff1f;
数据分表
怎么分表#xff1f;
垂直分表
好处#xff1a;
缺点#xff1a;
水平分表
优点#xff1a;
缺点#xff1a;
数据分库
怎么分库#xff1f; 水平分库
适用场景#xff1a;
优点#xff1a;
注意事项#x…目录
为什么会分表分库
数据分表
怎么分表
垂直分表
好处
缺点
水平分表
优点
缺点
数据分库
怎么分库 水平分库
适用场景
优点
注意事项
垂直分库
适用场景
优点
注意事项
分库分表之后的常见问题
1.数据一致性问题
问题描述
解决方案
2.数据迁移和扩容
问题描述
解决方案
3.跨表查询性能
问题描述
解决方案
4.分布式事务管理
问题描述
解决方案
5.业务逻辑调整
问题描述
解决方案 为什么会分表分库
数据库数据会随着业务的发展而不断增多因此数据操作如增删改查的开销也会越来越大。
再加上物理服务器的资源有限CPU、磁盘、内存、IO 等。最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。
换句话说需要合理的数据库架构来存放不断增长的数据这个就是分库分表的设计初衷。目的就是为了缓解数据库的压力最大限度提高数据操作的效率。
数据分表
如果单表的数据量过大例如千万级甚至更多那么在操作表的时候就会加大系统的开销。
每次查询会消耗数据库大量资源如果需要多表的联合查询这种劣势就更加明显了。
以 MySQL 为例在插入数据的时候会对表进行加锁分为表锁定和行锁定。
无论是哪种锁定方式都意味着前面一条数据在操作表或者行的时候后面的请求都在排队当访问量增加的时候都会影响数据库的效率。
那么既然一定要分表那么每张表分配多大的数据量比较合适呢这里建议根据业务场景和实际情况具体分析。
一般来说 MySQL 数据库单表记录最好控制在 500 万条这是个经验数字。既然需要将数据从一个表分别存放到多个表中那么来看看下面两种分表方式吧。
怎么分表
垂直分表
直分表是一种将大型表按列进行拆分将不同的列分离出来形成多个表的分表方案。通过垂直分表可以将冗余的数据和低频使用的列从主表中分离出来提高查询性能和减少存储空间的占用。
垂直分表通常基于数据的逻辑关系进行划分可以按照以下方式进行 垂直拆分Vertical Splitting将原始表中的列按照功能或使用频率进行拆分形成多个表。例如将经常变更的列和不经常使用的列从主表中分离出来形成一个或多个辅助表。这样可以减少主表的数据量提高查询性能。 冷热数据分离Hot and Cold Data Separation将热数据经常被查询的数据和冷数据不经常被查询的数据分离到不同的表中。将热数据存储在主表中而将冷数据存储在单独的表中可以提高主表的查询性能。 稀疏列拆分Sparse Column Splitting对于具有大量稀疏列的表可以将这些列拆分成一个或多个表。这种方式可以减少表的宽度提高查询效率。
好处
提高查询性能通过将数据划分到多个表中减少每个表的数据量可以加快查询速度。减少存储空间的占用将冗余的数据和低频使用的列从主表中分离出来可以减少存储空间的占用。简化数据管理和维护将不同的列划分到不同的表中可以更加灵活地进行数据管理和维护。解决业务系统层面的耦合业务清晰。
缺点
部分表无法join只能通过接口聚合方式解决提升了开发的复杂度。分布式事务处理复杂。依然存在单表数据量过多的问题需要水平切分
水平分表
将一个表中的数据按照关键字例如ID或取 Hash 之后对一个具体的数字取模得到的余数就是需要存放到的新表的位置。 用 ID 取模的分表方式分配记录
ID 分别为 01-04 的四条记录如果分配到 3 个表中那么对 3 取模得到的余数分别是
ID01 对 3 取模余数为 1 存到“表 1”。ID02 对 3 取模余数为 2 存到“表 2”。ID03 对 3 取模余数为 3 存到“表 3”。ID04 对 3 取模余数为 1 存到“表 1”。
当然这里只是一个例子实际情况需要对 ID 做 Hash 之后再计算。同时还可以针对不同表所在的不同的数据库的资源来设置存储数据的多少。针对每个表所在的库的资源设置权值。
用这种方式存放数据以后在访问具体数据的时候需要通过一个 Mapping Table 获取对应要响应的数据来自哪个数据表。目前比较流行的数据库中间件已经帮助我们实现了这部分的功能。
也就是说不用大家自己去建立这个 Mapping Table在做查询的时候中间件帮助你实现了 Mapping Table 的功能。所以我们这里只需要了解其实现原理就可以了。 Mapping Table 协助分表
水平拆分还有一种情况是根据数据产生的前后顺序来拆分存放。例如主表只存放最近 2 个月的信息其他比较老旧的信息拆分到其他的表中。通过时间来做数据区分。更有甚者是通过服务的地域来做数据区分的。
按照时间做的数据分表
需要注意的是由于分表造成一系列记录级别的问题例如 Join 和 ID 生成事务处理同时存在这些表需要跨数据库的可能性
Join需要做两次查询把两次查询的结果在应用层做合并。这种做法是最简单的在应用层设计的时候需要考虑。ID可以使用 UUID或者用一张表来存放生成的 Sequence不过效率都不算高。UUID 实现起来比较方便但是占用的空间比较大。 Sequence 表的方式节省了空间但是所有的 ID 都依赖于单表。这里介绍一个大厂用的 Snowflake 的方式。
排序/分页数据分配到水平的几个表中的时候做排序和分页或者一些集合操作是不容易的。
这里根据经验介绍两种方法。对分表的数据先进行排序/分页/聚合再进行合并。对分表的数据先进行合并再做排序/分页/聚合。
事务存在分布式事务的可能需要考虑补偿事务或者用 TCCTry Confirm Cancel协助完成。
优点 提高查询性能通过将数据行分散存储在多个表中可以提高查询性能。当查询条件涉及到分表键时MySQL可以仅扫描相关分表而不需要扫描整个表从而减少了IO开销和查询时间。 管理简化对于大型表水平分表可以简化数据管理。可以针对某个分表执行备份、恢复、优化等操作而不需要对整个表进行操作。同时也方便进行数据迁移和维护。 分布式处理水平分表可以支持分布式处理允许将数据分布在多台服务器上以提高系统的并发性和扩展性。
缺点 连接操作复杂当需要跨多个分表进行连接查询时会增加查询的复杂性。需要使用特殊的语法或合并结果集来获取完整的查询结果。 数据一致性难以保证在水平分表的情况下某些操作如跨分表事务可能难以保证数据的一致性。 分布式事务问题当使用分片技术进行水平分表时可能会涉及到分布式事务的处理这增加了系统的复杂性和开发成本。
数据分库
每个物理数据库支持数据都是有限的每一次的数据库请求都会产生一次数据库链接当一个库无法支持更多访问的时候我们会把原来的单个数据库分成多个帮助分担压力。
怎么分库
这里有几类分库的原则可以根据具体场景进行选择
根据业务不同分库这种情况都会把主营业务和其他功能分开。例如可以分为订单数据库核算数据库评论数据库。根据冷热数据进行分库用数据访问频率来划分例如近一个月的交易数据属于高频数据2-6 个月的交易数据属于中频数据大于 6 个月的数据属于低频数据。根据访问数据的地域/时间范围进行分库。
水平分库
适用场景
当单个数据库中的表过多时可以根据业务逻辑将不同类型或功能相关的表分散到不同的数据库中以减轻单个数据库的负担和提高数据库性能。 概念以字段为依据按照一定策略hash、range等将一个库中的数据拆分到多个库中。 结果
每个库的结构都一样每个库的数据都不一样没有交集所有库的并集是全量数据
优点
可以根据业务需求和访问模式灵活地划分数据库降低单个数据库的数据量和提高数据库性能。
注意事项
不同的数据库应该存放在不同的服务器上需要考虑数据库之间的数据一致性和跨库事务管理。
垂直分库
适用场景
当单个数据库的性能达到瓶颈时可以根据某种规则将数据划分到多个数据库中每个数据库负责存储部分数据以提高数据库的扩展性和性能。 概念以表为依据按照业务归属不同将不同的表拆分到不同的库中。 结果
每个库的结构都不一样每个库的数据也不一样没有交集所有库的并集是全量数据
优点
可以将数据分散存储在多个数据库中有效缓解单库的性能瓶颈和压力提高系统的并发处理能力。
注意事项
需要考虑数据库之间的数据同步和一致性、跨库事务管理、数据路由和负载均衡等问题选择合适的分库规则和策略。
分库分表之后的常见问题
1.数据一致性问题
问题描述
分库分表后跨库、跨表的事务管理和数据同步变得复杂。需要考虑如何确保数据的一致性以及在分布式环境下如何处理跨库事务和并发访问。
解决方案
使用分布式事务管理框架如Seata、XA协议等来确保分布式事务的一致性。 采用消息队列等异步处理机制将跨库事务拆分成本地事务并通过消息队列来实现最终一致性。 设计合适的数据同步方案定期或实时地将数据同步到各个库中确保数据的一致性。
2.数据迁移和扩容
问题描述
随着业务的增长可能需要对分库分表进行扩容或迁移。这涉及到数据的迁移、重新分片和负载均衡等问题需要谨慎规划和执行以避免数据丢失或服务中断。
解决方案
使用分库分表中间件如MyCAT、ShardingSphere等可以简化数据迁移和扩容的过程自动进行数据的重新分片和负载均衡。 采用数据迁移工具如阿里巴巴的DataX可以实现数据的快速迁移和同步避免数据丢失或服务中断。
3.跨表查询性能
问题描述
分表后跨表查询的性能可能会受到影响特别是涉及到大量表的联合查询或聚合操作。需要设计合适的查询方案尽量减少跨表查询的频率和数据量。
解决方案
设计合适的数据模型尽量减少跨表查询的频率和数据量避免在大规模数据表上进行联合查询或聚合操作。 使用数据库索引来优化查询性能确保查询语句能够有效地利用索引进行快速检索。
4.分布式事务管理
问题描述
分库分表后事务管理变得更加复杂需要考虑分布式事务的实现和一致性保证。通常会采用两阶段提交2PC、补偿事务TCC、最终一致性等分布式事务处理方案。
解决方案
结合分布式事务管理框架设计合适的分布式事务方案确保事务的一致性和可靠性。 考虑使用柔性事务模型如TCCTry-Confirm-Cancel模式来处理分布式事务中的异常情况。
5.业务逻辑调整
问题描述
分库分表可能需要对原有的业务逻辑进行调整和优化以适应新的数据分布和访问模式。需要重新评估业务需求并根据实际情况做出相应的调整。
解决方案
根据新的数据分布和访问模式调整业务逻辑和流程优化系统性能和用户体验。 对于需要大规模重构的业务逻辑可以采用分阶段、分模块的方式进行调整以降低风险和成本。
