当前位置: 首页 > article >正文

分库分表笔记

海量数据的存储与访问会是系统设计与使用的瓶颈,数据往往存储在数据库中,传统的数据库存在着先天的不足,即单机(单库)性能瓶颈,并且扩展起来非常的困难。如果单机数据库易于扩展,数据可切分,就可以避免这些问题,但是当前的这些数据库厂商,包括开源的数据库MySQL在内,提供这些服务都是需要收费的,所以转向一些第三方的软件,使用这些软件做数据的切分,将原本在一台数据库上的数据,分散到多台数据库当中,降低每一个单体数据库的负载。

1 数据库读写分离

随着互联网技术的发展,人们发现在互联网的系统应用是一个读多写少的应用,比如电商系统,商品浏览的次数是比下单要多的。数据库承载压力大,主要是由这些读的请求造成的,那么是不是可以把读操作和写操作分开,让所有读的请求落到专门负责读的数据库上,所有写的操作落到专门负责写的数据库上,写库的数据同步到读库上,这样保证所有的数据修改都可以在读取时,从读库获得。

如果系统的读请求比较多的话,读库可以多部署几台,这样读请求就可以均摊到多台读库上,降低每一个读库上的压力。但是在写数据的时候,数据要落在一个确定,且唯一的写库中。当然可以部署多个写库,但是数据怎么分片是一个十分重要的问题,目前仅以一个写库为例,比如:商户发布商品时,将这个商品的数据落在了写库上,同时,写库将这条数据同步给两个读库,买家在网站浏览商品时,会从读库将这个商品数据读取。至于从哪个读库取出数据,那就要看这个请求在当时的路由情况了。

读写分离带来的好处是很多的,对比一下原始的架构和读写分离的架构,从数据流上看,他们的区别是,数据从写入到数据库,到从数据库取出,读写分离的架构多了一个同步的操作。想一想,同步操作的时间是多少,延迟如果太大对系统有没有影响,如果同步挂了怎么办?这就是读写分离的弊端,当同步挂掉,或者同步延迟比较大时,写库和读库的数据不一致,这个数据的不一致,用户能不能接受,订单支付状态这个不一致当然是不能接受的了,其他的业务场景能不能接受呢?这个要对不同的业务场景做具体的分析了。

一些对数据实时性要求不高的业务场景,可以考虑使用读写分离。但是对数据实时性要求比较高的场景,比如订单支付状态,除非网络延迟应该在 5ms 以内,这个对网络环境要求是非常高的,不然还是不建议采用读写分离的,或者在写程序时,老老实实的从写库去读取数据。

2 数据库数据切分

数据切分,就是通过某种条件,将之前存储在一台数据库上的数据,分散到多台数据库中,从而达到降低单台数据库负载的效果。数据切分,根据其切分的规则,大致分为两种类型,垂直切分和水平切分。

2.1 垂直切分

垂直切分就是按照不同的表切分到不同的数据库中,比如:订单表 order 和商品表 product 原本是在同一个数据库中,现在要对其切分,使得订单表和商品表分别落到不同的物理机中的不同的数据库中,使其完全隔离,从而达到降低数据库负载的效果。

垂直切分的特点就是规则简单,易于实施,可以根据业务模块进行划分,各个业务之间耦合性低,相互影响也较小。
一个架构设计较好的应用系统,其总体功能肯定是有多个不同的功能模块组成的。每一个功能模块对应着数据库里的一系列表。例如商品功能模块对应的表包括:类目、属性、属性值、品牌、商品、sku等表;而在订单模块中,对应的表包括:订单、订单明细、订单收货地址、订单日志等。

在架构设计中,各个功能模块之间的交互越统一、越少越好。系统模块之间的耦合度会很低,各个系统模块的可扩展性、可维护性也会大大提高。这样的系统,实现数据的垂直切分就会很容易。
但是,在实际的系统架构设计中,有一些表很难做到完全的独立,往往存在跨库 join 的现象。比如我们接到了一个需求,要求查询某一个类目产生了多少订单,如果在单体数据库中,我们直接连表查询就可以了。但是现在垂直切分成了两个数据库,跨库连表查询是十分影响性能的,也不推荐这样用,只能通过接口去调取服务,这样系统的复杂度又升高了。对于这种很难做到完全独立的表,作为系统架构设计人员,就要去做平衡,是数据库让步于业务,将这些表放在一个数据库当中?还是拆分成多个数据库,业务之间通过接口来调用呢?在系统初期,数据量比较小,资源也有限,往往会选择放在一个数据库当中。而随着业务的发展,数据量达到了一定的规模,就有必要去进行数据的垂直切分了。而如何进行切分,切分到什么程度,则是对架构师的一个艰难的考验。

