分布式存储技术：总结 2023，展望 2024

1. 前言

这篇文章对 zStorage 相关的一些存储技术做一个总结，并对未来发展趋势做一些展望。

本文不关心整个存储行业的技术发展，只讨论跟 zStorage 有关的技术。实际上，分布式存储是一个相当大的领域，我没精力、也没能力，对整个分布式存储领域做一个全面的技术总结。zStorage 的目标是“最好的承载数据库的存储平台”，凡是跟这个目标相关的技术，本文都关心。

2. 全闪分布式

全闪分布式这个概念，逐渐被整个存储行业认可了。国内几个主流厂商，都在开发全新的全闪分布式架构。当然，也有厂商继续基于以前的混合分布式存储架构来包装全闪产品。可以预见，没有全闪分布式架构的厂商，在未来会逐渐被淘汰。当年 PureStorage 的全闪阵列发布之后，基于混合阵列架构开发的全闪产品，很快就被市场淘汰了。同样的故事，会在分布式存储领域再重复一次。

全闪分布式架构的主要特征在于：

• 异步 Event 模型异步 event 编程模型。Thread 模型的优势是代码结构简单，编码生产效率高，但是性能开销大。在业务逻辑简单，性能要求高的系统中，彻底抛弃 thread 和 mutex 是必然选择。

• 用户态驱动与内核态驱动相比，用户态驱动省掉了内核与用户态之间的线程上下文切换，也省掉了内核与用户态之间拷贝数据的开销，是提升性能的必选项。

• RDMA 和 NVMeoF100G RoCE 或者 IB 接口，以及 NVMeoF，已经成了高性能分布式存储的标准配置。值得提一下的是，很多现存系统的性能瓶颈不在网络通信模块，即便配置了 100G IB/RoCE 也无法提升性能，社区版 Ceph 就存在这个问题。

• 高性能本地存储有些分布式存储系统直接采用 ext4、xfs 等单机文件系统作为本地存储模块，早期的 Ceph 也是这么做的，使用了十年之后，Ceph 研发团队终于意识到，对于分布式存储的本地存储来说，ext4/xfs/btrfs 等单机文件系统并不是最佳选择。

2.1. 存储介质

2.1.1. ZNS

ZNS 接口声称可以减少 SSD 的 OP 成本，减少 GC 导致的性能开销，我并不认同。用 append-only 接口替换掉 write-in-place 接口，并没有真正省掉 OP 成本和 GC 开销，只是把这些成本和开销从 SSD 盘内部转移到了应用层。使用 ZNS 接口应用，必须自己设计 类似 LSM Tree 的数据结构，自己定期对 LSM Tree 做 Compaction 以回收无用空间。那些没有被即时回收的空间，跟 SSD 盘内部配置的 OP 是等价的。从应用发起的 Compaction 流程，占用了 HOST 的 CPU 处理能力，并且占用了 HOST 到 SSD 的总线带宽。

ZNS 的真正潜力在于，允许 SSD 盘配置性能更弱的 CPU，以及允许 SSD 盘配置更少的 DRAM， 从而让 SSD 盘的成本下降。可是，硬件成本不只跟复杂度相关，跟销量本身相关性更强，销量越大成本越低。现在看来，ZNS 靠简化 SSD 盘内部设计来节约掉的成本，并不足以抵消普通 NVMe 接口 SSD 由于销量巨大而带来的优势。

重新为 SSD 盘定义块接口，已经有过很多尝试了。但是，只有 NVMe 获得了巨大成功。Open Channel 算是失败了。NVMe 中有一个 Streams 选项，也没有得到广泛应用。现在看来， ZNS 也很难成功。最近两年又有人提出 FDP，是另外一个版本的 Streams，FDP 是否能得到推广，尚未可知。

2.1.2. SCM

随着 Intel Optane PM 宣布停产，字节级寻址的持久化内存的发展速度慢了下来。无论 如何 SCM 技术不会消失，很可能在 CXL 时代大放异彩。现在开发的新架构，必须考虑如何 利用好 SCM。如果力量足够强，应该投入一些研发资源持续跟进 SCM 技术的发展。

