最近一直在测试一款让我非常兴奋的存储介质： Fusion IO 的 ioDrive。他在随机小IO的方面的表现，实在是让我吃惊，可以轻松达到100k左右的单一读（或者写）（注意是写也可以达到这个数据） IOPS，读写混合也可以达到 50k～60k左右的IOPS，而且这个 IOPS 数据还是在响应时间低于5ms 的情况下的数据。而实际上，当 IOPS 达到50k 的时候，响应时间仍然低于1ms。

    注：测试工具为 orion/fio/iometer

    100K 的 IOPS 是一个什么概念？

    假如我们使用 15k 转速的 SAS 磁盘来对比，每块磁盘的 IOPS 大概 150 左右，那么一块 ioDrive 的 IOPS 表现就相当于 100k/150=666.66 块 15k 转速的 SAS 磁盘并行的能力，而且每个 IOPS 的响应时间还得 5～7ms（机械原理决定） 。这样的 IOPS 能力，恐怕也只有 EMC ， HDS 等高端存储厂商们的顶级存储设备才能够达到如此高的 IOPS 性能了。

    ioDrive 为啥能达到如此之高的 IOPS 而且还能保持极小的响应时间？

    Fusion IO 的 ioDrive 产品其本质就是当前存储界炒的非常热的 SSD ，而非传统的机械磁盘。但其他厂商的 SSD 磁盘的性能和 ioDrive 相比，实在是还有一段不小的差距，这是为什么？那就要看下面这个原因了。

    常见的 SSD 设备大多是通过实现标准的 ATA 接口协议，连接在RAID/SAS 等磁盘控制器上，以传统的访问路径提供IO服务。但 Fusion IO 在这一点的处理上与其他人有很大的差异，他们通过在 Linux 内核中增加内核模块，与自己独有的驱动配合，绕过多道传统磁盘需要经由的路径，大大缩短了 IO 操作路径。

    二者的IO访问路径可以简单表示如下：

    传统的磁盘包括目前大部分的 SSD ： CPU ―> 北桥 ―> 南桥 ―> SAS/RAID 控制器 ―> 背板 ―> 磁盘（SSD/机械盘）。

    Fusion IO 的 ioDrive： CPU ―> 北桥 ―> PCIe 控制器 ―> ioDrive

    可以看出，ioDrive 减少了 “―> 南桥 ―> SAS/RAID 控制器 ―> 背板” 这一过程，所以在响应时间上肯定有较大优势。而且，这一过程上RAID/SAS 控制器可能造成的瓶颈也就不会对 ioDrive 造成任何影响了。

    普通 SSD 磁盘大多包含有自己的芯片用于内部调度计算，但 ioDrive 却使用主机的CPU来进行调度，对于大多数 IO 密集型系统来说，CPU 资源总是会有较大富余，而 ioDrive 正是利用了这一点来更好的利用了主机资源，同时提高了自己的计算能力，因为主机 CPU 的计算能力肯定要比集成在 SSD 磁盘上中的那个小芯片要强很多。

    此外其实还有在Firmware上的 IO 调度方面的一些多通道，并行等特殊优化，也给 ioDrive 的高 IOPS 表现带来了很大的帮助。

    之前一直不明白为什么 Fusion IO 称他们的 ioDrive 为 ioMemory，当时还以为只是他们在玩概念忽悠人，不过在听了 Brad Pfefer 和 Jens Axboe (http://en.wikipedia.org/wiki/Jens_Axboe) 二人的相关介绍后，总算明白了，确实还是有点道理的。

    从我个人的认知来说，ioDrive 确实可以说是一款具有革命性的存储介质产品，或许在不久的将来，io 访问模型都将是如 ioDrive 一样，先自己 YY 一下吧。

建议继续学习：

1. HFile存储格式    (阅读：14539)
2. 我对技术方向的一些反思    (阅读：9874)
3. 淘宝图片存储架构    (阅读：9838)
4. 海量小文件存储    (阅读：7558)
5. HBase技术介绍    (阅读：6761)
6. 存储基础知识之——硬盘接口简述    (阅读：6157)
7. 在perl中连接和使用sqlite做数据存储    (阅读：5059)
8. 如果用户在5分钟内重复上线，就给他发警告，问如何设计？    (阅读：4873)
9. HTML5本地存储初探(二)    (阅读：4398)
10. Redis新的存储模式diskstore    (阅读：4409)