千万级并发架构下,关系型数据库应该如何优化?

作者:善思者_tin
链接:https://www.jianshu.com/p/c2c081b51ab9

一、概述

顺势而为,大数据高并发要有系统不断的升级,分库分表便是其一。

二、为什么要分库分表

场景:随着互联网技术的蓬勃发展,大数据,高并发是很多公司遇到的情况。比如公司业务的发展,系统用户量迅速增加,系统每天会多 10 万条数据,一个月就多 300 万条数据,单表已经会达到几百万数据量,高峰期请求达到 1000。处理方式是我们在线上部署了几台机器,通过nginx做负载均衡,数据库撑 1000QPS 也还将就。然而,数据量不断在增长,接下来该如何处理呢?

当每天活跃用户数上千万,每天单表新增数据多达 50 万,目前一个表总数据量都已经达到了两三千万了,数据库磁盘容量不断消耗掉,高峰期并发达到惊人的 5000~8000QPS!此时,单个数据库已经抗不住了。

三、分表

3.1、分表的方案

当单表达到几千万的时候,单表数据量太大,会极大影响 sql 执行的性能,到了后面你的 sql 可能就跑的很慢了。一般来说,单表到几百万的时候,性能就会相对差一些了,就得分表了。

根据数值取模

采用Id取模的方式来进行分表。比如那customer表举例,将customer 表根据 cusno 字段切分到4个库中,余数为0的放到第一个库,余数为1的放到第二个库,余数为2的放到第三个库,余数为3的放到第三个库。这样同一个用户的数据会分散到不同的表中,如果查询条件带有cusno字段,则可明确定位到相应表去查询。

实例说明:

首先创建三张表 customer0/ customer1/customer2/customer3, 然后我再创建 uuid表,该表的作用就是提供自增的id。

create table **customer0**(

    id int unsigned primary key ,

    name varchar(32) not null default '',

    pwd varchar(32) not null default ''

)engine=myisam charset utf8;

create table **customer1**(

    id int unsigned primary key ,

    name varchar(32) not null default '',

    pwd varchar(32) not null default ''

)engine=myisam charset utf8;

create table **customer2**(

    id int unsigned primary key ,

    name varchar(32) not null default '',

    pwd varchar(32) not null default ''

)engine=myisam charset utf8;

create table **customer3**(

    id int unsigned primary key ,

    name varchar(32) not null default '',

    pwd varchar(32) not null default ''

)engine=myisam charset utf8;

create table **uuid**(

    id int unsigned primary key auto_increment

)engine=myisam charset utf8;

**利用以上创建的表进行业务处理**

@Service

public class CustomerService {

    @Autowired

     private JdbcTemplate jdbcTemplate;

    /**

     * 注册的代码

     * @param name

     * @param pwd

     * @return

     */


    public String regiter(String name,String pwd){

        //1.生成cusno ,-  先获取到 自定增长ID

        String insertUUidSql = "insert into uuid values(null)";//插入空数据,这里的id是自动增长的

        jdbcTemplate.update(insertUUidSql);//执行

          //查询到最近的添加的主键id

        Long cusno = jdbcTemplate.queryForObject("select last_insert_id()"Long.class);

        //2.存放具体的那张表中 - 也就是判断存储表名称

        String tableName = "customer" + cusno % 3;

        //3.插入到具体的表中去- 注册数据

        String insertUserSql = "INSERT INTO " + tableName + " VALUES ('" + cusno + "','" + name + "','" + pwd + "');";

        System.out.println("insertUserSql:" + insertUserSql);

        jdbcTemplate.update(insertUserSql);

        return "success";

    }

   /**

     * 通过cusno查询name

     * @param userid

     * @return

     */


    public String get(Long cusno) {

        //具体哪张表

        String tableName = "customer" + cusno % 3;

        String sql = "select name from " + tableName + " where id="+cusno;

        System.out.println("SQL:" + sql);

        return jdbcTemplate.queryForObject(sql, String.class);//执行查询出name

    }

}

优缺点总结

优点:

将一个数据表的数据分成多个表后,数据相对比较均匀,减轻来高并发访问带来的数据库压力。

缺点:

后期如果扩容时,需要迁移旧的数据重新计算。

跨分表查询复杂性增加。比如上例中,如果频繁用到的查询条件中不带cusno时,将会导致无法定位数据库,从而需要同时向4个库发起查询,再在内存中合并数据,取最小集返回给应用,分库反而成为拖累。

根据数值范围

