优化建议：存储性能优化。

柔情只为你懂 2024-04-17 05:38 77阅读 0赞

在网站应用中，海量的数据读写对磁盘访问造成巨大压力，虽然可以通过Cache解决一部分数据读压力，但是很多时候，磁盘仍然是系统最严重的瓶颈。而且磁盘中存储的数据是网站最重要的资产，磁盘的可用性和容错性也至关重要。

# 机械硬盘 VS 固态硬盘 #

机械硬盘是目前最常用的一种硬盘，通过马达驱动磁头臂，带动磁头到指定的磁盘位置访问数据，由于每次访问数据都需要移动磁头臂，因此机械硬盘在数据连续访问（要访问的数据存储在连续的磁盘空间上）和随机访问（要访问的数据存储在不连续的磁盘空间）时，由于移动磁头臂的次数相差巨大，性能表现差别也非常大。机械硬盘结构如下图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70][]

固态硬盘又称作SSD或Flash硬盘，这种硬盘没有机械装置，数据存储在可持久记忆的硅晶体上，因此可以像内存一样快速随机访问。而且SSD具有更小的功耗和更少的磁盘震动与噪声。SSD硬盘如下图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 1][]

在网站应用中，大部分应用访问数据都是随机的，这种情况下SSD具有更好的性能表现。但是目前SSD硬盘还不太成熟，可靠性、性价比有待提升，因此SSD的使用还在摸索阶段。但是相信随着SSD工艺水平的提高，逐步替代传统机械硬盘是迟早的事。

# B+树 VS LSM树 #

由于传统的机械磁盘具有快速顺序读写、慢速随机读写的访问特性，这个特性对磁盘存储结构和算法的选择影响甚大。  
为了改善数据访问特性，文件系统或数据库系统通常会对数据排序后存储，加快数据检索速度，这就需要保证数据在不断更新、插入、删除后依然有序，传统关系数据库的做法是使用B+树，如下图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 2][]

B+树是一种专门针对磁盘存储而优化的N叉排序树，以树节点为单位存储在磁盘中，从根开始查找所需数据所在的节点编号和磁盘位置，将其加载到内存中然后继续查找，直到找到所需的数据。  
目前数据库多采用两级索引的B+树，树的层次最多三层。因此可能需要5次磁盘访问才能更新一条记录（三次磁盘访问获得数据索引及行ID，然后再进行一次数据文件读操作及一次数据文件写操作）。  
但是由于每次磁盘访问都是随机的，而传统机械硬盘在数据随机访问时性能较差，每次数据访问都需要多次访问呢磁盘影响数据访问性能。  
目前许多NoSQL产品采用LSM树作为主要数据结构，如下图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 3][]

LSM树可以看作是一个N阶合并树。数据写操作（包括插入、修改、删除）都在内存中进行，并且都会创建一个新纪录（修改会记录新的数据值，而删除会记录一个删除标志），这些数据在内存中仍然还是一棵排序树，当数据量超过设定的内存阈值后，会将这棵排序树和磁盘上最新的排序树合并。当这棵排序树的数据量也超过设定阈值后，和磁盘上下一级的排序树合并。会用最新更新的数据覆盖旧的数据（或者记录为不同版本）。  
在需要进行读操作时，总是从内存中的排序树开始索引，如果没有找到，就从磁盘上的排序树顺序查找。  
在LSM树上进行一次数据更新不需要磁盘访问，在内存即可完成，速度远快于B+树。当数据访问以写操作为主，而读操作则集中在最近写入的数据上时，使用LSM树可以极大程度减少磁盘访问次数，加快访问速度。  
作为存储结构，B+树不是关系数据库独有的，NoSQL数据库也可以使用B+树。同理，关系数据库也可以使用LSM，而且随着SSD硬盘的日趋成熟及大容量持久存储的内存技术的而出现，相信B+树这一“古老”的存储结构会再次焕发青春。

# RAID VS HDFS #

RAID（廉价磁盘冗余阵列）技术主要是为了改善磁盘的访问延迟，增强磁盘的可用性和容错能力。目前服务器级别的计算机都支持插入多块磁盘（8块或者更多），通过使用RAID技术，实现数据在多块磁盘上的并发读写和数据备份。  
常用RAID技术有以下几种，如下图所示。

![20190823110310432.png][]

假设服务器有N块磁盘。

## RAID0 ##

数据在从内存缓冲区写入磁盘时，根据磁盘数量将数据分成N份，这些数据同时并发写入N块磁盘，使得数据整体写入速度是一块磁盘的N倍。读取时也一样，因此RAID0具有极快的数据读写速度，但是RAID0不做数据备份，N块磁盘中只要有一块损坏，数据完整性就被破坏，所有磁盘的数据都会损坏。

## RAID1 ##

数据在写入磁盘时，将一份数据同时写入两块磁盘，这样任何一块磁盘损坏都不会导致数据丢失，插入一块新磁盘就可以通过复制数据的方式自动修复，具有极高的可靠性。

## RAID10 ##

结合RAID0和RAID1两种方案，将所有磁盘平均分成两份，数据同时在两份磁盘写入，相当于RAID1，但是在每一份磁盘里面的N/2块磁盘上，利用RAID0技术并发读写，既提高可靠性又改善性能，不过RAID10的磁盘利用率较低，有一半的磁盘用来写备份数据。

## RAID3 ##

