现在存储都喜欢搞性能军备竞赛，世界上最大的组织者就是SPC，各大存储厂商都在其中。目前SPC-1性能的世界冠军是华为OceanStor18000V3，而SPC-2性能冠军则是HPE3PARStoreServ20850。
没有参加测试的其他产品，厂商也往往提供一些参数，比如100万IOPS，在4K100%读的情况下，如果读写比例是70/30，那么性能变为80万IOPS。
用户一般把这些测试叫做herotest。很多用户认为，这些理想测试和自己现实的工作负载差距太大，对它没有什么用。
其实不然，如果你了解你自己的应用I/O，这些herotest还真是可以帮你评估那些存储比较适合你的要求。
大家知道，存储的性能主要和数据块的大小和读写的比例有关。但不同的产品有不同的设计理念，比如XtremIO针对4K负载进行优化，Pure则针对读进行优化，而Nimble则针对重度写进行优化。如果你了解自己的应用对存储的特征，那么理论上来说比较容易找到匹配你应用模式的存储，达成最优。
但用户如何知道自己的应用的负载情况呢？而且要从外部存储的角度来看，因为现代的服务器有大量的Cache，很多读写I/O都在服务器消化了，落到外部存储的I/O特性才有价值。
NimbleStorage公司刚刚发布一款AFA，西瓜哥朋友圈很多人刷屏，以后有时间我再给大家解读。但Nimble的产品，最大的特点不是硬件产品，而是其基于云和大数据的维护平台InfoSight。业界能和其媲美的还有Pure的Pure1。
这个InfoSight的厉害之处就是收集所有的install-base的产品信息，进行大数据分析，然后给用户维护建议，并且可以建立自己的数据库，改善产品。
虽然收集是匿名的，在海外不是问题，但在中国基本行不通。几乎没有用户愿意把产品的运行状况实时在线报送给厂商（高端存储除外），只有出问题的时候允许厂商远程维护。更多是安全考虑，其实也是社会的信任机制不完善所致。因此，中国的厂商只能有羡慕的份，而Nimble和Pure进入中国国内，也可能失去最有竞争力的这个优势。
不过，InfoSight的大数据统计结果，对存储厂商和客户来说，确实有很多参考的价值。首先，Nimble说其已经有了几千个客户，数据量够大；第二，这是用户的真实场景，而且是从存储侧观察到的。
今天，我们就分享一下从InfoSight在去年2月份这1个月收集的数据。我们主要通过其收集的数据来了解真实的应用负载是怎样的，特别是一些通用的负载，我们完全可以借鉴。
首先，我们来看一下现实环境中，IO的大小分布到底是怎样的？
从上面的统计我们可以看出：
>60%的写是小于8K的；
>50%的读小于16K;
另外，IO大小呈两极分化。
>50%的IO大小在4K（包括）和16K（不包括）之间
>20%的IO大小在64K（包括）和256K（不包括）之间
只有~15%的IO大小在16K(包括）到64K（不包括）之间
也就是说，现实生活是一种两极分化的模式。因此我们的存储设计的时候，要重点考虑4-16K和64-256K这个区间的性能。
有些存储厂商不是这么设计的，而32K大小来进行系统优化。因为他们认为I/O的平均大小是32K。这种设计理念并不好。
确实，IO全部平均起来，每个阵列的平均IO大小大部分落在16-64K的区间。
但是，上面的第一个图我们已经很清楚，这个区间的I/O是很少的，并不典型。因此，采用平均IO大小的模型来评估性能是不科学的。
InfoSight也给出了很多典型应用的IO大小的分布情况，关键还有读写比例。我们一块来看一下。
这是VDI的负载的IO分布，我们看到4-8K是最典型，读写比例是91:9。这种场景下，可以参考厂商提供的4K100%读的herotest结果，还是有意义的。当然要看配置相似的情况。
Splunk应用是一款日志分析软件，其典型IO也是4-8K，但读写比例是21:79。这种明显是写多读少的场景，应用优先考虑对读优化得比较好的产品。
SQLSERVER数据库典型IO是8-16K和64-128K，也是一种双峰的状态。读写的比例是63:37。
ORACLE数据库IO典型集中在8-16K，读写比例是65:35。
Exchange2013在4-8K，64-256K都有大量的分布，读写比例是63:37。
但是Exchange2010则又不同，大量分布在32-512K，读写比例75:25。
Exchange2007则集中在8-16K范围，读写比例是92:8。
Exchange2003集中在4-8K，读写比例是91:9。
从Exchange不同版本的对比我们可以看到，其IO特征差距是非常大的。这个要特别注意。
最后看一下文件服务，IO在4-512K之间比较分散，读写比例79:21。
从上面的数据我们可以看出，设计一款通用的存储是比较困难的，因为IO模式差距比较大。但大部分情况，4-16K的IO大小，70:30的读写比例，这个区间的I/O是比较典型的。如果设计一款通用的存储，可能重点的优化区间就是这个了。
厂商通过收集其产品的运行数据，确实能够帮助用户运维，更重要的是可以改进自己的产品。Nimble是每4小时采集一次产品的运行数据，形成自己强大的信息库。今天展示的只是负载方面的信息，还有运行时间，宕机时间，各个版本的分布情况，集群的比例，压缩比信息等等，这些对厂商来说都是无价之宝。Nimble也因此敢提供7年多的维保，而且宣传不靠收维保费来盈利。