2.1.3. HDD

早有预测说，2027 年 SSD 的每 TB 存储成本会下降到与 HDD 持平，到时候 HDD 将彻底失去 生存空间，HDD 会像 BP 机、MP3、傻瓜相机、车载 GPS 导航仪一样，彻底消失。在我看来， 也许 2027 年太早，HDD 还不至于彻底消失。这个时间点，也许是 2030 年，或者 2035 年， 总之，这个时间点一定会到来，不需要等太久。在 2023 年还继续把研发成本投入 到 SSD 和 HDD 的混合存储产品上，是不明智的。

2.2. 重删

全闪阵列支持重删，背后的逻辑是：SSD 盘的随机读性能，在全闪阵列中用不完的，富裕很多。CPU 性能也是有富裕的，那么，就把这些富裕的 SSD 和 CPU 的性能利用起来，用 在重删上面，来降低每 TB 成本。

主存储的重删，不能只有产品支持，还要配合商业模式，也就是，不再按照 SSD 盘的物 理容量定价，而是按照客户存入的数据量定价。数据缩减率低的风险，厂商承担。这是 全闪阵列成功的原因。

但是，现在看来，以上这些成功因素，已经发生了变化。牺牲一些性能，换取每 TB 价格 下降，看起来不再那么有吸引力了。10 年前，Pure Storage 起步的时候，SSD 每 TB 的价格，是 HDD 的几倍甚至十几倍。但是，现在 SSD 每 TB 成本价格已经跟 HDD 接近了，再过几年 就跟 HDD 持平了。10 年前，阵列还是以 HDD 或者混合存储为主，那个时代，阵列的性能都 不高，几万 IOPS 就可以称霸江湖了。那个年代，人们习惯于低性能的存储，几百上千 IOPS 的存储，一样可以跑数据库应用。

但是，现在人们已经无法忍受低性能存储了。现在单片 SSD 的性能就可以达到百万 IOPS。另外一方面，有十几个服务器节点，上百个 SSD 盘的 Ceph 集群，也是百万 IOPS。如果还要牺牲一些性能，换取每 TB 成本下降，这个逻辑有些讲不通了。

所以，现在搞全闪阵列，或者全闪分布式，是否还应该搞重删，值得重新思考审视。在我看来，把 CPU 的每一条指令，都用到提升 IOPS 和带宽上，是更明智的选择。

2.3. 开源软件

现在讨论分布式存储，已经很难避开 Ceph、DAOS、SPDK 这些开源软件。Ceph 已然垂垂老矣，但凡有一点实力的 Ceph 厂商，已经开始着手开发下一代架构的产品，或者基于 DAOS， 或者全自研的新架构。

DAOS 发展迅猛，但是遭遇了 Intel Optane 停产的打击，基于 DAOS 开发的产品比原计划 上市时间推迟至少一年，也为此浪费了很多研发成本。对于实力比较强的团队，这不 算致命，但是对于财力不强的企业，打击不小。在 Optane 停产之后，Intel 是否会停止对 DAOS 的投入，是一个值得关注的风险点。研发是高风险、高投入、高产出的活动，如果 Intel 不再投入，基于 DAOS 做产品化的团队，是否有能力推动 DAOS 架构继续发展，是值得怀疑的。一般来说，对开源软件做产品化的团队，对开源技术的先进性有强烈的信仰，对开源社区的技术决策有很强的依赖。团队如何摆脱盲目迷信开源习惯，如何培养独立思考、独立决策的能力，将会是一个非常大的挑战。

SPDK 并不是简单包装一下就可以上市销售的完整系统，只是一些零碎的存储相关驱动 和协议的工具模块库。SPDK 里面的工具模块性能和质量都还可以，只是必须全流程按 照 SPDK 设定的轮询模式才能充分发挥出它的性能。

无论 Ceph、DAOS 还是 SPDK，使用这些开源软件的团队都应该有清晰的策略，是选择坚决跟随开源社区版本，还是分叉出自己的版本，从此与开源版本分道扬镳。

