mysql架构演变过程

前言

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

mysql的背景

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





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


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


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

mysql架构演变过程

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

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

• 横向：增加数据库节点

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


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

V1.0简单架构

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

瓶颈：
1.数据量，一个机器放不下时
2.数据的索引，放不下
3.访问了（读写混合）承受不了

V2.0 垂直拆分

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

瓶颈：单实例单业务

V3.0主从架构

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

V4.0 水平拆分

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

总结

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