如何解决存储系统的“热点”问题

热点对于大部分应用来说都是一个麻烦。一个应用在多个设备之间发出请求，就必须受到物理上的输入/输出请求的限制。如果请求的延迟时间很长，而且数据索引的延迟时间也很长，那么应用程序的反应时间取决于SQL所建请求的最大延迟时间。结果当然是性能大大下降。

　　那么如何才能够对付这些讨厌的热点呢?当然，几乎所有的人都会说最好的解决热点的方法就是分散化数据，那么你就要用掉更多磁盘驱动器。但是我认为，基于各种原因，这是非常错误的做法。我将在这里探讨这种方法的利弊，并提供另一个解决这种问题的方法。记住，并不是所有人都相信的事情就一定是对的。地球不是平的。

　　简要回顾热点的历史

　　追溯到上个世纪90年代初，当时开放系统上的RAID(独立磁盘冗余阵列技术)还处于萌芽期，但是已经有一些使用于IBM主机上。EMC是RAID的领导者，而Veritas磁区管理也开始受到广泛使用。在我看来，正式由于这两个产品而产生了我们所谓的存储架构的"热点理论"。在那个时候，也许该理论就是这种问题的正确解决方案，但是我们现在有了其他工具来提供更好的解决方案。让我们看看当时的解决方法以及为什么这种方法是可行的。

　　当时开放系统上的文件系统是标准的UNIX文件系统，这种文件系统占据很小的分配空间，而且文件系统的元数据区域和数据区域混在一起。从主机角度来看，IBM MVS占主导地位，其文件系统是记录导向型的。这意味着大部分的UNIX文件系统的数据并不一定都要按顺序分配，而MVS的分配基础是记录，因此数据库也不是按顺序分配的。这个时期，许多UNIX系统的数据库用户使用裸设备。

　　从存储硬件角度来看，希捷公司推出了SCSI驱动器，给业界造成了轰动，他们替代了IP-3和其他类型的驱动器。下表显示了SCSI驱动器的进步。

对照现在的进步：

对照的几个关键点是：

　　读取整个磁盘驱动器所需时间从125秒增加到2400秒，是原来的19.2倍。

　　寻道加延迟时间从20.0毫秒减少道了7.69毫秒，原来所需时间是现在的2.7倍。

　　存储密度增加了600倍。

　　带宽增加了31.25倍。

　　磁盘虽然从2004年到现在变快了一些，但是幅度不大。综合以上所述事实，结论是读取整个磁盘的数据所需的时间大大增加了。举个例子，比如现在有一个8KB大小的数据库需要输入/输出。在1991年，按平均的寻道和延迟时间来计算，需要大约0.004秒来读取该数据。今天，只需要0.0008秒就可以了，是原来的五分之一。这意味着当进行小量输出/输出请求时，寻道和延迟时间很可能左右整体的性能水平。这无需奇怪，因为磁盘驱动器本来就是一个机械装置。这里有两点：

　　在UNIX系统下启动RAID、磁区管理软件和文件系统时，将数据分散到多个设备是提高性能的唯一方法，这是因为相对于寻道+延迟时间的进步，磁盘变慢了。

　　在早些时候，RAID高速缓存还很小，因此不能使用积极的预读和后写式工作模式。

　　因此，过去的情况就是：磁盘传输速率相对于寻道和延迟时间来说要快一些，文件系统将数据分成很小块，磁区管理和RAID分配都不大(小于128K)，积极的预读模式不现实，而数据库和应用程序也都相当小。因此，解决问题的唯一办法就是将它们分成越小越好;在当时这是完全合理和唯一可行的方法。这种情况一直持续到大概2001年或2002年。此后我们看到：

　　可以按顺序分配数据的文件系统，大的顺序分配超过32MB;

　　中端产品的RAID高速缓存的大小超过2GB，而企业产品则超过64GB;而且在切换到另一个设备之前，磁区管理可以按GB规模进行分配；

　　我们看到磁盘驱动器也在发生变化，传输速率的提升幅度远远超过寻道和延迟时间的减小幅度。

　　解决热点问题

　　任何一个精于存储的人士都知道这里没有万灵药，但是存储架构的热点理论却被视为存储的十大戒律之一。我并不是说这个理论是错的，但是我觉得这种方法有问题。比如说我有一个文件系统和磁区管理，分配64MB或以上的顺序分配数据。甚至还有一个RAID-5 8+1，也就是说，每个磁盘一个512KB的条带，那么将有16个顺序分配。想想这个。现在的希捷硬盘驱动器，每个驱动器都拥有16MB的高速缓存。假设所有都是随机的，那么进行磁盘预读不会帮助提升性能。而且，每次寻道和延迟过程中平均可以传输的数据量为读558KB，写608KB。这也就是数据传输在每次输入/输出请求时所损失的性能。

在考虑顺序分配之前，还有一个问题必须关注，即输入/输出请求是否是顺序的，这个问题甚至我也不能做出百分之百的回答。热点理论认为输入/输出请求是随机的。我相信它并不百分百适用于所有情况，但是我也不能给出适用和不适用的比例分别是多少。我知道在HPC(