一般情况下，一台服务器上不会出现同时损坏两块磁盘的情况，在只损坏一块磁盘的情况下，如果能利用其他磁盘的数据恢复损坏磁盘的数据，这样保证可靠性和性能的同时，磁盘利用率也得到大幅提升。  
在数据写入磁盘的时候，将数据分成N-1份，并发写入N-1块磁盘，并在第N块磁盘记录校验数据，任何一块磁盘损坏（包括校验数据磁盘），都可以利用其他N-1块磁盘的数据修复。  
但是在数据修改较多的场景中，修改任何磁盘数据都会导致第N块磁盘重写校验数据，频繁写入的后果是第N块磁盘比其他磁盘容易损坏，需要频繁更换，所以RAID3很少在实践中使用。

## RAID5 ##

相比RAID3，方案RAID5被更多的使用。  
RAID5和RAID3很相似，但是校验数据不是写入第N块磁盘，而是螺旋式的写入所有磁盘中。这样校验数据的修改也被平均到所有磁盘上，避免RAID3频繁写坏一块磁盘的情况。

## RAID6 ##

如果数据需要很高的可靠性，在出现同时损坏两块磁盘的情况下（或者运维管理水平比较落后，坏了一块磁盘但是迟迟没有更换，导致又坏了一块磁盘），仍然需要修复数据，这时候可以使用RAID6。  
RAID6和RAID5类似，但是数据只写入N-2块磁盘，并螺旋式的在两块磁盘中写入校验信息（使用不同算法生成）。  
在相同磁盘数目（N）的情况下，各种RAID技术的比较如下表所示。

<table> 
 <thead> 
  <tr> 
   <th>RAID类型</th> 
   <th>访问速度</th> 
   <th>数据可靠性</th> 
   <th>磁盘利用率</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>RAID0</td> 
   <td>很快</td> 
   <td>很低</td> 
   <td>100%</td> 
  </tr> 
  <tr> 
   <td>RAID1</td> 
   <td>很慢</td> 
   <td>很高</td> 
   <td>50%</td> 
  </tr> 
  <tr> 
   <td>RAID10</td> 
   <td>中等</td> 
   <td>很高</td> 
   <td>50%</td> 
  </tr> 
  <tr> 
   <td>RAID5</td> 
   <td>较快</td> 
   <td>较高</td> 
   <td>(N-1)/N</td> 
  </tr> 
  <tr> 
   <td>RAID6</td> 
   <td>较快</td> 
   <td>较（RAID5）高</td> 
   <td>(N-2)/N</td> 
  </tr> 
 </tbody> 
</table>

RAID技术可以通过硬件实现，比如专门的RAID卡或者主板直接支持，也可以通过软件实现。RAID技术在传统关系数据库及文件系统中应用比较广泛，但是在大型网站比较喜欢使用的NoSQL，以及分布式文件系统中，RAID技术却遭到冷落。  
例如在HDFS（Hadoop分布式文件系统）中，系统在整个存储集群的多台服务器上进行数据并发读写和备份，可以看作在服务器集群规模上实现了类似RAID的功能，因此不需要磁盘RAID。  
HDFS以块（Block）为单位管理文件内容，一个文件被分割成若干个Block，当应用程序写文件时，每写完一个Block，HDFS就将自动复制到另外两台机器上，保证每个Block有三个副本，即使有两台服务器宕机，数据依然可以访问，相当于实现了RAID1的数据复制功能。  
当对文件进行处理计算时，通过MapReduce并发计算任务框架，可以启动多个计算子任务（MapReduce Task），同时读取文件的多个Block，并发处理，相当于实现了RAID0的并发访问功能。  
HDFS架构如下图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 4][]

在HDFS中有两种重要的服务器角色：NameNode（名字服务节点）和DataNode（数据存储节点）。NameNode在整个HDFS中只部署一个实例，提供元数据服务，相当于操作系统中的文件分配表（FAT），管理文件名Block的分配，维护整个文件系统的目录树结构。DataNode则部署在HDFS集群中其他所有服务器上，提供真正的数据存储服务。  
和操作系统一样，HDFS对数据存储空间的管理以数据块（Block）为单位，只是比操作系统中的数据块（512字节）要大得多，默认为64MB。HDFS将DataNode上的磁盘空间分成N个这样的块，供应用程序使用。  
应用程序（Client）需要写文件时，首先访问NameNode，请求分配数据块，NameNode根据管理的DataNode服务器的磁盘空间，按照一定的负载均衡策略，分配若干数据块供Client使用。  
当Client写完一个数据块时，HDFS会将这个数据块再复制两份存储在其他DataNode服务器上，HDFS默认同一份数据有三个副本，保证数据可靠性。因此在HDFS中即使DataNode服务器有多块磁盘，也不需要使用RAID进行数据备份，而是在整个集群上进行数据复制，而且系统一旦发现某台服务器宕机，会自动利用其他机器上的数据将这台服务器上存储的数据块自动再备份一份，从而获得更高的数据可靠性。  
HDFS配合MapReduce等并行计算框架进行大数据处理时，可以在整个集群上并发读写访问所有的磁盘，无需RAID支持。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/9d8ec26ad22e4eaab7d2a2e210636966.jpg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/0616a4b8def54a6c867ee24d80ea81fc.jpg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/b35698f4ee334b3a89640f12227b0837.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/9aa8d902a6234675aa534d961a04098e.png
[20190823110310432.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/eb2fe47c76934482964c7f3246e6f1c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/11/056de3a89aa74a9c9c49233c18172725.png