为了解决后期集群扩容需要迁移旧数据的问题,可以使用按日期或者ID来进行分表。例如:按日期将不同月甚至是日的数据分散到不同的表中;将cusno为1~9999的记录分到第一个表,10000~20000的分到第二个表,以此类推。某种意义上,某些系统中使用的”冷热数据分离”,将一些使用较少的历史数据迁移到其他库中,业务功能上只提供热点数据的查询,也是类似的实践。

优缺点

优点:

单表大小可控

天然便于水平扩展,后期如果想对整个分片集群扩容时,只需要添加节点即可,无需对其他分片的数据进行迁移

使用分片字段进行范围查找时,连续分片可快速定位分片进行快速查询,有效避免跨分片查询的问题。微信搜索公众号:Linux技术迷,回复:linux 领取资料 。

缺点:

热点数据成为性能瓶颈。连续分片可能存在数据热点,例如按时间字段分片,有些分片存储最近时间段内的数据,可能会被频繁的读写,而有些分片存储的历史数据,则很少被查询。

四、分库

就是你一个库一般最多支撑到并发 2000,随着查询量的增加单台数据库服务器已经没办法支撑,而且一个健康的单库并发值你最好保持在每秒 1000 左右,不要太大,太大会导致单台DB的存储空间不够。那么你就可以将一个库的数据拆分到多个库中,访问的时候就访问一个库好了。

垂直拆分

垂直拆分意思就是处理数据库的列,列和对应的业务有关系,意思就是就是根据业务耦合性,将关联度低的不同表存储在不同的数据库。

联想到微服务,做法与大系统拆分为多个小系统类似,按业务分类进行独立划分,每个微服务使用单独的一个数据库。比如最初就一个数据库为db_shop,db_shop库包含user,product表,随着公司业务的发展,技术团队人员也得到了扩张,划分为不同的技术小组,不同的小组负责不同的业务模块。例如A小组负责用户模块,B小组负责产品模块,拆分为db_user库和db_product库

需要解决的问题:跨数据库的事务、jion查询等问题。

水平拆分

按照规则划分,一般水平分库是在垂直分库之后的。比如每天处理的订单数量是海量的,可以按照一定的规则水平划分。比如某张表太大,单个数据库存储不下或访问性能有压力,把一张表拆成多张,每张表存放部分记录,保存在不同的数据库里,水平分库需要对系统做大的改造。

1)Scale up,升级数据库所在的物理机,提升内存/存储/IO性能,但这种升级费用昂贵,并且只能满足短期需要。

2)Scale out,把订单库拆分为多个库,分散到多台机器进行存储和访问,这种做法支持水平扩展,可以满足长远需要。

订单库主要包括订单主表/订单明细表(记录商品明细)/订单扩展表,水平分库即把这3张表的记录分到多个数据库中,订单水平分库效果如下图所示:

千万级并发架构下,关系型数据库应该如何优化?

分库策略:和水平分表类似

分库维度确定后,如何把记录分到各个库里呢?一般有两种方式:

根据数值范围,比如用户Id为1-9999的记录分到第一个库,10000-20000的分到第二个库,以此类推。

根据数值取模,比如用户Id mod n,余数为0的记录放到第一个库,余数为1的放到第二个库,以此类推。

需要解决的问题:数据路由、组装。

读写分离

对于时效性不高的数据,可以通过读写分离缓解数据库压力。

需要解决的问题:在业务上区分哪些业务上是允许一定时间延迟的,以及数据同步问题。

垂直分库–>水平分库–>读写分离

五、拆分后面临新的问题的解决方案

常用的解决方案:站在巨人的肩膀上能省力很多,目前分库分表已经有一些较为成熟的开源解决方案。

选用第三方的数据库中间件(Atlas,Mycat,TDDL,DRDS),同时业务系统需要配合数据存储的升级。综合考虑,现在其实建议考量的,就是 Sharding-jdbc 和 Mycat,这两个都可以去考虑使用。

Sharding-jdbc 这种 client 层方案的优点在于不用部署,运维成本低,不需要代理层的二次转发请求,性能很高,但是如果遇到升级啥的需要各个系统都重新升级版本再发布,各个系统都需要耦合 Sharding-jdbc 的依赖;

Mycat 这种 proxy 层方案的缺点在于需要部署,自己运维一套中间件,运维成本高,但是好处在于对于各个项目是透明的,如果遇到升级之类的都是自己中间件那里搞就行了。