zStorage 使用了 SPDK，我们的策略是后者，维护自己的版本，遇到严重 Bug 到社区去找一找，如果已经解决了，就把这个 Bug 的补丁单独合并过来。如果找不到，就自己解决。如果我们需要什么新功能特性，多半是自己开发。例如，我们给增加了 SPDK 中 断轮询自动切换的特性。还增加很多统计功能，例如，统计哪些 poller 耗时过长。

2.4. Share Everything 架构

share everything 架构这个口号是 vastdata 喊出来的，Vastdata 是 2023 增长最迅猛的 存储初创公司。存储行业的研发人员，都不应该忽视这个公司，以及它的 DASE 架构。

share everything 架构分为两层：下面的存储层是双控的 EBOF 全闪存储硬盘框，上面业 务层运行在标准服务器节点上的软件集群。所有业务节点通过 100G RDMA 网络共享访问 EBOF 存储节点。EBOF 存储节点的特点是双控、双口 nvme SSD 盘、每个控制器带有多个 100G RDMA 网口。Vastdata 自己并不生产 EBOF 硬盘框，委托其他厂商生产。vastdata 的 目标是让 EBOF 硬盘框变成像标准服务器一样的廉价硬件，这样围绕 share everything 架构生态系统才能发展起来。

这种架构可以在集群规模不大的情况下支持大比例 EC，这样可以降低每 TB 存储成本。与 基于标准服务器的分布式 SDS 相比，这种架构把最小故障域从服务器节点缩小到了 SSD 盘， 一个 EBOF 框中单个控制器故障，还有另外一个控制可以工作，不会导致整个 EBOF 框故障 离线，这种故障模型跟双控阵列一样。这种架构的问题是性价比不高，虽然最近 20 年网 络技术发展很快，网络带宽迅速从千兆发展到 100G，但是 IB 和 RoCE 网络的带宽成本都比 服务器内部 PCIe 总线的带宽成本高很多。至少现在，跨越 100G IB/RoCE 访问 EBOF 硬盘框， 并没有性价比优势。

无论如何，这个技术值得关注。zStorage 也会在未来版本中考虑如何适配 EBOF 硬盘框， 但不是现在。

2.5. 共识协议

2.5.1. 为什么需要共识协议

分布式系统的设计难点是故障处理。如何在某些部件发生故障的情况，保持系统正常工作状态，包括，数据不丢失，并且能够正确处理从主机所收到的 IO 请求。这就是故障处理流程要考虑的问题。

存储系统有两种类型，分布式和集中式。它们之间最大差别在于，分布式假设系统中所有所有部分都可能发生故障，所有部件都是可以被更换的。

集中式系统，假设存在一个非常可靠的部件，它不会发生故障。例如，系统的背板，或者仲裁节点等等。集中式系统类似一个官僚系统，对某个故障做出决策判断的基本模式是，下级服从上级。在集中式系统中，如果对某个问题的判断产生分歧，那么按照流程上升，交给上级做裁决。例如，硬盘阵列的 A 控和 B 控相互认为对方故障了，认为自己还处于可正常工作状态，这个分歧如何解决？一般来说，由背板来解决，背板上有一个锁，谁抢到，谁就是正常工作状态。背板上这个”锁”，很可能就是一个简单的数字逻辑芯片实现的。就是这么一个简单的锁，解决了“发生分歧以谁的判断为准”的问题。

在分布式系统中，没有永远不发生故障部件，所有部件都可能发生故障。在分布式系中，对关键问题的判断，需要采用”投票”的方式，共同做出决策。投票，就需要有一个规则，大家按照这个规则来投票。这个投票的规则，就是 Paxos 和 Raft 这类共识协议。在某些部件发生故障的情况下，让系统能够做出正确的反应，对分布式系统来说，并不简单。其中有一个前提条件是，“投票规则”的设计没有漏洞。这一点也不容易做到，因为有很多特殊情况需要考虑。如果每个分布式存储系统都自己设计一套投票规则， 一般来说，总会在运行过程中发现各种规则没考虑到的情况。Paxos 和 Raft 解决了这个问题，这两个共识协议被大家认为是比较完善的，逐渐被行业接受了。一般来说，新的分布式系统没必要再定义自己特殊的“投票规则”了，直接采用 Paxos 和 Raft 就好了，这两个共识协议，很多双同行的眼睛仔细检视过了，经过了 TLA+这种形式化语言的证明。因此，对分布式存储系统的设计者来说，透彻理解 Paxos 和 Raft 很重要。

