存储系统瓶颈往往在于I/O，因此需要对I/O有一个整体而清晰的认识，也算是一次总结。I/O涉及的范围比较广，包括硬件架构和网络结构等方面，本篇文章试图从应用层面来分析：

1、性能参数

I/O顾名思义就是数据输入和输出，在计算机中，不同的硬件或者介质I/O性能表现是不同的，下面是常见硬件性能参数。
从上表可以看出，「千兆网络发送1MB数据」、「异地机房之间网络来回」、「SATA磁盘寻道」、「从SATA磁盘顺序读取1MB数据」是比较消耗时间的，都是10ms级别的。 因此我们在设计存储引擎的时候需要考虑如下因素：减少在网络间传输数据（特别是跨机架甚至跨机房）、减少发生磁盘寻道。

2、案例分析

所有的存储引擎在设计时候都需要根据业务需求（写多还是读多）设计解决方案来提高I/O效率。以HDFS为例来说明，看它是如何设计的。

2.1、数据冗余策略

Client申请将数据写入HDFS中，HDFS默认会将数据存3个副本（可以设置，默认为3）。
第一个副本放在Client所在的DataNode上（如果Client不在集群中，则随机选取一个负载较低的DataNode）
第二个副本放在与第一个副本节点不同机架中的DataNode（随机）
第三个副本放在与第二个副本节点同一个机架中另外一个DataNode节点（随机）

数据放在不同机架中是为了可靠性（机架的单点故障）。
后两个副本放在同一个机架是为了减少数据在网络节点中传输，看下图：

2.2、Combiner

以HDFS为数据存储的基础之上，是MapReduce计算框架，分为两个阶段Map和Reduce，流程可以参考下图：

数据在网络间传输发生在Shuffle阶段，Shuffle是指将Map输出的结果排序并按Key哈希分发到Reduce节点的过程，这个过程不可避免，所以只能尽量减少传输的数据量。 Combiner就是在Map端对数据进行一次本地Reduce，对数据量进行一次瘦身，但是必须保证对最终Reduce的结果没有影响，例如求最大值的MapReduce程序，只需要传输Map输出结果最大的那个值。

如何优化Shuffle减少传输的数据量是MapReduce优化的重点。例如Spark的Shuffle实现，可以参考这里。

2.3、HDFS块大小

HDFS默认块大小是64MB，如果太小就会增加磁盘寻道的时间，如果太大造成Map执行时间过长，因为Map任务通常一次处理一个块的数据。所以块的大小设置直接影响MapReduce的性能。

3、方法总结

I/O优化策略可以简单的从上面两个方面来入手，同时需要结合相应的业务需求（系统吞吐量和响应时间、可用性（99.99）、一致性、可扩展性），来选择合适的解决方案。常见的优化手段有：

成组提交：REDO日志先放在内存缓存区中，然后定期顺序写入磁盘，提供效率
checkpoint（检查点技术）：解决内存不足无法缓存所有的更新操作
数据压缩：减少数据量，提高写入和传输速度。

        original link:
        <a href='http://findhy.github.io/blog/2014/03/16/io/'>http://findhy.github.io/blog/2014/03/16/io/</a><br/>
        written by <a href='http://findhy.github.io'>Findhy</a>
        &nbsp;posted at <a href='http://findhy.github.io'>http://findhy.github.io</a>
        </p>