背景
在目前 Rocksdb 系的分布式存储架构下，我们需要引申出一种更 高性能 ，低成本 和 高可扩展性 的架构设计，从而实现降本增效的目的。目前发展的主要方向集中在 存算分离 的上。所以本次调研也围绕着分布式数据库存算分离概念和其方案进行调研。
什么是存算分离
起源
我们先回顾一下我们常用的 mysql 的单体顶层部署架构。
部署架构还是很简单，单体程序直接部署，文件和实例同在一个机器上，这样最符合我们对数据拿取写入的认知，但是这样同时也依赖实例所处的环境，包括 CPU , 内存，disk ...etc。后来我们进入了高带宽时代，高带宽催生了微服务架构，进而催生了容器技术，然后容器技术有衍生出容器编排...到现在的云原生技术，这似乎都在将之前的架构肢解，也就是哪里不够加哪里～数据库是不是也是这样？那么就说到了今天的主角--存算分离。
最早存算分离起源于谷歌 GFS 的一个观念的思考 ："移动计算到数据的观念"，它带来新的计算和存储耦合方式。基于此人们发现计算和存储融合的架构出现了机器资源浪费：
- 性能评估不准确：计算和存储对机器的性能诉求不同，在计算和存储耦合系统中，我们很难在存储负载和计算负载之间达成比较好的平衡，任意一个能力在其性能曲线顶点都将影响其他能力，导致系统能力瓶颈；
- 成本高：如果任意一侧能力出现瓶颈，一般来说的处置方法是加机器，那么造成的冗余将会使成本变高；
- 可扩展性差：计算和存储耦合模式下，计算扩展通常迁移大量数据；并且上层通用能力不足，为实现其他协议或者特定功能都将改写存储逻辑。
根据以上介绍我们知道存储和计算的边界是可以清晰的，存储就像是一台主机中落盘的持久化数据，计算是计算过程中需要的的 CPU 和内存。由于今天的带宽越来越大已为两者的分离做好了充足的条件，所以将单机节点作为分布式存储组件的道路变得越来越现实。换而言之，单机节点完全可以承担 CPU ，内存或者磁盘的角色，那时无论是对计算侧还是存储侧性能都是质的提升。
存算分离架构的好处
根据我们的设想，我们把计算层和存储层抽象剥离，并让每个存储节点都有分布式协调的能力，我们将得到了如下架构：
这也是存算分离的基础架构方式，通过解耦计算和存储负载，系统负载均衡调度会更加灵活，更加的健壮，计算可以认为是无状态的，同时计算本身是比较复杂的，这也意味着存在出问题的概率比较高，一般而言，存储的逻辑比较简单，因此出现问题的概率也比较小，这种架构下，如果计算层出现问题，可以很方面的进行故障恢复，另外就是系统的弹性比较好，计算层可以无感扩缩容，使系统的资源利用率提高了，节约成本；虽然存储层扩容是有状态的，但是扩容或者故障都可以通过 raft paxos zab 等共识算法进行数据的再分配或者角色的再分配，又在此基础上我们又引入优化的 Multi Raft ，Multi paxos 等等解决了一致性的问题。
存算分离的进阶演化
我们已经有如上架构了，那还能怎么玩呢？ 我们从架构图中不难发现，存储集群被单独抽象成为存储层，那么在这个抽象上我们可以提供统一接口做一个存储池，将原本的存储层和文件系统一起降沉到抽象存储层中，上游可以承接各类计算层的请求，代表产品 GaussDB(for xxx) 。在现在 kv 引擎能提供给我们大部分通用存储能力，这也为抽象做了很好的铺垫。计算层自己提供丰富扩展，可以是 redis ，mysql 等等。
在这种分离架构里，只要解决文件存储问题，其实能解决了一大部分之前 mysql 遇到的问题，如果下游共享存储层是类似分布式文件系统的结构 ，我们就可以把分离架构里的存储层摊薄，将计算和存储层重新规划在一起，新的存储层称为计算存储层，负责对分布式文件存储（共享文件存储）进行调用。这需要在原来 RDS 计算层基础上增加一些分布式能力，例如：通过 proxy 区分只读只写节点，，这种能力很容易从 RDS 上扩展开来。代表产品 PolarDB（RDS），Rocksdb Secondary instances，clickhouse。由于扩展了分布式文件存储，所以使得系统逐渐有了为 OLAP 提供存算分离的能力。
还有一种玩法是对之前存算分离改动较小的，就是只改存储层，这里存储层访问的路径是分布式文件存储的所在路径，理论上应该是存储层无感知的，由架构控制读写等操作，有点和上一个玩法类似，这样部署的好处就在于：文件对于一个 group 的所有节点都是共享的，也就意味着，在存储层视角数据只有 1 份，在分布式文件存储中数据副本个数是人为设定的最大数和上层存储系统无关，比如分布式存储设定 3 备份，那么实际上就是 3 份数据，存储层所有节点文件路径指向这个分布式文件的地址，这样考虑是因为：大多数主从协调发生的原因都不是数据损坏，所以过分的冗余备份工作让成本更高，所以现在备份不再跟着实例数走，可能你有 100 个节点，但是都是在分布式文件系统中共享 6 份数据，这就极大的降低了存储成本。代表产品：bookkeeper，greenplum，doris，VictoriaMetrics 以及各种扩展了冷数据能力的数据库。
时至今日存储层又被提出了新的要求，它们都有向池化，数据湖的倾向发展的趋势，计算层都有向融合态的方向发展的趋势，综合以上架构玩法的各个特点，说明市场更注重在存储的基础上如何展开更丰富的扩展，使之达到多模或者超融合的目的，有这个倾向的代表产品有：pulsar-bookie，Ti 系列，MatrixOne，MatrixDB ，TDengine ...etc。
总结
以上架构只针对特定场景并不分优劣，从计算能力和存储能力的分离开始，存算分离架构逐渐向更分离的方向努力，计算层的读写分离，存储层的存储计算和文件分离，都预示着一场超融合能力的发生。