分布式存储软件的架构，由控制面和数据面两个部分来构成。系统运行的关键决策由控制面负责，例如，集群由哪些节点构成，每个节点负责处理哪部分数据，哪个节点发生了故障等等。控制面由一些控制节点构成，控制节点按照共识协议的规则来共同决策，这保证了决策的连贯和一致，避免了“集群脑裂”。

数据面负责处理 IO 请求，也需要对一些问题做决策。例如，何时可以给主机回复写成功？数据有三个副本，应该从哪个副本读？等等，如果这些问题全部交给控制面决策，那么控制面就会变成瓶颈，集群的性能会很差。数据面需要自行对某些问题做决策，因此，数据面也需要运行共识协议。

2.5.2. 为什么关注共识协议

虽然 Paxos 和 Raft 的设计很严密，投票规则没有漏洞，但是，还不能完全满足实际产品的需求。对 Raft 的改进和增强主要集中在数据面，etcd 可以满足管控面的需求。zStorage 使用了 Raft 协议，我们遇到下面一些问题：

• Multi-RaftzStorage 在数据面使用 Multi-raft，把一个存储池的数据打散(sharding)到多个 Raft 组中，每个节点和硬盘承载多个不同 Raft 组的副本，在扩容或者硬件故障情况下，在节点和盘之间重新分布这些 Raft 副本，以此达成可弹性伸缩的目标。每个节点上有多个 Raft 组，心跳消息就会很多，会占用很多网络带宽和 CPU 处理能力，实际上，并不需要在每个 Raft 组都维持自己的心跳，只需要在节点之间维持心跳就 可以探测到节点（或者进程）故障了。因此，需要对多个 Raft 组的心跳消息进行合并。除了合并心跳消息之外，还需要考虑对多个 Raft 组的日志合并之后写盘。日志合并之后， 减少了对 SSD 盘随机写的次数。另一方面，SSD 盘写操作的最小单位是 512Bytes 的数 据块，如果不做合并，要等到 Raft 日志凑齐一个 512B，可能需要很长时间。如果不等凑齐就写盘，那么 SSD 盘上就会有比较多的空洞，增加了写放大，影响性能，也影响 SSD 盘的寿命。zStorage 是块存储系统，不涉及跨越多个 Raft 组的分布式事务管理，这方面比分布式数据库简单一些。

• 硬盘状态机 zStorage 是一个分布式存储系统，对它来说，集群所有服务器节点硬盘上的数据全集， 构成了 Raft 状态机。但是，Raft 有一个隐含的基本假设是，状态机是在内存中的，并且尺寸并不很大。虽然 Raft 的大论文中有一节提到了硬盘状态机，但是篇幅并不长，只给了一些基本的处理原则，并没有具体的设计。Raft 硬盘状态机，首先要解决的问题是，如何打快照？不可能再像内存状态机一样， 把数据完整复制一份到硬盘上了，因为硬盘上所有存储空间都归属状态机，没有其 他多余空间用来存储快照了。Raft 的大论文中给出的建议是，本地存储要支持 COW 快 照，这个方法其实也不太可行。一方面对于用户数据本身要支持用户级别的快照， Raft 的 COW 快照跟用户级别的快照可能存在相互冲突，不好解决。另外，在发生盘故 障的情况下，对于几个 TB 的数据执行快照安装流程，可能耗时几个小时。在这几个小 时中保持日志不删除，也不可行。zStorage 用了自己的方法，解决 Raft 在硬盘状态机 情况下如何打快照和安装快照的问题。当出现硬盘故障之后，需要对故障硬盘上的副本做数据重构。具体过程是，对跟故障 硬盘相关的 Raft 组做配置变更，用正常硬盘上的 Raft 副本替换掉故障副本，配置变更之后要对新副本执行安装快照的过程，也就是把数据复制到这个新副本上。一般来说，这个数据复制的过程耗时很长，zStorage 当前版本规格是 4TB/小时，那么一片 8TB 的 SSD 盘发生故障，需要耗时至少 2 小时。如果在这两个小时过程中，再发生一个 SSD 盘 故障，那么就会有部分 Raft 出现两个副本故障，只剩下一个正常副本，那么这个 Raft 组就不可用了，不能再继续正常工作。整个系统中有几千个 Raft 组，只要有 1 个 Raft 组 不能正常工作，那么整个存储池就停摆了。为了解决这个问题，zStorage 给 Raft 增加 了一个 logger 角色。logger 是一个可以在只有日志没有完整状态机数据的情况下工作 的 Raft 组成员，logger 可以投票，但是不能被选为 Leader。增加了 Logger 角色之后， zStorage 的三副本可以在一个 SSD 故障的情况下，在 10 秒内恢复为三副本工作状态，只 要 10 秒内没有发生第二个 SSD 故障，那么就不会出现 Raft 组不可用的情况。增加了 Logger 角色之后，提升了 Raft 在硬盘状态机情况下的可用性。zStorage 还利用 Logger 角色实现了基于 Raft 的二副本模式。

