PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火星人

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2600人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6群均已爆满，新人进7群，8群，准备9群)

PoalrDB这块，目前国内的博客在用户这个序列里面的，我还是能写出有点水平的东西，当然这的感谢阿里云的PolarDB核心研发的老师们，给我的内部资料，内部一些核心问题的解释......我后面有一个弹药库呢，就是庙小写不完。 今天就拿出最近刚给我的数据文件和存储部分说一说。（当然我个人技术水平有限，理解能力也有限，也只能写到这个程度了）我争取将一些内部，大家拿不到的东西，有的放矢的写一下，让一些信息也能流落民间。

最近群里经常有人问PolarDB的问题，然后那个兄弟说他用的PSL4，我就说他了，怎么不用PSL5，然后一帮人说差不多，差不多？？？？ 差远了

     碰巧核心研发这块的老师在群里看见有人问，因为搞纯技术的人都不善言辞，也不喜欢抛头露面，都愿意潜心搞技术。我也就做一个传声筒，将给我的内部的一些资料来学习、消化、且让这些知识流落民间。

     咱们天天说PolarDB, PolarDB 大部分人都停留在“泼辣DB”的名字上，今天我根据给我的内部资料我来说说PolarDB的底层，底层的存储系统。

     这个部分是非常产生大众不理解的部分，因为大部分人都一直和实体机打交道，云上的磁盘环境大多都是在臆想中，来诠释。上来我不废话，自问自答。

1 PolarDB 使用的是独有的磁盘系统吗？

是，独有

2 PolarDB 独有的磁盘系统叫什么？

PolarFS

3 PolarDB 磁盘系统有什么特殊的地方？

PolarFS 是一个分布式的存储系统，具有低延迟，搞可用性的特性。一句话PolarFS I/O模型消除了锁和关键数据路径上的上下文切换，利用DMA，在主存和RDMA，NIC/NVMe 磁盘之间进行数据的传输。在分布式，且一份数据要写三副本的情况下，写入的效率与本地的SSD性能相等。

4 PolarDB POLARFS 为什么是分布式，怎么体现分布式？

PoalrFS 使用了ParallelRaft协议，通过数据写入的随机性，打破了Raft协议本身的严格序列化的问题。

5 PolarDB 的 PolarFS 的架构设计是什么样子的？

PolarFS 由存储管理层和文件系统层组成。存储层负责所有存储节点的磁盘资源，并为每个数据库实例提供一个数据库卷。文件系统层支持卷中的文件管理，并负责对文件系统元数据的并发访问进行互斥和同步，PolarFS 集群的主要组件包括：libpfs（用户空间文件系统实现库）、PolarSwitch（计算节点上的 I/O 请求重定向器）、ChunkServers（存储节点上的 I/O 请求服务程序）和 PolarCtrl（控制平面）。

6 PolarDB 的ParallelRaft 协议怎么对并行进行改进，Raft协议本身性能不高是业内都知道的？

乱序确认的实现机制：

Raft 协议的限制: 在 Raft 协议中，follower 节点必须按顺序接收并确认日志条目。只有当所有之前的日志条目都被持久化存储后，follower 才能发送确认信息给 leader。

ParallelRaft 的改进: ParallelRaft 放宽了这一限制，允许 follower 在收到日志条目后立即进行确认，即使之前的某些条目尚未到达。

回溯缓冲区: 为了解决乱序应用可能导致的数据不一致问题，ParallelRaft 引入了一种名为“回溯缓冲区”的数据结构。回溯缓冲区记录了之前 N 个日志条目修改的逻辑块地址 (LBA) 范围。

冲突检测: 通过回溯缓冲区，follower 可以判断当前日志条目是否与之前的条目存在冲突（即修改了相同的 LBA 范围）。

乱序应用规则:

对于没有冲突的日志条目，可以按任意顺序应用。 对于存在冲突的条目，则必须按照到达的顺序依次应用，以保证较新的数据不会被较旧的数据覆盖。

乱序日志确认体现在以下几个方面： Follower 节点确认: 当 follower 节点收到来自 leader 的日志条目后，会立即将其写入磁盘并发送确认信息给 leader，而无需等待之前的条目。 Leader 节点提交: leader 节点在收到来自大多数 follower 的确认后，即可提交该日志条目，而无需等待所有 follower 的确认。 乱序应用: follower 节点可以根据回溯缓冲区的信息，对没有冲突的日志条目进行乱序应用。 乱序日志确认的优势： 减少 follower 节点的等待时间，提高 I/O 并发性能。 允许 leader 节点更早地提交日志条目，降低平均延迟。

7 PolarFS 如何利用RDMA和NVMe提升性能？用户态 I/O 堆栈和网络堆栈: 1 1 PolarFS 采用了用户态 I/O 堆栈和网络堆栈，绕过了内核，避免了系统调用和上下文切换带来的开销。 这使得 PolarFS 可以直接访问 RDMA 和 NVMe 设备，实现更低的延迟和更高的吞吐量。

2 RDMA 技术: RDMA (远程直接内存访问) 允许 PolarFS 在网络节点之间直接进行内存访问，无需 CPU 参与数据复制。 这种“零拷贝”的数据传输方式减少了 CPU 开销和数据传输延迟，特别适用于大规模数据传输场景。

