近来，Solidigm连搞两个大新闻——首先是StorageReview利用AMD EYPC处理器和Solidigm QLC SSD构建的服务器刷新了计算100万亿位圆周率的世界记录，总用时为59天10小时46分49.55秒。
上一个记录是在2022年，谷歌云（Google Cloud）在人类历史上第一次将圆周率计算到百万亿位，总用时为157天23小时31分7.651秒。
也就是说，这一次只用了三分之一多一点的时间。
圆周率百万亿位的最后十位数字是：
▼
3095295560
圆周率100万亿位是一个什么样的概念的？如果一张A4纸打印1万位数字，那也需要100亿张纸，摞起来需要1000公里高；如果平铺的话，北京市海淀区的地皮肯定不够，再拉上东城区、西城区、石景山区帮忙都有点儿勉强。那存硬盘里总可以吧？讲真，一般人家里压根儿就存不下这个数。因为单单是以十进制数的文本方式存储它，就需要100TB的空间。所以，计算极高精度圆周率是一个计算密集、存储密集的任务。
谷歌云当时使用的计算节点为运行Debian Linux 11的n2-highmem-128，对应的配置为Intel Xeon 128 vCPU、864GB内存，网络接口带宽为100Gbps。存储节点为32个n2-highcpu-16，每个节点配置了2个10359GB的区域平衡持久磁盘（Zonal Balanced Persistent Disks），16 vCPU，32Gbps网络。
（图片来源：Google）
这里顺便简单介绍一下谷歌云的几种持久磁盘（PD）：
☞ SSD Persistent Disks：SSD持久磁盘显然基于SSD构建，适合需要高IOPS的工作负载。
☞ Balanced Persistent Disks：平衡持久磁盘也基于SSD，平衡的是性能与成本，拥有较低的每GB成本和较低的IOPS。
☞ Standard Persistent Disks：标准持久磁盘，基于机械硬盘（HDD），价格实惠，适合顺序读/写操作。
根据谷歌云的相关介绍，平衡PD的（每实例）读写吞吐量为1200MB/s，IOPS可达80k，成本和单位容量的吞吐量（MB/s per GB）均在SSD PD的60%左右。从这个指标看上去，谷歌云当时就意识到这个任务的特点是容量比IOPS重要。
谷歌云运行整个百万亿位π运算项目使用的总容量为663TB，峰值用量515TB，处理的数据总量为82PB（读取43.5PB，写入38.5PB）。
成本方面，谷歌云内部怎么结算我们无从得知，不过我们可以通过公开数据大致算一下。一个n2-highmem-128每个月平均5000美元，一个n2-highcpu-16每月平均400美元，整个集群跑上半年大约需要10万美元。
现在回过头来看破纪录。StorageReview使用了一台（物理）服务器，具体配置为：
CPU：双路AMD EPYC 9654（96 核，基准频率2.4 GHz，加速3.7 GHz）
内存：24槽64GB DDR5 4800内存，总计1.5TB
SSD：19个Solidigm D5-P5316 30.72TB，可用530.1TB
操作系统：Windows Server 2022
基于同样的算法，这个系统使用的容量峰值为514.5TB，与谷歌云相同。数据吞吐量略有差异，为读取40.2PB，写入35.4PB，总计75.6PB。
从硬件角度看，新记录的处理器内核数量为谷歌云的3倍，192核AMD第四代EYPC对64核（128个超线程）Intel第三代至强，内存容量约为2倍。存储方面的性能看，19个本地QLC SSD的纸面带宽（写3200MB/s×19=60800MB/s）与32个存储节点（1200MB/s×2×32=76800MB/s）大致在一个数量级；IOPS方面，随机写入肯定是本地QLC SSD较弱，益企研究院曾经测试过D5-P5316，其64KB随机写IOPS大约是8K，低于平衡PD的指标，考虑到数量，总IOPS更不可比；至于读性能，则不论是顺序读还是随机读IOPS，本地QLC SSD的优势都很明显。
但是，如果考虑到网络瓶颈，那情况就不一样了。根据数据的总读写量和总时间，我们可以估算出系统平均每秒需要读或写8GB/s的数据，谷歌云计算节点的100Gbps网络带宽只能应付平均水平的吞吐量。而峰值是多少呢？StorageReview称突发写入可以达到38GB/s，这起码需要400Gbps网络才能应付。
简单说，三倍数量的处理器内核，没有瓶颈的本地存储，共同创造了新的记录。至于这样一台服务器的成本，我们的读者有很多行内人，可以在后台给我们留言。
综合来看，StorageReview的目标是以较低的成本刷新记录，构建服务器时使用了目前性价比最好的双路x86处理器，以及容量刚好够用的SSD。对于SSD而言，这一次应用并不考验随机性能，QLC的吞吐量是满足需要的，其容量和性价比优势就显得尤为突出。要知道，现在市场上30TB容量点的SSD凤毛麟角，而D5-P5316是一款2年前上市的SSD，难怪Solidigm要将百万亿位圆周率的记录视为“全村人的骄傲”了。
Solidigm的另一件大事也与QLC相关，即上周正式推出Solidigm D5-P5430，而D5-P5316的“接班人”也快要来了。这两款新品的共同点是采用192层的第四代QLC，在性能和耐用性等方面有高低之分。
耐用性向来是QLC SSD的短板，现如今也能搞出“必要耐用性”（D5-P5430）和“足够耐用性”（D5-P5316“后人”）这样的细分来，是不是真的要走向主流了？
应用是检验耐用性的第一标准，让我们回到破百万亿位圆周率世界记录的案例来分析一下写入量。计算期间，每个（D5-P5316）SSD每天大约需要写入30TB的数据，也就是1DWPD。整个项目运行下来，SSD的寿命损耗在2~3%。按照这个强度继续运行5年应该可保无虞。
(图片来源：StorageReview网站)
有趣的巧合是：同样的介质，如果设定成TLC模式，那就需要25块盘才能达到目标容量，正好比前面板24个U.2盘位多了那么一丢丢……接下来，我们可以引出几个话题，简单展开一下。
1.QLC SSD的耐久度超出许多人的预期
可能有人觉得单块D5-P5316在写入近2PB数据后，耐久度只损耗2~3%，并不可信。但根据Intel和Solidigm给的保修政策，30.72TB的D5-P5316的随机写耐久度为22.93PBW, 顺序写耐久度为104.55PBW。考虑到圆周率计算整体偏顺序写，CrystalDiskInfo判读的健康信息与厂家的保修政策是吻合的。
(图片来源：Solidigm)
对于顺序写，P5316可以承受接近2 DWPD的工作强度，这次记录中并没有把它逼到极限。
Solidigm在发布D5-P5430时也指出，根据公司内部分析，2020～2023年在全球范围出货的数据中心SSD，大约85%的额定值≤1 DWPD。多伦多大学在2020年的文件与存储技术会议(FAST '20）发表的论文中表示，“…对大多数情况而言…，将存储系统的写入负载调整到接近QLC SSD的PE周期极限并不会有风险，因为99%的系统使用不会超过其（SSD）额定寿命的15%。”
Solidigm D5-P5430有U.2、E1.S和E3.S三种形态，用于替代M.2的E1.S体积较小，最大容量“仅”15.36TB，U.2和E3.S的最大容量均为30.72TB，追平U.2和E1.L规格的D5-P5316。
性能方面，D5-P5430顺序读写达7000/3000 MB/s，随机读写达971K/120K IOPS，基本上读性能与主流（PCIe 4.0）TLC SSD相当，写性能大约在一半上下，在读多写少的应用场景可以说是相当够用。
最后看这个“必要”的耐用性：D5-P5430随机写为0.58 DWPD，顺序写为1.83 DWPD。凭借容量上的优势，30.72TB的D5-P5430总写入量达32 PBW，也略高于1 DWPD但一半容量的主流TLC SSD。
2.如何用好QLC SSD
圆周率计算属于一次典型的“知Q（LC）用Q”的案例。有那么多顺序读写优化的应用场景给QLC SSD发挥吗？
还真有，而且不少。Intel在推广数据中心级QLC SSD时，曾用一个图表列出了QLC SSD的适用场景。
（图片来源：Intel）
从图中可以看到，AI、大数据、CDN/VoD、HPC毫无意外地成为QLC SSD的优势领域，因为基本上都是大数据块，且读多写少。然后，HCI和云存储也被看做是适合QLC SSD的场景，这就涉及到写缓存或写整形的问题了，将随机写尽量转化为顺序写入。
在上图中，还有一个重要的细节，在读写比例60/40这一列，QLC SSD的领域被划到了64KB及以上数据块大小。个中原因是因为当时Intel的最新QLC SSD就是D5-P5316，其IU（Indirection Unit）也就是SSD内部对介质最小写入单位为64KB大小，如果拿去做4KB随机写，是很不划算的。
但是，千万不要以为QLC SSD只适合64KB及以上块大小。实际上，Intel更早的数据中心级QLC SSD，如D5-P4420，就是用的4KB IU，其4KB随机写IOPS也可以达到36K。在D5-P5316上选择64KB IU是对追求极致QLC成本的尝试，以为用户提供合理成本的大容量QLC产品。就拿D5-P5316的“前任”D5-P4326来说吧，型号虽然也以6结尾，IU则是对客户更加友善的16KB，有些业务甚至可以直接用起来，不需要大改软件。
现在Solidigm的新一代QLC SSD中，D5-P5430已经回到4KB IU，4KB随机写IOPS提升到了110K——与PCIe 3.0 TLC SSD的全速性能相当，容量点涵盖7.68~30.72 TB。
随着新的QLC SSD推出，64KB IU带来的偏科问题也就成为过去式。现在Solidigm已将优势领域做了更新，变成了下面这样：
(图片来源：Solidigm)
在新的区域图中，被“64KB”断开的部分被拉平了，然后，HCI和云存储的场景有了更明确的细分，如索引、分布式存储（DSS）、联机事务处理（OLTP）等。OLTP是典型的传统关系型数据库的一种应用，提到它就顺便说一下在线分析处理（OLAP），后者的吞吐量要求比前者高得多，但总体上是读多写少，也比较适合QLC SSD。
3.SSD性能过剩
上一个话题其实蕴含了一个潜台词：许多应用对SSD的性能需求并不高。事实也确实如此。虽然现在依旧处于数据量爆炸的时代，但瓶颈主要集中在数据的处理，以及数据的存储成本上，性能相对不是那么迫切的问题。
在前面关于圆周率项目存储性能瓶颈的分析当中也可以看到：对于集群，网络带宽是多数应用瓶颈。对于机器学习这种吃性能的应用，瓶颈主要在内存墙，数据在内存、CPU、GPU、显存之间来回搬运，降低了计算效率，而不是元数据喂不饱CPU和GPU。所以用户对PCIe 5.0 SSD的需求并不迫切，甚至，PCIe 3.0 SSD的性能已经足够满足多数应用需求了。业界普遍预期PCIe 4.0 SSD的生命周期会很长。
另外，随着应用水平的提升，用户关注的价值点变得多元化，除了传输率、IOPS、时延等传统指标，还会关注能耗、可管理性、固件定制等等。对于高水平的用户，SSD也不再是传统的块存储设备，而是需要更深入其底层（如ZNS、OpenChannel等），或者转变应用形态（如内存语义SSD等）。
当然，SSD的性能也不至于到了可以故步自封的时候。除了前面提到的内存语义SSD、SCM等，机器学习对高性能、大容量SSD的需求其实就很“朴素”：用较少的PCIe通道数量达到足够的吞吐量或容量。对于机器学习、HPC等，多GPU、多网卡（含DPU）是常规操作，主板上的PCIe通道数量还是很紧张的。
4.为什么数据中心不追求单盘容量
从D5-P5316问世到现在已经两三年了，按说SSD的单盘容量早该进一步提升了，但貌似量产品的最大容量暂时停留在了30TB这个量级。为啥会停滞呢？简单说还是“有什么用”和“该怎么用”的问题。
首先，用户希望控制“爆炸半径”。最大容量如30TB级的SSD，主要客户是大型互联网和云计算公司，这些客户的特点是一台服务器要服务于多个应用和最终用户的访问，越大容量的SSD，承载的应用和用户数据也就越多，一旦（某个环节）发生故障，影响的业务和租户会比较多。如果把容量增加一倍，硬件技术上可行，但也需要在软件架构、用户信心、应用模式等方面有进一步的提升，需要云厂商和用户做出更多努力。
其次，是性能不划算。表面上，较高的单盘容量可以占用较少的空间、较低的能耗，但是，平均每单位容量的性能降低了——可以回想下谷歌云的SSD PD和平衡PD。对于同一代的SSD，容量较低的一两个型号的性能会低一些，之后各容量的性能就会大致相同。以云服务为例，虚拟机/实例的基本参数是CPU数量和存储容量，然后，根据吞吐量、IOPS提供分级的报价。如果配置大容量的SSD，那么，分配到每个实例容量所对应的IOPS可能会很低，缺乏竞争力。
当然，把接口升级到带宽加倍的PCIe 5.0可以暂时缓解单位容量性能下降的问题，但是前一个“紧箍咒”还在呢不是。
既然用户端没有强烈的愿望，那就要从技术和成本角度算算SSD进一步做大的难度了。譬如逻辑到物理的映射，容量越大，成本越高（想想TLB的占用）。前面提到的64KB IU是一种思路，但会付出应用范围变窄的代价，不具有普适性。要从根本上解决这种问题，最好还是动底层，如上一节提到的ZNS等。活跃在这个领域的是少数互联网大厂，以及全闪供应商。换句话说，这是用户的应用水平去决定的。所以，从标准化的块存储设备角度，SSD的发展恐怕还真得套用一下“公知体”：等一等软件和上层应用的发展。