• Erasure Code 实际上，Raft 并不需要每个成员都保持一个完整的状态机，一个 Raft 组中所有成员加 起来有一份完整的状态机就够了。在分布式存储产品上实现基于 Raft 的 EC，目前可供参考的例子并不多，很多问题需要自行解决，zStorage 也正在探索中。

• 实现问题

  配置变更 Raft 论文中讲了两种实现成员变更的方法：1、单步骤只变更一个成员，也就是在 一次变更中，要么增加一个成员，要么减少一个成员，不能直接替换掉一个成员。例如，要实现由(A, B, C)==>(A, B, D)的变更必须分为两步走，第一步先做 (A, B, C)==>(A, B, C, D)，第二步再做(A, B, C, D)==>(A, B, D)。这种方法 比较简单，但是有可用性问题；2、第二种做法是 joint consensus 方法，实现稍复 杂，没有可用性问题。很多开源的 Raft 都没有实现 joint consensus 方法。

  流程异步化 SPDK 所谓的“线程”，并非线程，而是异步 event 处理模式。zStorage 达成相对比较 高性能的一个重要原因是，避免了 pthread、mutex、condition 的编程模式，使用 SPDK 框架提倡的异步 event 模式。这就是要求代码中任何位置都不能阻塞，Raft 流程中的写日志、发送消息、写元数据等等，都不能阻塞。目前有一些异步实现的开源 Raft 可供参考，但是，这些开源 Raft 总有些不经常运行的流程是同步实现的。

  读操作 Raft 中实现读的方法有两种：1、读操作其他操作相同，也要走 Append Entry 和 commit 流程；2、不走 Append Entry 和 commit 流程，直接在 Leader 上读状态机；显然第 2 种方法性能更好，但是要保证新的 Leader 选出来之前，旧的 Leader 先退位， 如果旧的 Leader 等待了一段时间，没有收集到足够的心跳消息，它自行退位。如果 这个旧 Leader 所在的服务器时钟不准，那么“等待一段时间”就不可靠，就可能出 现新旧两个 Leader 同时工作，Client 从旧 Leader 读出了旧数据的情况，从而导致了 数据不一致问题。为了避免这种问题，zStorage 会每隔一段时间，对所有服务器的 时钟频率做一次校对，并且让“等待一段时间”这个时长足够容忍不同服务器节点 之间的物理时钟频率的偏差。

  测试用例 zStorage 没有设计自己的共识算法，而是直接使用了 Raft，这个相对成熟的算法。这个技术决策客观上缩短了 zStorage 的开发周期，节约了开发成本。但是，即使完全按照 Raft 论文描述的原理去写代码，也不能完全避免代码中的 Bug。找出并改 掉这些代码中 Bug，最关键的是测试，要有一套完备的测试用例。etcd 一套已经 得到广泛应用的 Raft 开源实现，etcd 有一套针对 Raft 的测试用例集，可用参考。但是 etcd 的测试用例是用 golang 写的，zStorage 是 C 语言实现的，etcd 用例无法直 接使用，zStorage 用 C 语言重写了 etcd 所有用例，并且每晚例行运行这些测试用例 对 zStorage 的 raft 实现进行测试。

