性能优化之数据库篇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-分库分表与数据迁移所遇到的程序开发问题。

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

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
喜欢与人分享编程技术与工作经验,欢迎加入编程之家官方交流群!

猜你在找的Java相关文章

前言 日常开发中,难免会遇到需要查询到数据库所有记录的业务场景,在索引完善的情况下,当数据量达到百万级别或者以上的时候,全表查询就需要耗费不少的时间,这时候我们可以从以下几个方向着手优化 优化sql
【设计模式】汉堡中的设计模式——观察者模式 情景带入 对于爱吃麦当劳的我来说,自然是不想错过各种动态,可是我又不可能【无时无刻】的蹲在店里等新品吧(还是要搬砖的) 那么有没有一种好的方法,在麦当劳【推
一、前提知识: http协议规定一次请求对应一次响应,根据不同的请求方式,请求的内容会有所不同; 发送GET请求是没有请求体的,参数会直接拼接保留到url后一并发送; 而POST请求是带有请求体的,带
关于Java中的重载与重写,每一个java人肯定都学习过,这里就再梳理一遍,加深一下印象,忘记的时候拿出来看一看就好了 重载与重写的区别 重载发生在同一个类里面,同一个方法,拥有不同的参数列表,不同的
1、正常创建一个List,对List进行操作 List<Integer> collect = Stream.of(1 ,3 ,5 ,7 ,9).collect(Collectors.toL
我发现,自从我学了Stream流式操作之后,工作中使用到的频率还是挺高的,因为stream配合着lambda表达式或者双冒号(::)使用真的是优雅到了极致!今天就简单分(搬)享(运)一下我对strea
性能优化-数据库篇1 首先我们要谈论什么是性能? 吞吐和延迟 没有量化就没有改进 :监控和度量指标可以指导我们从哪里入手 80/20原则:先优化性能瓶颈的地方 过早的优化是万恶之源:选择合适的优化时机
一、从数据说起 我们再做缓存之前需要把数据先分好类 按变化频率: 静态数据:一般不变的,类似于字典表 准静态数据:变化频率很低,部门结构设置,全国行政区划数据 中间状态数据:一些计算的可复用中间数据,
微信公众号搜索 “ 程序精选 ” ,选择关注!
微信公众号搜 "程序精选"关注