3 NVMe 技术: NVMe (非易失性内存快速) 是一种针对 SSD 的高速存储协议，相比传统的 SATA 接口，NVMe 提供了更高的带宽和更低的延迟。 PolarFS 利用 NVMe SSD 作为底层存储介质，充分发挥 NVMe 的高性能优势，进一步提升系统的 I/O 性能。

4 SPDK 的应用 (来自外部信息) 除了 RDMA 和 NVMe，PolarFS 还可能利用了 SPDK (存储性能开发工具包)。 SPDK 是一个开源的用户态存储库，可以提供对 NVMe SSD 的高效访问。 (需要独立验证) 通过 SPDK，PolarFS 可以绕过内核的块层，直接管理 NVMe 设备，进一步降低 I/O 延迟。

8 PolarDB 的 EMP 怎么提升性能，存储的部分改了什么？

PolarStore 通过引入名为 Elastic Memory Pool (EMP) 的弹性内存池机制来提升 PolarDB 的性能。EMP 充分利用 RDMA 技术，构建了一个全局共享的内存池，为 PolarDB 提供了更大的缓存空间和更低的 I/O 延迟。

以下是 PolarStore 利用 EMP 提升 PolarDB 性能的具体方式：

解决 Buffer Pool 瓶颈: 传统数据库的 Buffer Pool 受限于数据库实例的内存大小，当数据量较大时，会导致频繁的磁盘 I/O，影响性能。 EMP 通过 RDMA 技术将存储集群中的内存资源整合起来，形成一个全局共享的内存池，突破了单机内存限制，为 PolarDB 提供了更大的缓存空间。

降低 I/O 延迟: EMP 允许 PolarStore 直接从内存池中读取数据，避免了访问磁盘的延迟。 通过 EMP，PolarStore 将 16KB 数据块的 I/O 延迟从原来的 100us 降低到 25us，提升了 5 倍。 相比传统的 NVMe SSD 80~90us 的延迟，EMP 带来了显著的性能提升。

提升 I/O 效率: EMP 能够智能识别数据库的热点数据，并将其缓存到内存池中，从而提高缓存命中率，减少磁盘 I/O 次数。

支持动态扩展: EMP 的容量可以根据数据库负载动态调整，避免了资源浪费，并能够满足不同规模数据库的需求。 PolarDB 可以提供数十 TB 的 EMP 容量。

提升写性能: PolarStore 支持将写操作的数据先写入 EMP 内存池，然后再异步写入磁盘，从而提高写性能。

支持读写分离: PolarStore 可以根据数据访问模式，将只读数据缓存到 EMP 中，从而提升读操作的性能。

智能识别热点数据: EMP 能够智能识别数据库的热点数据，并将其优先缓存到内存池中。 这进一步提高了缓存命中率，减少了对磁盘 I/O 的需求，从而降低 I/O 等待时间

异步写操作: PolarStore 支持将写操作的数据先写入 EMP 内存池，然后再异步写入磁盘。 这种方式可以将写操作的 I/O 等待时间隐藏起来，提高写性能，同时不影响读操作的性能

EMP 的优势:

突破单机内存限制，提供更大缓存空间。 利用 RDMA 降低 I/O 延迟，提升 I/O 效率。 支持动态扩展，满足不同规模数据库的需求。 提升写性能和读写分离效率。

总而言之，PolarStore 利用 EMP 的全局共享内存池、直接内存读取、热点数据识别和异步写操作等机制，有效地减少了 PolarDB 的 I/O 等待时间，提升了数据库的整体性能。

9  PolarFS 集中式和分散式设计中的思考和权衡 （这段不是人家给的我是看完资料猜的）

集中式设计 通常指数据存储在一个中心节点或少数几个节点上，由中心节点统一管理和控制。这种设计易于管理，一致性维护简单，但扩展性受限，中心节点容易成为性能瓶颈和单点故障。 分散式设计 则将数据分散存储在多个节点上，每个节点都具备一定的自治能力。 这种设计扩展性强，容错性高，但一致性维护和数据管理更加复杂。

全局共享内存池 EMP: PolarFS 通过 RDMA 技术将存储集群中的内存资源整合起来，形成一个全局共享的内存池 (EMP)。 这种设计更接近于集中式管理，所有节点共享同一个内存资源池。

数据多副本一致性: PolarFS 使用 ParallelRaft 共识协议，确保数据多副本一致性和文件元数据同步。 这意味着数据会复制到多个节点上，具备一定的分散存储特性。

存储节点可扩展: PolarStore 采用可扩展的存储节点架构，允许动态添加或移除存储节点，以满足不断增长的存储需求。

推测 PolarFS 的设计权衡: 基于上述信息，可以推测 PolarFS 可能采用了一种混合式的设计，结合了集中式和分散式设计的优点： 集中式管理: EMP 的设计更偏向集中式管理，方便资源分配和数据一致性维护。 分散式存储: 数据多副本机制和可扩展的存储节点架构则体现了分散式设计的特点，提升了系统的容错性和扩展性。

本篇的重点，知道差哪里了吗？？？？？

PolarStore PSL5上可免费开启EMP，不收取任何费用。（你们也就只能从我这知道这些）开启EMP功能后，可以将百us级别的16KB读IO延迟最高降低至25us，充分利用分布式存储集群的优势，大幅度降低热点数据的IO访问延时，在TP/AP多个场景下提升TPS，降低SQL执行时间，获得QPS读写性能大幅度提升。

OK，今天就说到这，散会！