未来 zStorage 还会持续在 Raft 协议上投入研发资源，我们目标让 Raft 更好地为存储业务服务。zStorage 对于改进 Raft 协议本身没兴趣，例如，如何让 raft 支持乱序提交，这类 改进收益有限，但是它修改了 raft 核心工作流程，风险比较高，投入产出比不高。

2.6. 存储层接口

一般来说，分布式存储系统至少有两层：协议网关层、数据存储层，有些系统还有一个 中间的业务层。数据存储层的基本功能是对数据进行持久化，有些还会实现一些业务功 能，例如：加密、压缩、块存储的逻辑卷、快照、克隆等等。存储层实现功能不同，对 上层提供的接口也不同。总的来说，存储层接口有两类：1、追加接口；2、原地更新接口。根据存储层接口不同，可以把分布式存储系统的架构分为两类。

2.6.1. 追加接口（Append-Only）

谷歌的 GFS、微软的 WAS(Windows Azure Storage)存储层的接口是追加接口。一般来说， 提供接口的分布式存储系统，存储层不会实现很复杂的业务，例如：逻辑卷、快照、克隆 等等，都不会在存储层实现。存储层最多只实现压缩、加密等简单的数据处理服务。另外，这种类型的系统一般也不需要实现 Multi-Paxos 和 Raft 等共识协议，只需要实现 相对比较简单的 seal-and-new 流程，就可以保证故障场景中数据一致性。由于存储层 的数据一旦写入就不再改变，扩容和故障恢复的数据重构流程都相对简单。

这种架构有两个主要缺点：1、业务层实现复杂；2、处理流程长，性能开销大。由于存储 层只支持追加写，因此业务层的实现更复杂，一般来说，业务层需要实现一套 LSM Tree 的 处理逻辑，包括 compaction 流程。这种架构简化了存储层空间管理，也减轻了 SSD 盘 内部的 GC 压力，但是需要业务层发起 compaction 流程，并且需要跨网络进行数据合并， 这使得空间回收的处理流程更长，性能开销更大。

2.6.2. 原地更新接口（Write-in-place）

zStorage 和 Ceph 的存储层对外提供原地更新接口。与 Append-Only 接口的架构对比， Write-in-place 接口可以在存储层实现更多业务功能，也不需要跨越网络做 compaction， 性能更好。缺点是模块的功能边界不够清晰，不太适合规模很大的开发团队。zStorage 团队规模不算很大，而且对性能要求很高，这种架构更合适。

3. 数据库的存储平台

3.1. 软件定义存储（SDS）

zStorage 平台坚持走纯软件路线，不会与某种类型的特殊硬件强绑定。zStorage 并不排 斥利用特殊硬件，但是要考虑投入产出比，要考虑特殊硬件对软件架构发展的影响。基 于 zStorage 平台的产品可以走软硬结合的一体化路线，提升性能、改善产品稳定性等等。

DAOS 强绑定 Intel Optane PM，由于 Optane 停产对 DAOS 的发展造成了不小的冲击。强绑某 种硬件，对于分布式软件来说，有很大风险。这种强绑定硬件的设计模式，也没有创造 很多新价值。

全闪阵列是采用专用硬件的典型代表，每个厂商都设计生产自己的专用硬件，得不到服务器通用硬件生态系统的支持，因此成本比较高。

3.2. 存算分离

分布式（集群）数据库有两种架构模式：1、每个数据库节点各自管理自己的持久化存储， 节点之间不共享数据，如 TiDB、OceanBase、ClickHouse 等，就是这一类；2、数据库节点 与底层存储设备是分离的，底层存储在所有数据库节点之间共享，例如 Oracle RAC、 PolarDB 等，都是这一类数据库。第 1 类是存算一体的 Share nothing 架构，第 2 类是存算 分离的架构。第 1 类的优点是，不需要专门的存储系统，数据库自己管理存储系统，数据 库自己负责把数据复制为几份，自己管理冗余数据副本。

