有关于存储

此篇就来谈谈数据存储吧！年初的时候进入一家互联网公司实习，刚好做的是分布式存储系统，主要支撑部门中的应用（部门所有的应用都可以承载在上面）数据存储。下面分阶段来聊一聊存储随着应用逐步的发展过程。

目前很多公司都是没有自己的数据库系统，应该说大部分互联网公司都没有，基本都采用了开源的MySQL进行数据存储，在通过MySQL进行存储的过程中，难免会应对性能的挑战，下面根据自己的实践和理解分享下基于MySQL构建存储要经历的几个阶段吧。

0x01

处于这一阶段的应用承载的用户量有限，一般这个时候整个应用的数据存储可以用单点MySQL进行支撑，没有很大的限制。但是随着应用用户量的逐步增长这种设计也存在很多缺陷，对于用户的响应速度会出现非常大延迟的情形，MySQL中出现大量慢查询，响应数据的读取效率。出现种种问题后，需要对存储层进行适当的改良了。

0x02

针对上面出现的慢查询影响整个应用的数据响应速度，可以通过读写分离的方式来降低这个问题，通过水平扩展多个从节点，将应用的读请求导到从库上进行读操作，这样可以大大缓解主节点上面的负载，但是同样会出现问题。

• 主从出现延迟大等问题，使用户的友好体验下降。

• 主从同步过程中对主库造成压力。

上面出现的两种问题主要通过提升机器性能来缓解：

• ssd硬盘

• 提升cpu

• 促使更多的操作在内存中进行操作，减少硬盘的io

0x03

主从分离的方式貌似解决了数据存储过程中慢查询的问题，但是事情往往不会这么简单的被解决了，这时又会出现新的问题。

单一主库会成为性能瓶颈，随着用户量的逐步扩展，对于数据库的读写压力也相应增大，同之前的单点数据存储节点一样，主库也会成为单点问题。在这样的应用背景下我们需要对数据进行垂直分割。

垂直分割

垂直分割一般的分割原则是将不想关的数据放到不同的MySQL数据库实例上，不同的数据库实例上基本上没有交集。比如说：

• 用户信息

• 朋友关系

• 商家信息

这些无关的信息表可以分别存储到不同的MySQL实例上独立对外提供服务，当存在join操作，将一个join操作进行分解，逐步去完成每个实例上对应的操作。

0x04

将不相关的数据拆分存储到不同的MySQL实例上，这确实能够很好的解决某种意义上的单点问题。但是如果某个数据表的记录数很大，应用对这种表进行相应的操作的过程中，会出现数据的查找缓慢，单表数据记录数过大会造成MySQL实例的响应速度过慢。所以在这种背景下一般的处理方式是对单一的数据表进行水平拆分。

水平拆分(sharding)

当一个大表在一定程度上影响到了数据存储的效率的时候，我们可以将这个大表进行水平拆分，将一个表拆成两个三个甚至更多个，这样就不会出现单表过大的问题，过大就对其进行拆分。

总结

一般通过MySQL构建集群，应对大规模数据的挑战可以参考上面所说的步骤来，可能目前很多互联网公司在构建存储的过程也是这样进行的吧！