什么是数据库“存算分离”架构？

    今天的话题要从一个朋友的咨询开始

    所以准备写一篇短文谈谈我对“存算分离”架构的理解，不一定全面，欢迎在评论区探讨。

    其实这个朋友是误解了“存算分离”这个概念。他认为普通MySQL云数据库用evs做存储，计算资源和存储资源是分开的，比如可以单独扩容计算资源或单独扩容存储资源，所以就是存算分离的架构，其实这么理解是片面的。要理解“存算分离”架构，还得追根溯源，从传统MySQL主备架构说起。

    这张图熟悉MySQL的人应该都见过，我们知道，MySQL的master端有数据变更时，备机是通过读取和回放binlog，涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在备节点，三个线程配合完成数据复制的工作。但是，不难发现，这个架构在某些场景会有明显的缺陷：

1. 主库写入压力大时。当主库的写入压力比较大的时候，主备复制的时延会变大，因为需要回放完所有binlog的事务才会完全达到数据同步。

2. 增加只读节点时。增加备机/只读节点的速度很慢，因为我们需要将数据全量的复制到从节点，如果主节点此时存量的数据已经很多，那么扩展一个备机节点速度就会很慢高。

3. 使用多个只读节点时。存储的成本线性增长，如果数据库磁盘空间比较大，那么相应的所有只读节点挂载的磁盘空间都需要和主节点一样大，成本将会随着只读库数量增加进行线性增加。

    这些问题通过存算分离架构就能得到很好的解决，以华为云GaussDB（for MySQL）为例，作为华为自研的最新一代高性能企业级分布式数据库，基于华为最新一代DFV分布式存储，采用计算存储分离架构，最高支持128TB的海量存储，可实现超百万级QPS吞吐。

    首先，GaussDB（for MySQL）采用计算与存储解耦的技术架构，让所有的节点都共享一个存储，也就是说，增加计算节点时，无需调整存储资源，真正做到计算与存储分离，并且可支持 15 个只读节点的扩展，主节点和只读节点之间是 Active-Active 的 Failover 方式，计算节点资源得到充分利用，由于使用共享存储，降低了用户使用成本。完美契合了企业级数据库系统对高可用性、性能和扩展性、云服务托管的需求。GaussDB（for MySQL）将MySQL存储层变为独立的存储节点，在GaussDB（for MySQL）中认为日志即数据，将日志彻底从MySQL计算节点中抽离出来，都由存储节点进行保存，与传统 RDS for MySQL 相比，不再需要刷 page，所有更新操作都记录日志，不再需要 double write，从而大大减少了网络通信。

    小结一下，以“存算分离”架构来答复一下上面的3个问题：

    1. 当主库的写入压力比较大的时候，由于不再有double write入，主节点和只读节点之间的复制时延基本得以消除。

    2. 增加只读节点的速度非常快，因为不再需要将数据全量的复制到只读节点，无论多大数据量，只需 5 分钟左右即可完成增加只读节点。

    3. 使用多个只读节点时，因为只有一份存储，所以存储的成本不会有变化，存储空间越大，只读节点越多，节省成本越明显。