分布式之存储高性能

本文探讨了提高存储性能的几种分布式策略,包括读写分离、分库分表、全文搜索引擎、列式数据库和文档数据库的使用。读写分离通过减少主库压力,分库分表解决数据量大带来的性能问题,全文搜索引擎如ES提高搜索效率,列式数据库如Hbase用于统计,文档数据库如MongoDB允许动态结构,分布式缓存如Redis应对高并发读取。各种方案针对不同场景,如电商系统中的商品、订单和用户数据模块,需要根据业务需求灵活选择。

前言

  • 存储高性能的概念
    • 存储
      • 存储主要指的是数据库。
    • 高性能
      • 高性能主要指的是数据库的高性能[写数据的性能;读取数据的性能]。

一、读写分离


  • 概念

    • 读写分离其实是将数据的读和写分开存储,并且使用同步工具从写库往读库同步数据;如图:
      在这里插入图片描述
  • 前提

    • 操作系统是独立的;主库与从库是部署在不同的主机上的。
  • 读写分离的缺陷

    • 缺陷
      • 数据库压力过大,导致数据读写性能下降。
        • 局限
          • 数据磁盘容量有限。
        • 解决方案
          • 降低数据库的压力
            • 使用分库分表。
      • 数据同步[写—同步—>读]有时间上的延迟,造成无法实时查询数据。
        • 解决方案
          • 直接读写库 【不推荐】;如图:
            在这里插入图片描述

            • 缺陷
              • 业务代码入侵大,造成代码不稳定。
            • 使用场景
              • 数据一致性比较强,使用该方案。
          • 先读从然后读取主库

            • 数据写入主库后,查询从库如果没有查询到写入的数据,再去读取主库即可;如图:
              在这里插入图片描述

            • 优势

              • 可以解决业务代码入侵大的问题 [查询添加数据根据数据的ID查询]。
            • 缺陷

              • 主库的并发压力大。
            • 使用场景

              • 数据一致性比较强,使用该方案。
          • 使用互斥锁

            • 直接从读库[从库]中读取数据
  • 场景总结 [CAP定理]

    • 电商系统,商品数据模块【使用读写分离即可,一致性不需要太强】
    • 电商系统,订单数据模块【使用读写分离,读取主库;一致性比较强】
    • 电商系统,用户数据模块【使用读写分离,读取主库;一致性比较强】
    • 电商系统,商品评价模块【使用读写分离,一致性不需要太强】
      根据系统发特点选择读写分离的方案。
    • 读写分离是为解决系统高并发查询的问题。

二、分库分表


  • 分库

    • 分库是为了解决数据库的压力[磁盘容量有限],将一个数据库分成多个库来存储数据来缓解数据库的压力;如图:
      在这里插入图片描述
  • 分表

    • 分表是为了解决表数据量过大造成的性能下降的问题,将一个表分成多个表来存储不同的数据叫分表;如图:
      在这里插入图片描述
  • 读写分写+分库分表

    • 解决数据量与并发量大的问题[先分库分表在读写分离];如图:
      在这里插入图片描述

    • 场景

      • 以京东商城为例:
        • 商城的商品数据适合:分库分表+读写分离
        • 商城的订单数据适合:分库分表+读写分离
        • 商城的优惠券适合:分表+读写分离
    • 实现思路

      • 分布式系统
        • 根据数据量与并发量的大小选择分库分表和读写分离。
      • 单体系统
        • 通过代码和配置实现。
  • 业务分库

    • 业务分库就是将不同的业务拆分出来分成不同的数据库叫做业务分库,以电商系统为例,如图:
      在这里插入图片描述

    • 场景

      • 微服务系统的设计。
    • 前提

      • 分布式系统。
      • 业务之间存在资源竞争的问题。
    • 缺陷

      • 数据库变多,公司的成本变大。

三、全文搜索引擎


  • 方案
    • 使用关系型数据库分库分表+读写分离的方式实现搜索 [不推荐];如图:
      在这里插入图片描述

      • 缺陷
        • 关系型数据库只能使用like[模糊查询]全局扫描查询到数据,如果数据量过大,性能会很低。
    • 使用NoSql数据库 [ES] [推荐]
      当系统将数据写入到关系型数据库,数据写入成功后,再将数据同步到ES数据库中,当用户搜索数据时,系统直接到ES中查找数据,这样性能就可以得到提升;如图:
      在这里插入图片描述

      • 同步工具
        • Mysql
          • canal
        • 其他数据库
          • DataX
      • 缺陷
        • 关系型数据库往ES同步数据的时候存在数据延迟的问题,系统有可能搜索不到数据。

四、列式数据库


  • 场景
    • 统计数据
  • 方案
    • 使用关系型数据库[数据量大,不推荐]
      • 使用行式数据库等进行统计。
        • 缺陷
          • 行式数据库遍历数据库数据的每一行,性能低。
      • 使用列式数据库统计
        • 工具Hbase,如图:
          在这里插入图片描述

五、文档数据库


  • 场景
    • 商品数据表的结构固定,业务模型的结构也固定了,当用户提出新增加一个属性,这是表结构和业务模型都会发生改变,同时导致客户端也发生了改变,这样违背开闭原则。
  • 方案
    • 使用MongoDB数据库动态更改表的数据结构,如图:
      在这里插入图片描述

六、分布式缓存


  • 场景
    • 当并发量变大,读取数据的时候,关系型数据库已经满足不了并发量大带来的性能低的问题,就应该使用分布式缓存[使用Redis];如图:
      在这里插入图片描述
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值