第一页
热点对于大部分应用来说都是一个麻烦。一个应用在多个设备之间发出请求，就必须受到物理上的输入/输出请求的限制。如果请求的延迟时间很长，而且数据索引的延迟时间也很长，那么应用程序的反应时间取决于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 | |||||||
对照的几个关键点是：
未完，请翻页
网友评论