网站建设哪里比较好,wordpress模板转为emlog,网站维护常见问题,儋州市住房和城乡建设局官方网站什么是分库分表
分库分表是一种数据库架构优化策略#xff0c;它将数据分散存储在多个数据库或表中#xff0c;以此来提高系统的可扩展性和性能。
虽然分库分表能够提升系统的整体性能#xff0c;但是也不要一上来就分库分表#xff0c;如果系统在单表的情况下#xff0…什么是分库分表
分库分表是一种数据库架构优化策略它将数据分散存储在多个数据库或表中以此来提高系统的可扩展性和性能。
虽然分库分表能够提升系统的整体性能但是也不要一上来就分库分表如果系统在单表的情况下能够正常运行就使用单表即可
当业务出现性能瓶颈时我们可以考虑先使用分区的方式去优化如果分区之后仍然不能满足性能要求再考虑分库分表
在单库单表下如果表的数据量累积到一定的数量时5000W 行或 100G 以上数据库的性能会出现明显下降即使我们使用索引优化或读写库分离性能依然存在瓶颈。此时如果每日数据增长量非常大就应该考虑分表避免单表数据量过大造成数据库操作性能下降。
面对海量数据在单库单表下数据库连接数、磁盘 I/O 、网络吞吐、并发能力等都是有限的。所以在一些大数据量且高并发的业务场景中我们就需要考虑分库分表来提升数据库的并发处理能力从而提升应用的整体性能。
如何分库分表
通常分库分表分为垂直切分和水平切分两种。
垂直分库
垂直分库通常是根据业务模块将数据库中的表进行分类每个业务模块的表存储在独立的数据库中。这种方式可以减少数据库的宽度提高查询效率并且有利于数据库的维护和扩展。
水平分库
水平分库是将同一个库的数据按照某种规则拆分到多个数据库中每个数据库存储数据的一部分。这种方式可以有效地分散单个数据库的负载提高系统的并发处理能力。
垂直分表
垂直分表是将一个表的列拆分到多个表中通常将不常用的列或大字段拆分出来。这种方式可以减少表的宽度提高查询性能。
水平分表
水平分表是将一个大表的数据按照某种规则如哈希分片、范围分片拆分到多个表中。这种方式可以有效地分散单个表的数据量提高查询效率。 举例说明一下如何确定分表数量 提成系统有个课消明细表用来记录学生上课课时消耗详情每月大概有 400 万条数据一年就是 4800 万假如我们保留 10 年是48000 万。 假如计划单表存储 200 万数据则分表数量等于 240。 因为我们要用学生维度去查询数据所以shard 键选择用学生 ID。 分库分表后的问题
分布式事务问题
比如在电商业务中当我们提交订单时除了会创建订单还会扣除相应的库存。而订单表和库存表由于垂直分库位于不同的库中此时我们需要分布式事务来保证事务的完整性。
跨节点JOIN查询问题
用户在查询订单时往往通过表连接获取到商品信息而商品信息表可能存在其他的库中这就涉及到了跨库的 JOIN 查询。
通常可以采用冗余表和冗余字段来优化跨库 JOIN 查询。
对于一些基础表如商品信息表可以在每一个订单分库中复制一张基础表避免跨库 JOIN 查询对于一两个字段的查询可以将少量字段冗余在表中从而避免 JOIN 查询也就避免了跨库 JOIN 查询。
跨节点分页查询问题
以订单表为例通常都是使用 UserId 字段做 Hash 取模对订单表进行水平分表若考虑高并发时的订单处理能力还可以考虑基于UserId 字段 Hash 取模实现分库分表。
当用户在订单列表中查询所有订单时可以通过用户 ID 的 Hash 值来快速查询到订单信息而运营人员在后台对订单表进行查询时则是通过订单付款时间来进行查询的这些数据都分布在不同的库表中此时就存在一个跨节点分页查询的问题了。
此时可以采用两套数据来解决跨节点分页查询问题。
基于分库分表的用户单条或多条查询数据基于 Elasticsearch 存储的订单数据主要用于运营人员根据其它字段进行分页查询
为了不影响提交订单的业务性能一般使用异步消息来实现 Elasticsearch订单数据的新增和修改。
全局主键ID问题
在分库分表后需要单独设计全局主键避免不同的库和表中的主键重复问题。
有以下几种策略
UUID
UUID 是实现全局 ID 是最方便快捷的方式即随机生成一个 32 位 16 进制数字可以保证唯一性水平扩展能力以及性能都比较高。但 UUID 最大的缺陷就是它是一个比较长的字符串连续性差如果作为主键使用性能相对来说会比较差不建议使用。
redis分布式锁
基于 Redis 分布式锁实现一个递增的主键 ID这种方式可以保证主键是一个整数且有一定的连续性但分布式锁存在一定的性能消耗。
雪花算法
基于 Twitter 开源的分布式 ID 生产算法——snowflake 解决全局主键 ID 问题snowflake 是通过分别截取时间、机器标识、顺序计数的位数组成一个 long 类型的主键 ID。这种算法可以满足每秒上万个全局 ID 生成不仅性能好而且低延时。
扩容问题
随着用户的订单量增加以 UserId Hash 取模的分表中的数据量也在增加此时需要考虑动态增加表就涉及到了数据迁移问题。
在最开始设计表数据量时尽量使用 2 的倍数来设置表数量。在扩容时也同样按照 2 的倍数来扩容这种方式可以减少数据的迁移量。 有 4 张表分别为 t0,t1,t2,t3UserID的哈希值4、8、12、16则这几个的UserID % 4 0都会存到 t0 表中 假如现在扩容到 8 张表则 UserID为 4 和 12 的被迁移到 t5其他两个不动 假如现在扩容到 6 张表则 UserID为 4 和 8 和 16 的都需要迁移只有UserID为12 的不需要迁移。 双写数据迁移方案介绍
数据迁移前上游业务应用是通过旧的服务访问旧的数据的。
步骤1服务升级双写
首先需要对旧服务升级对旧库的增删改在新库上也同样执行。
步骤2数据迁移
开发一个数据迁移工具负责将旧库中的数据迁移到新库中 到目前为止还是旧库在提供服务所以丝毫不影响我们的业务。
步骤3数据校验
在数据迁移完成之后需要使用数据校验的小工具将旧库和新库中的数据进行比对完全一致则符合预期如果出现不一致的情况则以旧库中的数据为准。
步骤4流量切换
数据完全一致之后将流量切到新库完成平滑数据迁移。
订单分库分表流程图
假如现在有一个订单表没有做分库分表现在呢我们要把订单进行分库分表怎么在不停机的前提下平滑迁移数据到新表呢
按照上面的双写迁移方案流程图如下 当数据比对完全一致后修改服务配置只写入分库分表中间件就可以了。