通常来说,这两个方案其实都可以选用,但是我个人建议中小型公司选用 Sharding-jdbc,client 层方案轻便,而且维护成本低,不需要额外增派人手,而且中小型公司系统复杂度会低一些,项目也没那么多;但是中大型公司最好还是选用 Mycat 这类 proxy 层方案,因为可能大公司系统和项目非常多,团队很大,人员充足,那么最好是专门弄个人来研究和维护 Mycat,然后大量项目直接透明使用即可。

附:

负载均衡:汽车超载,多台汽车运送物质。有个总调度中心,分配每辆车的权重,分别拉多少货物。在系统里面,这个总调度中心可以是nginx,通过配置多台服务器的ip,进行权重分配,使用轮询算法,实现应对并发量大的策略。

主键生成策略:

千万级并发架构下,关系型数据库应该如何优化?

--完--

读到这里说明你喜欢本公众号的文章,欢迎 置顶(标星)本公众号 架构师指南,这样就可以第一时间获取推送了~

本公众号 架构师指南,后台回复:架构师,领取2T学习资料 !
1. 后端架构师技术大全(69个点)
2. 架构师如何设计权限系统?
3. 我怎么才能成为一个架构师 ?
4. 架构师从0搭建一套订单系统!

千万级并发架构下,关系型数据库应该如何优化?

千万级并发架构下,关系型数据库应该如何优化?

本篇文章来源于微信公众号:程序IT圈

原创文章,作者:software,如若转载,请注明出处:https://www.sldh123.com/6454.html

(0)
上一篇 11月 13, 2022 1:29 下午
下一篇 11月 13, 2022 1:29 下午

相关推荐

  • 12306抢票:极限高并发带来的思考

    每到节假日期间,一二线城市返乡、外出游玩的人们几乎都面临着一个问题:抢火车票!虽然现在大多数情况下都能订到票,但是放票瞬间即无票的场景,相信大家都深有体会。尤其是春节期间,大家不仅…

    7月 1, 2022
    300
  • 架构概述之架构演化、模式与核心要素

    如何打造一个高可用、高性能、易扩展、可伸缩且安全的应用系统?相信这是困扰着无数开发者的难题,在这里我们以一个网站为例,来讨论一下如何做好大型应用系统的架构设计。 架构演化发展历程 …

    9月 25, 2022
    180
  • 架构师细谈八种架构设计模式及其优缺点

    什么是架构 我想这个问题,十个人回答得有十一个答案,因为另外的那一个是大家妥协的结果。哈哈,我理解,架构就是骨架,如下图所示: 人类的身体的支撑是主要由骨架来承担的,然后是其上的肌…

    8月 3, 2022
    200
  • 程序员不得不知道的 API 接口常识

    作者: 胡涂阿菌 链接:https://www.cnblogs.com/tanshaoshenghao/p/16215751.html 说实话,我非常希望自己能早点看到本…

    10月 1, 2022
    390
  • MySQL架构演进:从主从复制到分库分表

    背景 业务飞速发展导致数据规模急速膨胀,单机的数据库已经无法满足互联网业务的发展。 传统的将数据集中存储单一数据结节的方案,在容量、性能、可用性和可维护性方面已经难以满足互联网海量…

    10月 20, 2022
    290
  • 计算机架构设计的8个伟大思想

    来源:书籍《计算机组成与设计》硬件/软件接口 “These are eight great ideas that computer architects have invented…

    9月 29, 2022
    240
  • 后端架构师技术大全(69个点)

    工欲善其事,必先利其器;士欲宣其义,必先读其书。后台开发作为互联网技术领域的掌上明珠,一直都是开发者们的追逐的高峰。本文将从后台开发所涉及到的技术术语出发,基于系统开发、架构设计、…

    11月 8, 2022
    340
  • 架构师必须了解的微服务和技术栈

    一、简介         这些年软件的设计规模越来越庞大,业务需求也越来越复杂,针对系统的性能、高吞…

    6月 28, 2022
    260
  • 超1.5万台Kafka,每秒数亿消息量的挑战

    因公众号更改推送规则,请点“在看”并加“星标”第一时间获取精彩技术分享 Kafka在美团数据平台承担着统一的数据缓存和分发的角色,随着数据量的增长,集群规模的扩大,Kafka面临的…

    10月 27, 2022
    220
  • 架构师带你彻底搞懂Nginx的五大应用场景

    HTTP服务器 Nginx本身也是一个静态资源的服务器,当只有静态资源的时候,就可以使用Nginx来做服务器,如果一个网站只是静态页面的话,那么就可以通过这种方式来实现部署。 1、…

    7月 11, 2022
    170

发表回复

您的电子邮箱地址不会被公开。