把 SSD 说个明白

上篇文章介绍了机械硬盘和固态硬盘：

硬盘的各种概念

。在文章里有说到固态硬盘只有一种访问方式，不管是顺序读写还是随机读写，SSD都没有寻址时间。但是有朋友来讨论固态硬盘的顺序和随机访问的速度问题，有一些矛盾点。今天就把事情说明白。

正文 1746 字，预计阅读时间 5 分钟。

顺序和随机怎么比？

一般来说，顺序访问用吞吐量（Throughput）做度量指标，而随机访问用每秒执行的请求数（IOPS）做度量指标，按说是没啥可比性的。但是如果没有可比性，我在实际编程的时候应该怎么选？难道因为没得比就随便选了？这显然不可能，因此还是要比的。但是怎么比？

以一个数据库系统来说，索引用B树或者LSM-tree，这是两种方向，一个主要利用随机写，一个顺序写。你给用户吹数据库性能的时候，主要是看数据库一秒钟能写多少数据量，到了应用层面没人管你磁盘的 IOPS 是多少。因此，还是要用吞吐量来比。

一种访问方式，顺序和随机速度不一样？

SSD 只有一种访问方式，但是有很多地方还会看到 SSD 的一些测试中，顺序和随机访问的吞吐量不一样，这不是矛盾么？不矛盾，这是工程实现的事。我们接下来看一看。

顺序读和随机读

以一个例子来说，逻辑地址是1到10000。假设都访问5个地址的数据，而且第一个地址是11，那么顺序读就读的是11-15的数据。SSD 中有并行度的概念，他可以并行的读，因此顺序读可以同时把后边的都读出来，这就是一个优化点。

而随机读可能读11，1205，250，520，1408。怎么做优化呢？当你给SSD发一个读请求的时候，他是不可能知道你后边要读什么的，那就没法做优化了吗？在 SSD 层面没法做优化了，但是可以在上层进行优化。我同时把 5 个地址发过去让 SSD 并行读就就行了。

这个就像跟直男打交道一样，如果你也是个顺序女，好，那他能猜出来你要干嘛，你很开心，但是你要是个随机女，那他绝对猜不出来你要干嘛。这时候最好的方式就是直接告诉他你的所有计划，让他去全力以赴，这样效率最高。

那我们看看，在 SSD 层面进行优化的顺序读和在应用层面优化的随机读谁牛逼一些：（图来自《WiscKey: Separating Keys from Values in SSD-Conscious Storage》）

这是用 ext4 文件系统上一个 100GB 的文件测的，可以看到，顺序读一直很牛逼。随着每次读的数据量的大小增大，单线程随机读的吞吐量也在逐渐上升，但还没追上顺序读。重点来了，当 32 线程并发随机读的时候，单次读数据量大于 16KB 的时候，随机读的吞吐量就能追上顺序读了，在 64KB 以上就完全一样了。

这个事情在 HDD 的时代是不可能的，这也是 SSD 牛逼的地方，这也是有的地方说 SSD 顺序读和随机读性能一样。而且 16KB 也不是一个很高的限制，很多地方应该都可以用到。

顺序写和随机写

再来看写入。在写一个文件的情况下，文件在逻辑上就是有序的一堆字节，这时候写入的区别主要是每次写入数据量的大小。（图来自《WiscKey: Separating Keys from Values in SSD-Conscious Storage》）

写一个 10GB 的文件，每次写入的数据量越大，总写入时间越短。这张图是顺序写的。基本到 4KB 就可以了。如果要往文件写数据，最好做个缓存。

关于顺序写和随机写，大家认为随机写对 SSD 是不好的。当 SSD 的剩余空间充足时，随机写的性能很好，但是当剩余空间不多时，随机写的性能会急剧下降。原因有两个：SSD block的擦除机制，垃圾回收。

关于垃圾回收，Seagate 给了一些解释（https://www.seagate.com/cn/zh/tech-insights/lies-damn-lies-and-ssd-benchmark-master-ti/），主要是在顺序写的时候无效数据比较整齐，回收的时候不用拷贝数据到新块，而随机写的时候无效数据块比较零散，会跟有效数据混在相同的块中，在擦除块时就需要将有效数据拷贝到新块，给垃圾回收带来了麻烦。

总结

顺序和随机访问如果要对比，就对比吞吐量。不管在机械硬盘还是固态硬盘，顺序读写总是好的，而且单次访问的数据量越大越好。固态硬盘的随机读可以通过并发和增加访问数据大小使得吞吐量和顺序读持平。写 SSD 的话还是尽量顺序写入。