存算分离的主要意义在于，可以独立对存储和计算进行扩容和缩容。其次，存算分离架 构可以充分利用专业存储系统的能力，提升系统整体的可靠性、可用性和易用性。

应用对于存储和计算需求，并不总是确定不变的，有时候应用需要更多的计算资源，有 时又需要更多存储资源，如果存储和计算之间的比例不可弹性变化，那么就有很大概率 存在浪费。一般来说，share nothing 的存算一体分布式数据库集群更适合 OLAP 应用。但是 Snowflake 采用了存算分离架构，并且表现非常出色。

既然分布式数据库自己就能管理硬盘，能做三副本，硬盘故障之后也能做数据重构，为 什么还需要数据专业的数据存储系统？对存储数据来说，专业的数据存储系统，比兼职的数据库做得更好。存储系统一般都支持快照、克隆等特性，并可以可以基于快照实现 块存储层的备份，速度快，数据一致性有保障。专业存储会定期读出数据做校验，如果发现错误，则用冗余副本来恢复。专业存储支持纠删码等冗余方式，每 TB 存储成本更低。

存算分离架构已经成了比较明显的趋势。甚至连 TiDB、ClickHouse 等 Share Nothing 架构 的分布式数据库也准备推出存算分离的版本。

如何更好支持存算分离的数据库架构，是 zStorage 的一个重要课题。

3.3. 平衡 OLTP 和 OLAP

数据库应用分为交易型（OLTP）和分析型（OLAP）两种类型。银行存款取款，查询某人 的账户余额等，对数据库来说，算是交易型应用。数据库的交易型操作需要存取的数据量 不大，但是对时延要求比较苛刻。如果存储系统时延太高，或者时延不稳定，时高时低， 那么用户的感觉就不好。如果银行要统计最近一年每天上午 9:00 - 10:00 时间段的存款 总金额，那么就需要把所有存款记录读出来，过滤出 9:00 - 10:00 的存款记录，然后再 把这些记录中的金额加起来。分析型操作需要访问的数据量很大，一般来说，分析型 任务的执行时间都很长，因此对时延不是特别敏感，但是对存储系统的吞吐量要求 比较高。

一般认为，Share nothing 的分布式数据库更适合分析型应用，也就是 TiDB、OceanBase、 ClickHouse 这一类。因为可以多个节点同时并行做分析任务，然后再对结果进行汇总。基于共享存储的集群数据库更适合交易型应用，Oracle RAC 就是这一类。生产环境的实际情况是，很难找到纯粹的交易型应用。更普遍的需求是， 多数情况下是交易型操作，也夹杂少量的报表类分析型业务。交易型的数据库， 也需要满足少量分析型任务的需求。

软件定义的分布式存储系统，跟 Share nothing 分布式数据库架构类似。如果基于共享的 分布式存储系统构建 Oracle RAC 类似的交易型数据库，同时让分布式存储帮助完成少量 的分析型任务，充分利用多节点的并行能力。实际上 Oracle 的数据库一体机 ExaData 就是 这么做的，它也在市场上取得了商业成功。所以，我认为“分布式存储”、“共享存储集群”、 “计算下推”同时具备这三个要素的架构，是理想的数据库架构。

关于 zStorage

zStorage 是针对数据库应用开发的高性能全闪分布式块。三节点 zStorage 集群可以达到 200 万 IOPS 随机读写性能，同时平均时延<300us、P99 时延小于 800us。zStorage 支持多存储池、精简配置、快照/一致性组快照、链接克隆/完整克隆、NVMeoF/NVMeoTCP、iSCSI、CLI 和 API 管理、快照差异位图（DCL）、慢盘检测、亚健康管理、16KB 原子写、2 副本、强一致 3 副本、Raft 3 副本、IB 和 RoCE、TCP/IP、后台巡检、基于 Merkle 树的一致性校验、全流程 TRIM、QoS、SCSI PR、SCSI CAW。

(结束)