性能优化之数据库篇5-分库分表与数据迁移

编程之家收集整理的这篇文章主要介绍了性能优化之数据库篇5-分库分表与数据迁移编程之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

一、数据库拆分

1. 为什么要做数据库拆分

单机数据库存在的问题?

从容量、性能、可用性和运维成本上难以满足海量数据的场景。

  1. 性能方面,数据量超过一定阈值,B+树索引慎独增加导致磁盘访问的IO次数增加,进而导致查询性能的下降。
  2. 容量方面,单机能存储的数据量有限
  3. 可用性方面,大量的查询落到单一的数据库节点或者简单的主从架构上,数据库很难承担。
  4. 运维方面,数据量达到一定阈值,主从同步延迟高、增加字段索引、备份这些都会很慢,影响业务系统。

主从结构解决了高可用、读扩展。但是单机容量不变,单机写性能无法解决

为了解决这些问题,我们需要采用分库分表,将数据库拆分开。降低单个节点的写压力,提升整个系统的数据容量上限。

扩展立体方

  • X轴:通过clone整个系统复制,集群
  • Y轴:通过解耦不同功能复制,业务拆分
  • Z轴:通过拆分不同数据扩展,数据分片

2. 垂直拆分

垂直拆分,按照业务纬度分库分表。

垂直拆库

一个数据库,拆分为多个提供不同业务数据处理能力的数据库。如:将一个电商的单独库拆为用户库、订单库、商品库。

垂直拆表

如果单表数据量过大,还需要对单表进行拆分。如:一个200列的订单主表,拆分为十几个子表:订单表、订单详情表、订单收件信息表等。

垂直拆分的优缺点:

优点:

  • 单库(单表)变小,便于管理
  • 性能和容量有提升
  • 拆分后,系统和数据复杂度降低
  • 可以作为微服务改造的基础

缺点:

  • 库变多,管理变复杂
  • 对业务系统有较强的侵入性
  • 改造过程复杂,容易出故障
  • 拆分到一定程度就无法继续拆分

3. 水平拆分

水平拆分就是直接对数据进行分片,有分库和分表两个具体方式。不改变数据本身的结构,只是降低单个节点数据量。这样对业务系统本身的代码来说不需要做特别大的改动,甚至可以基于一些中间件做到透明。

比如把一个10亿条记录的订单的单库单表。按用户id除以32取模,将单库拆分为32个库;再按订单id除以32取模,每个库再拆为32个表。这样就是32*32=1024个表,单个表数据量就只有不到百万条了。

水平分库分表

一般来说我们我们的数据都是有创建时间的,可以按时间拆分,按照年、季度、月、天都可以。

或者根据用户拆分、甚至可以根据一些自定义的复杂的逻辑来拆分。

为什么有时候不建议分表,只建议分库?

因为分表不能解决容量问题,如果瓶颈在IO(磁盘IO、网络IO)上,分表也解决不了,因为分表还是在同一个机器,而分库可以在两个机器上。

分库还是分表,如何选择?

一般情况下,如果数据本身读写压力较大,磁盘IO已经成为瓶颈,那么分库比分表要好。而使用不同的库,可以并行提升整个集群的并行数据处理能力。

相反的情况下,可以尽量考虑分表,降低单表的数据量。

水平分库分表的优缺点:
优点:

  • 解决容量问题
  • 比垂直拆分对系统影响小
  • 部分提升性能和稳定性

缺点:

  • 集群规模大,管理复杂
  • 复杂sql支持问题
  • 数据迁移问题
  • 一致性问题

4. 数据的分类管理

数据的分类管理是指通过对数据进行分类提升数据管理能力。

随着对业务系统、对数据的分析了解发现,很多数据对质量的要求是不一样的。

如订单数据,肯定一致性要求最高,不能丢失。而一些日志数据,中间数据,则没有那么高的一致性。丢了就丢了。

