为了满足更多用户在存储和检索大量数据、提供丰富与个性化体验、及时响应点击与手势的要求，新型互联网与移动应用需要高I/O资源。为此，亚马逊AWS旨在EC2中加入一个新的“家庭成员”：运行低延迟、I/O密集型应用、支持NoSQL数据库如Cassandra和MongoDB的新实例，打破了一直存在于云世界的I/O瓶颈。真金不怕火炼，让我们来看看新的I/O体系究竟如何！
测试基准的制定
去年公布的Apache Cassandra performance benchmark显示，用数百个非常小的EC2实例就可以获得类似每秒超过百万客户端进行写入的效果。之前测试了用于Cassandra上建立和管理软件Priam的扩展性，并证明了，大规模的Cassandra集群按线性扩大，也就是10倍数量的实例将让你获得10倍的吞吐量。现在我们发布了一些基准它能体现出在原有类型系统和新的基础SSD的系统上运行Cassandra的对比。
AWS实例中的I/O元素摘要
已有几个临时的储存元素被存于网络磁盘中，它们将在实例结束后被删除。基于现有内部磁盘在Cassandra环境中进行的测试对比，主要采用了四个方案：m1.xlarge、m2.4xlarge、cc2.8xlarge以及现在加入的SSD hi1.4xlarge。AWS CPU性能对应了EC2的每一种实例。
我们首先在拥有最好CPU平衡性的Netflix上使用m2.4xlarge来运行Cassandra，尽管我们还必须通过调度每一个节点的精简和修复来不让I/0过载，但CPU和RAM容量仍然为我们工作的重中之重。
基于SSD实例上的hi1.4xlarge
这种新的基于SSD的类型实例在临时存储中提供了很高性能。在/proc/cpuinfo的报告中显示CPU为2.4GHz拥有8个核心和超线程技术的Intel Westmere E5620 ，这样就拥有了16个CPU线程。其CPU性能上介于m2.4xlarge和cc2.8xlarge之间，相同的RAM容量，和cc2.8xlarge同样的10GB网络接口。
磁盘的结构为两个1TB左右大的SSD，使实例能胜任100000左右的低延迟IOPS和1GB每秒的吞吐量。新的基于SSD的实例能提供数百倍于其他储存方式的吞吐量，以及极低延迟。
测试结果
首先，对于一个新的子系统，我们必须做基础文件系统的性能等级测试，我们使用izone测试准则来查证我们在当前的磁盘条件下一个非常短的时间内（大约20—60/ms）是否可以得到100000的IOPS和1GB/S的吞吐量。
然后我们用Cassandra的压力测试来用简单的数据存储模式对一个小型的数据集进行存储，类似我们去年公布的准则。我们发现我们的测试经常受到CPU限制，但是在启动的那小段时间随着数据加载进存储器，我们仍然可以在磁盘上得到接近1GB/每秒的吞吐量。
接着就是更多的混合，我们取出我们储存在Cassandra中最大的数据和从备份中恢复两份拷贝。一份在m2.4xlarge上，另一份在hi1.4xlarge上，这样我们就可以得出在同等的条件下以SSD为基础的新模块究竟有多完善。下一个将会是最有意思的对比。
Netflix的应用基准测试
我们的架构是精细入微的，每一个开发团队都拥有自己的一套服务和数据存储。结果就是，我们的产品中拥有十个Cassandra集群，每一个都服务于不同的数据源。我们从中抽取一个拥有静态数据提供应用程序的集群，该应用程序使用了聘美于Cassandra为写操作提供的缓存层来完成读的工作。我们的目的是想知道，在不使用系统缓存的情况下使用SSD是否会带来延迟。用EVcache来管理缓存层。下面是两项配置的对比：
现有的系统： 48 Cassandra> 
成本对比
在使用基于SSD模式的系统中，瓶颈从I/O转换到CPU上，我们就可以大量的减少实例个数。参照了现有的收费体系，完全可以通过减少实例数量来减少花费。
将Cassandra上的工作放到SSD上的优势
同吞吐量的成本大幅降低
大幅提升I/O的速度，降低延时
总结
这是AWS一次突破性的提升，无疑的克服了应用程序受制于数据库连接的囧境，给云端的人们带来了福音。我们期待作为云世界的领跑者Aamazon能一直与时俱进，为云世界的开拓和完善做出新的贡献。