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

电商-数据库分库分表方案 - 努力-

  一、 什么是分库分表


  1.1 当前遇到的问题


  随着订单数据的增加,当MySQL单表存储数据达到一定量时其存储及查询性能会下降,在阿里的《Java 开发手册》中提到MySQL单表行数超过 500 万行或者单表容量超过 2GB时建议进行分库分表,分库分表可以简单理解为原来一个表存储数据现在改为通过多个数据库及多个表去存储,这就相当于原来一台服务器提供服务现在改成多台服务器组成集群共同提供服务,从而增加了服务能力。
这里说的500 万行或单表容量超过 2GB并不是定律,只是根据生产经验而言,为什么MySQL单表当达到一定数量时性能会下降呢?我们知道为了提高表的查询性能会增加索引,MySQL在使用索引时会将索引加入内存,如果数据量非常大内存肯定装不下,此时就会从磁盘去查询索引就会产生很多的磁盘IO,从而影响性能,这些和表的设计及服务器的硬件配置都有关,所以如果当表的数据量达到一定程度并且还在不断的增加就需要考虑进行分库分表了。

  1.2 什么是分库分表


  下边通过一个例子来说明什么是分库分表。
  下边是一个电商系统的数据库,涉及了店铺、商品的相关业务。

FK1-1

 


  随着公司业务快速发展,数据库中的数据量猛增,访问性能也变慢了,如何优化呢?
  我们可以把数据分散在不同的数据库中,使得单一数据库的数据量变小来缓解单一数据库的性能问题,从而达到提升数据库性能的目的,如下图:将电商数据库拆分为若干独立的数据库,并且对于大表也拆分为若干小表,通过这种数据库 拆分的方法来解决数据库的性能问题。

FK1-2

 

  分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题,将原来独立的数据库拆分成若干数据库组成

,将数据大表拆分成若干数据表组成,使得单一数据库、单一数据表的数据量变小,从而达到提升数据库性能的目
的。

  二、 分库分表的方案


分库分表包括分库和分表两个部分,在生产中通常包括:垂直分库、水平分库、垂直分表、水平分表四种方式。

  2.1. 垂直分表


  下图是商品查询列表:

Fenku1-1

 


  用户在浏览商品列表时,只有对某商品感兴趣时才会查看该商品的详细描述。因此,商品信息中商品描述字段访问
  频次较低,且该字段存储占用空间较大,访问单个数据IO时间较长;商品信息中商品名称、商品图片、商品价格等 其他字段数据访问频次较高。
  由于这两种数据的特性不一样,因此考虑将商品信息表拆分如下:
  将访问频次低的商品描述信息单独存放在一张表中,访问频次较高的商品基本信息单独放在一张表中。

Fenku1-2

 


  垂直分表是将一个表按照字段分成多表,每个表存储其中一部分字段,比如按冷热字段进行拆分。

  垂直分表带来的好处是:充分发挥热门数据的操作效率,商品信息的操作的高效率不会被商品描述的低效率所拖累。

  通常我们按以下原则进行垂直拆分:

  把不常用的字段单独放在一张表;
  把text,blob等大字段拆分出来放在附表中;
  经常组合查询的列放在一张表中;


  2. 2 垂直分库


  通过垂直分表性能得到了一定程度的提升,但是还没有达到要求,并且磁盘空间也快不够了,因为数据还是始终限制在一台服务器,库内垂直分表只解决了单一表数据量过大的问题,但没有将表分布到不同的服务器上,因此每个表还是竞争同一个物理机的CPU、内存、网络IO、磁盘。

  经过思考,他把原有的SELLER_DB(卖家库),分为了PRODUCT_DB(商品库)和STORE_DB(店铺库),并把这两个库分 散到不同服务器,如下图:

