第一页
热点对于大部分应用来说都是一个麻烦。一个应用在多个设备之间发出请求，就必须受到物理上的输入/输出请求的限制。如果请求的延迟时间很长，而且数据索引的延迟时间也很长，那么应用程序的反应时间取决于SQL所建请求的最大延迟时间。结果当然是性能大大下降。
那么如何才能够对付这些讨厌的热点呢？当然，几乎所有的人都会说最好的解决热点的方法就是分散化数据，那么你就要用掉更多磁盘驱动器。但是我认为，基于各种原因，这是非常错误的做法。我将在这里探讨这种方法的利弊，并提供另一个解决这种问题的方法。记住，并不是所有人都相信的事情就一定是对的。地球不是平的。
简要回顾热点的历史
追溯到上个世纪90年代初，当时开放系统上的RAID（独立磁盘冗余阵列技术）还处于萌芽期，但是已经有一些使用于IBM主机上。EMC是RAID的领导者，而Veritas磁区管理也开始受到广泛使用。在我看来，正式由于这两个产品而产生了我们所谓的存储架构的"热点理论"。在那个时候，也许该理论就是这种问题的正确解决方案，但是我们现在有了其他工具来提供更好的解决方案。让我们看看当时的解决方法以及为什么这种方法是可行的。
当时开放系统上的文件系统是标准的UNIX文件系统，这种文件系统占据很小的分配空间，而且文件系统的元数据区域和数据区域混在一起。从主机角度来看，IBM MVS占主导地位，其文件系统是记录导向型的。这意味着大部分的UNIX文件系统的数据并不一定都要按顺序分配，而MVS的分配基础是记录，因此数据库也不是按顺序分配的。这个时期，许多UNIX系统的数据库用户使用裸设备。
从存储硬件角度来看，希捷公司推出了SCSI驱动器，给业界造成了轰动，他们替代了IP-3和其他类型的驱动器。下表显示了SCSI驱动器的进步。
|
年份 |
SCSI/FC磁盘容量（GB） |
最大传输速率(MB/毫秒) |
寻道时间（毫秒） |
转速 |
延迟时间（毫秒） |
读取整体磁盘数据所需时间（秒） |
带宽（GB） |
|
1991 |
0.5 |
4 |
14 |
4412 |
6.8 |
125.0 |
0.13 |
|
1991 |
1.0 |
4 |
10.5 |
4500 |
6.67 |
250.0 |
0.25 |
|
1992 |
2.0 |
7 |
8 |
7200 |
4.17 |
285.7 |
0.29 |
|
1994 |
4.0 |
9 |
8 |
7200 |
4.17 |
444.4 |
0.44 |
|
1996 |
9.0 |
16 |
8.8 |
7200 |
4.17 |
580.6 |
0.58 |
|
表 1 | |||||||
对照现在的进步：
|
年份 |
SCSI/FC磁盘容量(GB) |
最大传输速率(MB/毫秒) |
寻道时间（毫秒） |
转速 |
延迟时间（毫秒） |
读取整体磁盘数据所需时间（秒） |
带宽（GB） |
|
2002 |
146.0 |
89 |
3.6 |
15000 |
2 |
1638.6 |
1.64 |
|
2004 |
300 |
125 |
4.7 |
15000 |
2.99 |
2400.0 |
2.40 |
|
表 2 | |||||||
对照的几个关键点是：
未完，请翻页
第二页
读取整个磁盘驱动器所需时间从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（高性能计算）领域，大部分应用的输入/输出请求是顺序的。我知道备份过程中的输入/输出请求经常是顺序的。我也知道一些数据库访问是随机的，但是我也知道我所实际看到和跟踪过的数据库有时会按顺序读取索引一段时间，然后是突然变化，接着继续按顺序读取。我在许多不同类型的数据库上看到这种情况出现过很多次，但不是所有数据库都是这样。如果是RAID-1的输入/输出请求是按顺序的，那么分配就可以是按顺序的，如果此时请求也是顺序的，那么预读模式就可以大大提高性能，最大的好处是，你用不着那么多硬件了，因为磁盘的效率提高了。
现在热点专家们声称他们的方法是提高存储架构性能的唯一方法，但如果你采取进一步行动，分析你的数据访问模式，并通过文件系统和磁区管理来合理地分配你的数据，那么你就可以获得更好的性能，而不用那么多硬件，并具有更好的进退空间。如果发展到基于对象的存储的阶段--我希望如此--那么通过对象技术就可以让系统智能地分辨数据访问模式并调整预读和后写工作模式。无论未来如何，我都认为人们需要重新思考这个问题，并摸索其他可以利用现有技术来解决问题的方案。
网友评论