存储计算分离

在20年前就有NAS-网络附加存储这个东西，本质上也就是使用TCP/IP协议的以太网文件服务器。当时如果想要大规模的存储，就会让服务器将数据保存到NAS这个上面，但是NAS价格及其昂贵，并且扩展比较困难，NAS也就不适用于高速发展的互联网应用。
这个时候谷歌摒弃了之前的观念“移动存储到计算”，采取了“移动计算到存储的观念”，将计算和存储耦合了，因为当时的网络速度对比现在来说慢了几百倍，网络速度跟不上我们的需要。在在典型的MapReduce部署中计算和存储都在同一个集群中进行，比如后续的hadoop。这里其实也就是用本地IO速度来替换网络传输速度。

我们的网络速度也越来越快，我们的瓶颈不再是网络速度，但是我们的磁盘I/O速度却没有明显的速度增长，计算和存储融合的架构缺点也再逐渐暴露：

机器的浪费：业务是计算先达到瓶颈的，还是存储先达到瓶颈的。这两种情况往往是不一样的，往往时间点也是不一样的。在架构里就存在一定的浪费。如果说计算不够，也是加一台机器；存储不够，还是加一台机器。所以这里就会存在很多浪费。
机器配比需要频繁更新：一般来说在一个公司内机器的配型比较固定比如提供好几种多少核，多少内存，多少存储空间等等。但是由于业务在不断的发展，那么我们的机器配型也需要不断的更新。
扩展不容易：如果我们存储不够了通常需要扩展，计算和存储耦合的模式下如果扩展就需要存在迁移大量数据。

由于计算和存储耦合的缺点越来越多，并且网络速度越来越快，现在架构又在重新向计算和存储分离这一方向重新开始发展。

在Mysql的主从架构中有很多问题：

主库的写入压力比较大的时候，主从复制的延迟会变得比较高，由于我们其复制的是binlog，他会走完所有的事务。
增加从节点速度慢，由于我们需要将数据全量的复制到从节点，如果主节点此时存量的数据已经很多，那么扩展一个从节点速度就会很慢高。
对于数据量比较大的数据库，备份的速度很慢。
成本变高，如果我们的数据库的容量比较大，那么我们相应的所有从节点的容量都需要和猪数据库一样大,我们的成本将会随着我们所需要从数据库的数量进行线性增加。

这一切的问题好像都在指引着我们走向计算和存储分离的道路，让所有的节点都共享一个存储。在2014年，在AWS大会上，AWS就宣布推出Aurora。这是一个面向亚马逊关系数据库服务（RDS）的兼容MySQL的数据库引擎，Aurora完美契合了企业级数据库系统对高可用性、性能和扩展性、云服务托管的需求。目前的Aurora可跨3个可用区的6-路复制、30秒内便可完成故障转移、同时具备快速的crash recovery能力。在性能方面，Aurora现在比RDS MySQL5.6和5.7版本快5倍。

Aurora将MySQL存储层变为为独立的存储节点,在Aurora中认为日志即数据，将日志彻底从Mysql计算节点中抽离出来，都由存储节点进行保存，并且也取消了undolog用于减小计算存储之间的交互和传输数据带宽。
同样的在阿里的团队中，也借鉴了Aurora的思想，并在其上面做了很多优化，由于Aurora对于Mysql-Innodb的存储引擎修改较大，后续的Mysql的更新，必然成本很大，所以阿里的团队在保有了原有的MySQL IO路径的基础之上推出了PolarDB。

https://juejin.cn/post/6844904055840440333

https://juicefs.com/blog/cn/posts/why-disaggregated-compute-and-storage-is-future/

https://cloud.tencent.com/developer/article/1619383

https://promotion.aliyun.com/ntms/act/emractivity02.html

https://help.aliyun.com/document_detail/149748.html

实现方案
透明集成 ChubaoFS
为了实现 ChbuaoFS 对用户的透明，ChubaoFS 就需要作为 Kubernetes 可以自动识别的远程分布式存储服务存在，因此 ChubaoFS 实现了 kuberne 的 CSI（Container Storage Interface）, 从而实现与 kubernetes 的无缝集成和基于 POD 的动态挂载。

存储共享
在使用 ChubaoFS 时，申请的每个 Volume 的大小是配额记录信息，不会预先分配资源，也不会以此来限制用户使用的存储上限。比如：ChubaoFS 总体的存储空间是 1TB，有十个数据库实例去申请 ChubaoFS 的空间，每个数据库实例申请的 PV（persistent volumes）的大小都可以是 1TB，只要十个数据库实例实际使用的磁盘之和不超过 1TB 即可。而实际每个用户使用的磁盘空间的大小，由 ChubaoFS 的资源管理节点进行统一监控，一旦总体使用磁盘容量超过总容量的 80%，ChubaoFS 资源管理节点会第一时间监控到，并进行报警。

感谢 ChubaoFS 共享磁盘的设计，disca 可以为每个数据库实例申请比较大的磁盘（默认：2TB），而不用担心浪费或者超过集群总容量。从而可以减少数据库实例因为磁盘空间不足而不得不进行拆分或者扩容的情况

https://www.infoq.cn/article/w40u6t2frpbrep44mow0