Fenku1-3

 


  由于商品信息商品描述业务耦合度较高,因此一起被存放在PRODUCT_DB(商品库);而店铺信息相对独立,因此 单独被存放在STORE_DB(店铺库)。

  垂直分库是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念 是专库专用,微服务架构下通常会对数据库进行垂直分为,不同业务数据放在单独的数据库中,比如:客户信息数据库、订单数据库等。

  它带来的提升是:
    1、解决业务层面的耦合,业务清晰
    2、能对不同业务的数据进行分级管理、维护、监控、扩展等
    3、高并发场景下,垂直分库一定程度的提升IO、降低单机硬件资源的瓶颈。

  垂直分库通过将表按业务分类,然后分布在不同数据库,并且可以将这些数据库部署在不同服务器上,从而达到多 个服务器共同分摊压力的效果,但是依然没有解决单表数据量过大的问题。

  2.3. 水平分库


  经过垂直分库后,数据库性能问题得到一定程度的解决,但是随着业务量的增长,PRODUCT_DB(商品库)单库存储数据已经超出预估。粗略估计,目前有8w店铺,每个店铺平均150个不同规格的商品,再算上增长,那商品数量得 往1500w+上预估,并且PRODUCT_DB(商品库)属于访问非常频繁的资源,单台服务器已经无法支撑。此时该如何 优化?

  再次分库?但是从业务角度分析,目前情况已经无法再次垂直分库。

  尝试水平分库,将店铺ID为单数的和店铺ID为双数的商品信息分别放在两个库中。

fenku1-4

 


  也就是说,要操作某条数据,先分析这条数据所属的店铺ID。如果店铺ID为双数,将此操作映射至 RRODUCT_DB1(商品库1);如果店铺ID为单数,将操作映射至RRODUCT_DB2(商品库2)。

  水平分库是把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上,比如:单数订单在db_orders_0数据库,偶数订单在db_orders_1数据库。


  它带来的提升是:
    1、解决了单库大数据,高并发的性能瓶颈。
    2、提高了系统的稳定性及可用性。

  当一个应用难以再细粒度的垂直切分,或切分后数据量行数巨大,存在单库读写、存储性能瓶颈,这时候就需要进 行水平分库了,经过水平切分的优化,往往能解决单库存储量及性能瓶颈。但由于同一个表被分配在不同的数据 库,需要额外进行数据操作的路由工作,因此大大提升了系统复杂度。

  2.4. 水平分表


  按照水平分库的思路把PRODUCT_DB_X(商品库)内的表也可以进行水平拆分,其目的也是为解决单表数据量大 的问题,如下图:

 fenku1-5

 

  与水平分库的思路类似,不过这次操作的目标是表,商品信息及商品描述被分成了两套表。如果商品ID为双数,将 此操作映射至商品信息1表;如果商品ID为单数,将操作映射至商品信息2表。此操作要访问表名称的表达式为商品 信息[商品ID%2 + 1]

  水平分表是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中,比如:0到500万的订单在orders_0数据、500万到1000万的订单在orders_1数据表。

  水平分表优化了单一表数据量过大而产生的性能问题 。

  一般来说,在系统设计阶段就应该根据业务耦合松紧来确定垂直分库,垂直分表方案,在数据量及访问压力不是特 别大的情况,首先考虑缓存、读写分离、索引技术等方案。若数据量极大,且持续增长,再考虑水平分库水平分表 方案。

http://www.jsqmd.com/news/10856/

相关文章:

  • CAD 多个dwg文件合成一张图(无需插件)
  • 2025 年光伏灌注桩厂家推荐:天津宏图新能源发展设备优势与全程服务体系解析
  • 鸿蒙应用开发从入门到实战(十八):组件编程思想之代码复用
  • arm环境vg损坏mysql数据库恢复---惜分飞
  • Atcoder Beginner Contest 422
  • 【Android】解决安卓在隐藏强大的系统栏后usb鼠标被隐藏的疑问
  • RapidJSON 自定义内存分配器详解与实战 - 详解
  • PKC7300高频电流探头在新能源汽车车载充电机稳态电流测试中的应用方案
  • 质量检验知识专题讲座之六:抽样检验步骤
  • 羡慕线段树
  • 质量检验知识专题讲座之七:来料检验
  • windows 10分区教程,win10自带分区教程
  • 决斗(模拟赛题目T3)分析
  • Guidde:AI驱动的视频文档创建工具 - 详解
  • gitlen中,已经提交了内容,如何回退到修改前?
  • HCIP-IoT/H52-111 真题详解(章节C),接入实用的技术和网络设计 /Part1
  • CF1989F
  • 基于UML/MARTE的汽车安全关键系统设计手段
  • Vue3水波纹指令:2025年Material Design交互新标准 - 实践
  • Beyond Compare5最新破解版下载及安装使用教程
  • Why cant developing countries become developed?
  • 22 LCA模拟赛2T1 奶龙与贝利亚 题解
  • AI风险管控新规应对系统抵抗关闭行为
  • 01-Vue3阶段必会的前置知识-01变量和常量
  • 这是我的第一个个人博客
  • BLDC中的Q15
  • 251009
  • MaxProduct
  • 雪落 - L
  • PluginMonitor - Typecho 插件监控工具