mysql架构演变过程

前言

我们小组研究的是mysql,今天由小帅给大家分享我们组的研究成功,我没有做什么突出贡献,主要的技术点都是小帅没日没夜研究的,我也就帮忙做了个背景介绍,今天先总结一下mysql的架构之路,明天我也好好的研究一下主从复制什么的,争取在贡献一篇博客给大家参考~~~

mysql的背景

MySQL是由原MySQL AB公司自主研发的,是目前IT行业最流行的开放源代码的数据库管理系统,同时它也是一个支持多线程高并发多用户的关系型数据库管理系统。


mysql架构演变过程_第1张图片


其实这三点也是mysql数据库在发展过程中一直追求的三项原则,我们一一来看,第一项是简单,首先他的安装文件特别的小,打开安装文件直接下一步就能成功,建立数据库的过程也非常简单,一般的sql语句都可以搞定,所以说他操作起来非常简单,不像一般大型商业数据库管理系统(Oracle,DB2等等),安装包动辄都跟个操作系统那么大似的


第二点可靠性,根据权威的第三方评测机构多次测试各种数据库的TPCC值,MySQL一直都有非常优异的表现,而且在其他所有商用的通用数据库管理系统中,仅仅有Oracle数据库能够与其一较高下


第三点高效,mysql一直奉行的一个原则就是保证足够稳定的前提下,性能的地位是在功能之前的,也就是说他的第一考虑要素是性能,在满足客户的99%的需求下,剩余的精力用来提高系统的性能

mysql架构演变过程

为什么会有架构的演变过程?一般是一种架构在使用过程中,会遇到瓶颈,这时候我们就需要对数据库进行扩展,让他能承受更多的数据,所以不同的扩展就有了不同的数据库架构,扩展分为纵向和横向两种方式:

  • 纵向:换机器和资源,实现伸缩,提高服务能力

  • 横向:增加数据库节点

如果公司有经济实力,完全可以买处理能力更高的服务器,多买一些,来解决瓶颈问题,但是这样不适合大部分的公司,小公司还是通过更牛的技术实现更多数据量的访问,这就是我们所说的横向增加节点,这才是这一领域解决问题的王道


接下来我们就来看一下,mysql架构是如何一步步进化打怪的~

V1.0简单架构

mysql架构演变过程_第2张图片


简单小型网站或者应用背后的架构可以非常简单,数据存储只需要一个mysql instance,一般会把所有的信息存到一个database instance里面

瓶颈:
1.数据量,一个机器放不下时
2.数据的索引,放不下
3.访问了(读写混合)承受不了

V2.0 垂直拆分

mysql架构演变过程_第3张图片


什么是垂直?就是从业务角度来看,将关联性不强的数据拆分到不同的instance上,从而达到消除瓶颈
例子:将用户信息数据和业务数据拆分到不同的三个实例上,对于重复读类型比较多的场景,我们还可以加一层cache来减少对DB的压力

瓶颈:单实例单业务

V3.0主从架构

mysql架构演变过程_第4张图片


解决v2.0架构下的读问题,通过给Instance挂数据实时备份的思路来迁移读取的压力,在Mysql的场景下就是通过主从结构,主库抗写压力,通过从库来分担读多的压力

V4.0 水平拆分

mysql架构演变过程_第5张图片


对于V2.0 V3.0方案遇到瓶颈时,都可以通过水平拆分来解决,水平拆分和垂直拆分有较大区别,垂直拆分拆完的结果,在一个实例上是拥有全量数据的,而水平拆分之后,任何实例都只有全量的1/n的数据,以下图Userinfo的拆分为例,将userinfo拆分为3个cluster,每个cluster持有总量的1/3数据,3个cluster数据的总和等于一份完整数据(注:这里不再叫单个实例 而是叫一个cluster 代表包含主从的一个小mysql集群)

总结

今天小帅说的一句话印象深刻,他说什么问题都可以通过第四种架构解决,其实这种思想很简单,最开始是一个数据库,如果业务逻辑非常复杂,那么就多加几个数据库,就像我们的ITOO,评教自己一个库,新生自己一个库,自己负责自己的就好了,如果评教自己的这个库压力过大,那么就先建立主从数据库,缓解一下压力,还是有瓶颈,就把一个实例的数据库搭建成集群,每一个服务器上分担一部分数据,每一个集群上都是一个主从的数据库,这样就可以完美解决数据库瓶颈的问题了

你可能感兴趣的:(-----,【MySql】)