浙江建设工程信息网站,辽宁建设工程信息网场内业绩什么意思,点网站建设,php网站后台无法上传图片一#xff0c;背景 随着互联网的普及#xff0c;使用人数和场景爆炸式增长#xff0c;现在随便一个应用系统都可能达到数百万千万甚至更大数量级的数据。大量的数据带来了新的挑战#xff0c;怎么快速完成增删改查的业务#xff0c;是应用服务开发者最头痛的问题。面对这个…
一背景 随着互联网的普及使用人数和场景爆炸式增长现在随便一个应用系统都可能达到数百万千万甚至更大数量级的数据。大量的数据带来了新的挑战怎么快速完成增删改查的业务是应用服务开发者最头痛的问题。面对这个问题分库分表是一个很好的思路今天来聊聊分库分表。 二概念
1什么是分库分表
分库分表是一种数据库架构优化技术本质上就是一种分治思想。通过分库分表将数据分散到多个数据库或表中来提高系统的性能和稳定性。分库分表可以分为以下几种策略水平分库、水平分表、垂直分库、垂直分表。
下面以订单数据库db_order和订单表tb_order为例来说明。
1.1 水平分库
按照某些规则比如说按照年份对订单数据库进行划分一年一个数据库如db_order_2024,db_order_2025下面的表和表结构完全一致但是存储的数据不一样分别归属于不同年份的订单数据。 1.2 垂直分库
根据业务功能不同将数据分拆到不同的数据库中比如订单、用户、商品、客户的数据分别存储到订单数据库、用户数据库、商品数据库和客户数据库中。
1.3 水平分表
对数据表中数据根据某个字段来做分表比如根据订单创建月份来分表order_01和order_02 各个表的结构完全一致只是存储的数据分属于各个不同的月份。 1.4 垂直分表
按照业务和是否常用或者是否强关联来把宽表拆分比如订单信息中的商品和下单人等信息可以拆分成子表通过id来关联。 三落地
具体可以看看完这篇别再说不会Spring 分库分表了_spring data jpa 分库分表-CSDN博客
可用的方案其实很多比如常见的shardingsphere和mycat 四问题
1什么情况下需要分表
根据阿里的规范建议如下 事实上通常在实战中一般按经验数据达到千万级就需要分库分表。原因如下
我们知道InnoDB管理磁盘的最小单元页页大小16KB.
mysql show global status like %Innodb_page_size%;
-------------------------
| Variable_name | Value |
-------------------------
| Innodb_page_size | 16384 |
-------------------------
1 row in set (0.00 sec)在日常开发中对于数据库性能优化我们首先想到的是索引优化。索引的底层数据结构是B树。其组织结构如图所示 树高为3的B树数据存储计算规则
根节点计算
假设数据类型是bigint大小为8b。数据本身也需要一小块空间用来存储下一层索引数据页的地址大小为6b 那么根节点是可以存储16*1024/(86) 1170 个数据。
其它层节点计算
第二层因为每个节点数据结构和跟节点一样而且在跟节点每个元素都会延伸出来一个节点所以第二层的数据量是1170*11701368900
第三层因为innodb的叶子节点是直接包含整条mysql数据的假设每条数据以1kb计算那么第三层每个节点为16kb那么每个节点是可以放16个数据的所以最终mysql可以存储的总数据为
1170 * 1170 * 16 21902400 (千万级)
其实计算结果与我们平时的工作经验也是相符的一般mysql一张表的数据超过了千万也是得进行分表操作了。 2如何选择分片键 例如本节我们以订单表的分表为例一般订单表中含有订单编号order_id, 用户编号user_id, 订单创建时间order_date等。
对于订单表通常我们可以考虑以下分片键选项
2.1 订单编号
优点订单编号通常是唯一的可以确保每个订单都分散到不同的分片上。这对于保证数据均匀分布和避免热点数据非常有帮助。
2.2 用户编号
优点用户编号通常也是唯一的并且如果用户的订单量分布均匀那么使用用户编号作为分片键可以确保每个用户的订单都在同一个分片上这对于查询某个用户的所有订单非常高效。
缺点如果用户的订单量差异很大那么某些分片可能会存储大量的订单数据而其他分片可能只有少量的数据。这会导致数据分布不均匀进而影响查询性能。
2.3 订单创建时间
优点适用于按时间范围查询订单的场景。
缺点可能出现热点数据倾斜问题即在某个时段产生订单峰值 3如何选择数据库主键策略
在选择主键策略时需要注意以下几点 唯一性确保主键在全局唯一避免数据冲突。 性能选择适合的主键类型和生成策略以提高数据插入、查询和索引的性能。 扩展性能够适应数据量和并发量增长。 兼容性选择的主键策略要与使用的数据库兼容。 在 MySQL 中进行分库分表时自增主键策略确实需要特别处理因为传统的自增主键策略在分布式环境下会导致主键冲突。每个数据库实例或分片都会从相同的起始点开始自增这会导致在不同的分片上生成相同的 ID进而引发数据冲突。 4几种常见的主键策略 UUIDUUID 是一个 128 位的值具有全局唯一性可以很好地解决分布式环境下的主键冲突问题。但是UUID 字符串较长存储和索引效率较低而且是无序的可能会影响查询性能。 Snowflake 算法雪花算法SnowFlake是一种分布式ID生成算法由Twitter开源。其核心思想是使用64位long型数字作为全局唯一的ID通过时间戳、工作机器ID和序列号等部分来确保ID的全局唯一性。 结构说明 1位未使用因为二进制中最高位是符号位正数是0负数是1一般生成的ID都是正数所以这一位固定为0。 41位时间戳毫秒级用来记录时间截的差值当前时间截 - 开始时间截。 10位工作机器ID包括5位datacenterId数据中心ID和5位workerId工作机器ID用来表示工作机器的ID。 12位序列号用来记录同一毫秒内产生的不同ID12位可以表示的最大整数为4095用来表示同一机器同一时间截毫秒内产生的4095个ID序号。 通过这种结构雪花算法可以保证生成的ID按时间递增并且整个分布式系统中不会有重复的ID。 分布式自增 ID 生成器使用像 Twitter 的 Snowflake、阿里巴巴的 Druid 等分布式 ID 生成器来生成全局唯一的自增 ID。这些生成器通过特定的算法和机制保证在不同实例间生成的 ID 是全局唯一的。 自增主键 分片策略仍然使用自增主键但是结合分片策略确保每个分片上的主键值是唯一的。例如可以预先为每个分片分配一个 ID 范围确保在这个范围内的 ID 是唯一的。这种方法需要维护分片的 ID 范围并在必要时进行调整。 使用数据库的自增 ID 特性某些数据库支持在分表时自动处理自增 ID避免冲突。例如MySQL 8.0 引入了 AUTO_INCREMENT_INCREMENT 和 AUTO_INCREMENT_OFFSET 这两个系统变量用于在复制或分片环境中调整自增 ID 的步长和起始值从而避免冲突。
总之在分库分表时自增主键策略需要进行特殊处理以确保全局唯一性并根据实际情况选择合适的方案。 5如何选择分表策略
选择分库分表的策略时确实需要根据具体的业务场景和数据特性来决定。例如订单表以订单ID (order_id) 作为分表键。
5.1 基于范围的策略
适用场景当订单ID有明确的增长趋势例如连续的自增ID并且你知道未来可能的订单数量时范围分表是一个好选择。
策略实现可以将订单ID按照范围划分到不同的表中。例如订单ID【1-1000万】 在表tb_order_01【1000万-2000万】在表tb_order_02以此类推。 优点 查询效率较高尤其是范围查询。数据迁移和维护相对简单。
缺点 订单ID的分布必须均匀. 如果订单ID不是连续或可预测的这种策略可能不适用。 5.2 基于哈希的策略
适用场景当订单ID没有明确的增长趋势哈希分表是一个好选择。
策略实现使用哈希函数对订单ID进行哈希运算然后根据哈希值的结果决定存储在哪个表中。
table_index hash(order_id) % tables_num优点 负载均衡每个表的数据分布相对均匀。
缺点 不利于二次扩容。 5.3 映射表策略
适用场景当订单ID的分布不均或者需要灵活控制数据分布时映射表分表可能是一个好选择。
策略实现使用一个映射表来记录每个订单ID应该存储在哪个表中。这个映射表可以是内存中的数据结构也可以是数据库中的一个表。
优点 灵活可以根据需要调整数据分布。
缺点 查询时需要先查询映射表可能影响性能。 5.4 一致性哈希策略
适用场景当系统需要高可用性并且希望在添加或删除节点时尽量减少数据迁移时一致性哈希可能是一个好选择。
策略实现使用一致性哈希算法将订单ID映射到哈希环上然后根据哈希环上的节点或表来存储数据。
一致性哈希算法的核心思想是将哈希值空间表示为一个闭合的圆环哈希环每个节点负责维护圆环上一段连续的哈希值范围。 在分库分表的场景中可以将每个数据库或表看作是一个节点将这些节点均匀地分布在哈希环上。当插入或查询数据时根据数据的哈希值将其映射到哈希环上然后顺时针查找最近的节点即负责该哈希值范围的数据库或表将数据插入或查询该节点。优点 支持节点的动态扩容。缺点 当节点数量变化较大时可能需要重新计算所有数据的哈希值并进行迁移增加系统的开销范围查询和顺序查询可能不如范围分表和哈希分表高效。
6非分片键字段如何查询 曾几何时面试过程中遇到过这样一个问题假设有一个用户表你用ID做的分片键那么有一个类似于name这样的字段如何查询
这里提供几种常见的思路
6.1.全局索引 全局索引是一个跨所有分片的索引它包含了非分片键字段和对应的分片键信息。查询时先通过全局索引找到相关的分片键然后在相应的分片中查询详细数据。 适用场景适用于查询频率高、数据量大的非分片键字段。 优点查询效率高可以快速定位到数据所在的分片。 缺点全局索引维护成本较高需要定期更新以保持与分片数据的一致性。
6.2. 数据冗余 在每个分片中存储部分非分片键字段的数据。这样即使不直接查询分片键也可以在分片内快速找到相关数据。 适用场景适用于查询性能要求极高且可以接受一定数据冗余的场景。 优点查询性能高无需跨分片查询。 缺点数据冗余增加了存储成本和维护复杂性。
6.3. 应用层处理 在应用层实现复杂的查询逻辑将多个分片中的查询结果汇总后进行处理。 适用场景适用于查询频率不高或者可以接受一定延迟的场景。 优点灵活性高可以根据业务需求定制查询逻辑。 缺点查询性能可能受到网络延迟和分片数量的影响。
6.4. 使用Elasticsearch 将非分片键字段的数据同步到Elasticsearch中利用Elasticsearch强大的搜索和查询能力进行查询。 适用场景适用于非结构化数据、全文搜索、复杂查询等场景。 优点支持复杂的查询操作如全文搜索、模糊匹配等查询性能高支持分布式部署。 缺点需要维护Elasticsearch集群增加了系统的复杂性数据同步可能引入一定的延迟。
6.5. 数据库中间件
使用数据库中间件如ShardingSphere、MyCAT等来管理分库分表中间件可以自动处理非分片键字段的查询将请求路由到正确的分片。 适用场景适用于希望减少应用层复杂性的场景。 优点简化了应用层的查询逻辑减少了开发和维护的工作量。 缺点需要配置和维护数据库中间件。 7如何解决热点数据倾斜问题
热点数据倾斜通常发生在某些特定的数据项例如用户激增、促销订单峰值等等导致这些数据的查询和更新操作集中在些某特定的数据库或表上从而造成性能瓶颈。
解决方案采用Range分库Hash分表 8如何解决跨库关联查询
分库分表后数据被分散到了不同的数据库或表中。跨库关联查询成为新的问题。为了解决这个问题可以采取以下几种策略 字段冗余对于经常需要进行关联查询的字段可以考虑将这些字段冗余到每个相关的表中。这样在进行查询时就不需要跨库关联可以直接在单个表内完成查询。例如如果经常需要查询合同和客户的关联信息可以在合同表中冗余一些客户的基础字段这样查询时就不需要跨库关联客户表。 数据同步如果某个系统经常需要查询另一个系统的数据可以在当前系统中创建一张对应的表并通过ETL或其他数据同步工具定时同步所需的数据。这样查询时就可以直接在本地表中完成避免了跨库关联查询。 全局表广播表对于某些基础数据如行名行号信息等如果它们被多个业务系统频繁使用可以考虑在所有的数据库中都存储这些基础数据。这样无论哪个系统需要这些数据都不需要进行跨库关联查询。 ER表绑定表对于存在逻辑主外键关系的表如订单表和订单明细表可以考虑将它们的数据物理上存储在一起形成一个绑定表。这样查询时就可以在一个表中完成主表和明细表的关联查询避免了跨库关联。 使用分布式中间件分布式中间件如Sharding-JDBC、MyCAT等可以将多个物理数据库视为一个逻辑数据库。这些中间件能够处理复杂的联合查询、排序、聚合等SQL操作并根据分片规则指导SQL语句的执行。它们能够解决分库分表后的通过程序聚合汇总结果解决跨库关联查询问题。 应用层数据聚合在应用层可以编写逻辑来聚合来自不同数据库或表的数据。这通常涉及发起多个数据库查询然后在应用层将结果集合并成所需的结构。
需要注意的是虽然上述方法可以解决跨库关联查询的问题但它们也会带来一些额外的复杂性。在设计分库分表方案时需要综合考虑业务需求、数据量、查询频率等因素选择合适的策略来平衡性能和可维护性。同时随着业务的发展和数据量的增长可能需要对分库分表方案进行调整和优化。
9如何解决分库分表后排序问题 分库分表后排序和分页问题变得相对复杂因为数据不再集中在一个单一的数据库或表中。解决这些问题需要综合考虑多种因素包括数据量、查询频率、业务需求等。以下是一些解决分库分表后排序和分页问题的策略 全局排序字段在分库分表时可以引入一个全局排序字段所有分片都基于这个字段进行排序。这样即使数据分布在不同的分片中也可以保证整体排序的一致性。 数据同步与合并在查询时从各个分片中分别获取数据然后在应用层将这些数据按照排序规则进行合并。这种方式需要处理大量的数据传输和合并逻辑可能对性能有一定影响。 中间件支持使用支持分库分表的中间件如ShardingSphere、MyCAT等。这些中间件通常提供了强大的排序功能能够处理分库分表后的排序问题。 预算与缓存对于某些固定的排序需求可以预先计算排序结果并缓存起来减少实时计算的压力。
10如何解决分库分表后分页问题 10.1 分页参数调整 在分库分表的情况下传统的LIMIT OFFSET分页方式可能不再适用。可以考虑调整分页参数比如使用基于游标cursor的分页方式或者基于时间戳、ID等排序字段的范围查询来实现分页。 10.2 数据聚合 类似于排序问题的解决方式从各个分片中分别获取数据然后在应用层进行数据聚合实现分页功能。 10.3 中间件支持使用支持分库分表的中间件这些中间件通常也提供了分页功能的支持能够简化分页查询的处理。 10.4 限制分页对于深度分页的需求可以考虑限制分页的深度避免查询大量的数据。例如只支持查询前100页的数据。 10.5 预加载与缓存对于经常访问的分页数据可以考虑预加载并缓存起来减少实时查询的开销。 11分库分表如何扩容 当数据量逐渐增加需要进行分库分表的扩容时可以从以下几个方面来考虑和制定策略 11.1. 数据增长评估: 要对数据的增长趋势进行准确的评估通过分析历史数据、业务发展趋势以及用户增长情况可以预测未来的数据量增长情况。一般预估未来3~5年的数据增长。 11.2. 选择合适的分片键: 选择一个合适的分片键是分库分表的关键。分片键应该能够均匀分布数据避免某些数据库或表过载。同时分片键的选择也要考虑到查询性能和数据一致性等因素。 11.3. 实施扩容: 基于数据增长趋势和分片键的选择制定详细的扩容计划。这包括确定扩容的时间点、扩容的目标规模、数据迁移和重新分配的策略等。确保扩容过程能够顺利进行尽可能减少对业务的影响。 11.4. 数据迁移与重新分配: 在扩容过程中需要进行数据迁移和重新分配。这通常涉及到将现有数据从旧的数据库或表迁移到新的数据库或表中。可以使用数据迁移工具或自动化脚本来完成这个过程确保数据的完整性和一致性。 11.5. 负载均衡: 在扩容后需要确保数据在新旧数据库或表之间均匀分布以实现负载均衡。可以使用负载均衡器或支持分库分表的中间件来动态分配请求确保系统的性能和稳定性。 11.6. 监控与调优: 在扩容过程中和扩容后需要对系统进行持续的监控和调优。通过监控数据库或表的负载情况、查询性能等指标及时发现并解决性能瓶颈和故障。同时根据实际需求进行调优如调整索引、优化查询语句等以提升系统的整体性能。