垂直切分的优点:

  • 拆分后业务清晰,拆分规则明确;
  • 系统之间容易扩展和整合;
  • 数据维护简单

缺点:

  • 部分业务表无法 join,只能通过接口调用,提升了系统的复杂度;
  • 跨库事务难以处理;
  • 垂直切分后,某些业务数据过于庞大,仍然存在单体性能瓶颈;

2.2 水平切分

水平切分相比垂直切分,更为复杂。它需要将一个表中的数据,根据某种规则拆分到不同的数据库中,例如:订单尾号为奇数的订单放在 订单数据库1 中,而订单尾号为偶数的订单放在 订单数据库2 中。这样,原本存在一个数据库中的订单数据,被水平的切分成了两个数据库。在查询订单数据时,我们还要根据订单的尾号,判断这个订单在 数据库1 中,还是在 数据库2 中,然后将这条 SQL 语句发送到正确的数据库中,查出订单。

水平拆分数据,要先订单拆分的规则,要按哪个维度去拆分,比如按订单尾号的奇偶去拆分,那么这样拆分会有什么影响呢?假如我是一个用户,我下了两个订单,一个订单尾号为奇数,一个订单尾号为偶数,这时,我去个人中心,订单列表页去查看我的订单。那么这个订单列表页要去怎么查,要根据我的 用户id 分别取 订单1库订单2库 去查询出订单,然后再合并成一个列表,是不是很麻烦。所以,咱们在拆分数据时,一定要结合业务,选择出适合当前业务场景的拆分规则。那么按照 用户id 去拆分数据就合理吗?也不一定,比如:身份变了,不是买家了,而是卖家,这个卖家有很多的订单,卖家的后台系统也有订单列表页,那这个订单列表页要怎么样去查?是不是也要在所有的订单库中查一遍,然后再聚合成一个订单列表呀。那这样看,是不是按照 用户id 去拆分订单又不合理了。所以在做数据水平拆分时,是对架构师的真正考验。

水平拆分的优点:

  • 解决了单库大数据、高并发的性能瓶颈;
  • 拆分规则封装好,对应用端几乎透明,开发人员无需关心拆分细节;
  • 提高了系统的稳定性和负载能力;
    缺点:
  • 拆分规则很难抽象;
  • 分片事务一致性难以解决;
  • 二次扩展时,数据迁移、维护难度大。比如:开始我们按照 用户id 对2求模,但是随着业务的增长,2台数据库难以支撑,还是继续拆分成4个数据库,那么这时就需要做数据迁移了。

2.3 总结

无论是垂直切分,还是水平切分,它们解决了海量数据的存储和访问性能问题,但也随之而来的带来了很多新问题,它们的共同缺点有:

  • 分布式的事务问题;
  • 跨库 join 问题;
  • 多数据源的管理问题

针对多数据源的管理问题,主要有两种思路:

  • 客户端模式,在每个应用模块内,配置自己需要的数据源,直接访问数据库,在各模块内完成数据的整合;
  • 中间代理模式,中间代理统一管理所有的数据源,数据库层对开发人员完全透明,开发人员无需关注拆分的细节。

基于这两种模式,目前都有成熟的第三方软件,接下来在我们的视频中,会分别给大家介绍这两种模式的代表作:

  • 中间代理模式:MyCat
  • 客户端模式:sharding-jdbc

http://www.kler.cn/a/6523.html

相关文章:

  • [JAVA备忘录] Lambda 表达式简单介绍
  • 8位移位寄存器的verilog语言
  • Python tkinter写的《电脑装配单》和 Html版 可打印 可导出 excel 文件
  • 「Mac畅玩鸿蒙与硬件45」UI互动应用篇22 - 评分统计工具
  • 解决docker环境下aspose-words转换word成pdf后乱码问题
  • 进网许可认证、交换路由设备检测项目更新25年1月起
  • MVVM理解、object.defineProperty、数据代理
  • Android动态换肤框架实现小结
  • 射频接收机概述
  • PyTorch模型保存方法对比及其实现原理详解
  • 大数据领域的发展及其对现实世界的价值
  • BloombergGPT(LLM大模型用于金融科技)
  • Qt源码阅读(三) 对象树管理
  • java程序中常见的漏洞类型
  • 五 MySQL 存储过程
  • [jetson]pillow 报ImportError: The _imagingft C module is not installed
  • Unity游戏逆向及破解方法介绍
  • BUUCTF-逆向[GXYCTF2019]luck_guy1题解
  • day14—编程题
  • JVM垃圾回收——ZGC垃圾收集器
  • 【算法】树状数组维护总结
  • 计算机底层:循环冗余校验码CRC
  • 实验十八、测量运放的开环差模放大倍数
  • 实验二 配置Trunk和链路汇聚
  • 近世代数 笔记与题型连载 第八章(置换群)
  • Linux之进程替换