另外,同一张表里的订单数据也可以采用不同策略,无效订单比较多,我们可以定期转移或清除。(一些交易系统里80%以上的是下单后取消的无意义订单,所以可以清理它

如果没有无效订单,也可以考虑:

  1. 最近一周下单但是未支付的订单,被查询和支付的可能性较大。而再以前一点的,可以直接取消掉。
  2. 最近3个月下单的数据,被在线重复查询和系统统计的可能性最大。
  3. 3个月以前-3年以内的数据,查询的可能性小,可以不提供在线查询
  4. 3年以上的数据,可以直接不提供任何方式的查询

这样的话,我们就可以根据分类采用一定的手段去优化系统:

  1. 定义一周内下单但未支付的数据为热数据,同时放到数据库和内存
  2. 定义3个月内的数据为温数据,放到数据库,提供正常的查询操作
  3. 定义3个月到3年的数据为冷数据,从数据库删除,归档到一些便宜的磁盘,用压缩的方式(比如MysqL的tokuDB引擎)存储,用户需要查询的话提工单来查询
  4. 定义3年以上的数据为冰数据,备份到磁带之类的介质上,不提供任何查询操作。

5. 数据库中间件

数据库中间件的技术演进

ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由JDBC、Proxy和Sidecar(规划中)这3款相互独立,又能混合部署配合使用的产品组成。它们均提供数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构、云原生等各种多样化的应用场景。

ShardingSphere-JDBC

框架ShardingSphere-JDBC,可以直接在业务代码使用,支持常见的数据库和JDBC。只适用于Java语言。

使用实例:

二、数据迁移

方案一:全量

  1. 业务系统停机
  2. 数据库迁移,校验一致性
  3. 业务系统升级,接入新数据库

如果新数据库结构一样,可以dump后全量导入。如果是异构的话,需要用程序处理。

方案二:全量+增量

依赖于数据本身的时间戳

  1. 先同步数据到最近的某个时间戳(如前一天)
  2. 然后再发布升级时停机维护
  3. 再同步最后一段时间的变化数据
  4. 最后升级业务系统,接入新数据库

方案三:binlog+全量+增量

  • 通过主库或从库的binlog来解析和重新构造数据,实现复制。
  • 一般需要中间件工具的支持

可以实现多线程,断点续传,全量或增量的数据同步。

继而可以做到:

  1. 实现自定义复杂异构数据结构
  2. 实现自动扩容和缩容,比如分库分表到单库单表、单库单表到分库分表、分4个库到分8个库等等。

下面介绍一个迁移工具:

ShardingSphere-scaling

下载包:https://archive.apache.org/dist/shardingsphere/4.1.0/

总结

以上是编程之家为你收集整理的性能优化之数据库篇5-分库分表与数据迁移全部内容,希望文章能够帮你解决性能优化之数据库篇5-分库分表与数据迁移所遇到的程序开发问题。

如果觉得编程之家网站内容还不错,欢迎将编程之家网站推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您喜欢寻找一群志同道合、互帮互助的学习伙伴,可以点击下方链接加入:
编程之家官方1群
编程之家官方2群
编程之家官方3群
编程之家官方4群

相关文章

猜你在找的Java相关文章

性能优化-数据库篇1 首先我们要谈论什么是性能? 吞吐和延迟 没有量化就没有改进 :监控和度量指标可以指导我们从哪里入手 80/20原则:先优化性能瓶颈的地方 过早的优化是万恶之源:选择合适的优化时机
一、从数据说起 我们再做缓存之前需要把数据先分好类 按变化频率: 静态数据:一般不变的,类似于字典表 准静态数据:变化频率很低,部门结构设置,全国行政区划数据 中间状态数据:一些计算的可复用中间数据,
一、部署kafka集群 启动zookeeper服务: zkServer.sh start 修改配置文件config/server.properties #broker 的全局唯一编号,不能重复 bro
一、数据库拆分 1. 为什么要做数据库拆分 单机数据库存在的问题? 从容量、性能、可用性和运维成本上难以满足海量数据的场景。 性能方面,数据量超过一定阈值,B+树索引慎独增加导致磁盘访问的IO次数增加
一、 Lock 锁 java.util.concurrent.locks.Lock 为什么有了synchronized,还需要Lock呢? 使用方式更灵活 性能开销小 1.1 ReentrantLoc
写在前面 想想为什么要做重构? 如果没有能说出来的理由,建议不要轻易重构。 机票系统A的现状 A系统的背景 业务上:从杭州挪到北京,作为重新孵化项目,想要做大做强。行业竞争压力非常大,做不出成绩,项目
秒杀的本质 业务上:一场促销营销的活动 技术上:一种主动的DDos攻击,具备技术的不确定性和复杂度。 技术上对于秒杀有哪些优化方法呢? 丢弃订单 最早期,量太大扛不住,直接前端随机reject一些请求
专题一:主键ID生成 数据库自增 数据库多主模式 号段模式 UUID 时间戳+随机数 Redis里生成 雪花算法(SnowFlake) 滴滴出品(TinyID) 百度(Uidgenertor) 美团(
微信公众号搜索 “ 程序精选 ” ,选择关注!
微信公众号搜 "程序精选"关注