4.4 存储性能优化
前面虽然通过缓存可以减轻一部分数据访问的压力，但是很多时候，磁盘仍然是系统最严重的瓶颈。
而且磁盘是网站最重要的资产，磁盘的可用性和容错性至关重要。
4.4.1 机械硬盘vs.固态硬盘
机械硬盘适合顺序访问
固态硬盘适合随机访问
4.4.2 B+树 vs LSM树
为了改善数据访问特性，文件系统或数据库通常会对数据排序后存储，这就需要不断在数据增删改时，不断的变化顺序。对于B+树，就是通过左旋和右旋操作维持树的平衡，保持树的高度。
B+树是一种专门针对磁盘存储而优化的N叉排序树，以树节点为单位存储在磁盘中，从根开始查找所需数据所在的节点编号和磁盘位置，将其加载到内存中然后继续查找，直到找到所需的数据。
目前数据库多采用两级索引的B+树，树的层次最多三层。因此可能需要5次磁盘访问才能更新一条记录(三次磁盘访问获得数据索引及行ID，然后再进行一次数据文件读操作及一次数据文件写操作)。
但是由于每次磁盘访问都是随机的，而传统机械硬盘在数据随机访问性能较差，每次数据访问都需要多次访问磁盘影响数据访问性能。
许多NoSQL产品采用LSM树作为数据结构。
LSM树可以看作是一个N阶合并树。数据写操作都在内存中进行，并且都会创建一个新纪录(修改会记录新的数据值，而删除会记录一个删除标志)，这些数据在内存中仍然还是一颗排序树，当数据量超过设定的内存阈值后，会将这棵排序树和磁盘上最新的排序树合并。当这棵排序树的数据量也超过设定阈值后，和磁盘上下一级的排序树合并。合并过程中，会用最新更新的数据覆盖旧的数据(或者记录为不同的版本)。
在需要进行读操作时，总是从内存中的排序树开始搜索，如果没有找到，就从磁盘上的排序树顺序查找。
在LSM树上的数据更新操作不需要磁盘访问，速度比较快。
当数据访问以写操作为主，而读操作则集中在最近写入的数据上时，使用LSM树可以极大程度地减少磁盘的访问次数，加快访问速度。
手写B+树和LSM树，感受下
4.4.3 RAID vs HDFS
各种RAID方案提供了一些数据存储安全性，空间利用率上的思路，但是，大型网站喜欢使用NoSQL、分布式文件系统。
HDFS是Hadoop分布式文件系统，在HDFS中，系统在整个存储集群的多台服务器上进行数据并发读写和备份，可以看作在服务器集群规模上实现了类似RAID的功能，因此不需要磁盘RAID。
HDFS以块(block)为单位管理文件内存，一个文件被分割为若干个Block，当应用程序写文件时，每写完一个Block，HDFS就将其自动复制到另外两台机器上，保证每个Block有三个副本，即使有两台宕机，数据依然可以访问，相当于实现了RAID1的数据复制功能。
当文件进行处理计算是，通过MapReduce并发计算任务框架，可以启动多个计算子任务(MapReduce Task)，同时读取文件的多个Block，并发处理，相当于实现了RAID0的并发访问功能。
小结：
HDFS将一个文件分成若干block，每一个block有存储多分，不把鸡蛋放在一个篮子，也是分治的思想，访问的时候可以并发访问多个block。
在HDFS中有两种重要的角色：NameNode和DataNode。NameNode在整个HDFS中只部署一个实例，提供元数据服务，相当于操作系统中的文件分配表(FAT)，管理文件名Block的分配，维护整个文件系统的目录树结构。DataNode则部署在HDFS集群中其他所有服务器上，提供真正的数据存储。
和操作系统一样，HDFS对数据存储空间的管理一数据块(Block)为单位，只是比操作系统中的数据块(512字节)大，默认是64M。HDFS将DataNode上的磁盘空间分成N个这样的块，供应用程序使用。
应用程序需要写文件时，首先访问NameNode，请求分配数据块，NameNode根据管理的DataNode服务器的磁盘空间，按照一定的负载均衡策略，分配若干数据块供Client使用。
当Client写完一个数据块时，HDFS会将这个数据块再复制两份存储在其他DataNode服务器上，HDFS默认同一份数据有三个副本，保证数据可靠性。因此在HDFS中，即使DataNode服务器有多块磁盘，也不需要使用RAID进行数据备份，而是整个集群上进行数据复制，而且，而且系统一旦发现某台服务器宕机，会自动利用其他机器上的数据将这台服务器上存储的数据块自动再备份一份，从而得到更到的数据可靠性。
HDFS配置MapReduce等并行计算框架进行大数据处理时，可以在整个集群上并发读写访问所有的磁盘，无需RAID支持。
4.5 小结
网站的性能问题很多是在用户高并发访问时产生的，所以网站性能优化的主要工作是改善高并发访问情况下的网站响应速度。
网站的性能对最终用户来说是一种主观感受，用户体验快慢可以通过技术手段，也可以通过优化交互体验改善。
即使在技术层面，也要综合权衡：
性能提升一倍，但服务器数量也需要增加一倍；
或者响应时间缩短，同时数据一致性也下降，这样的优化是否可以接受？
这种问题不是技术团队能回答的。
归根结底，技术时为业务服务的，技术选型和架构决策依赖业务规划乃至企业发展规划，离开业务发展的支撑和驱动，技术走不远，甚至还会迷路。
个人感受：光是看书真的没用，把一些点记下来，自己排版，删减，总结，看起来花时间，实则最省时间，有空多翻一翻。