多年来,数据库管理员和数据库应用程序开发人员在实现关键事务性、数据仓库或混合工作负载时,一直都在绞尽脑汁进行存储布局和磁盘配置。为了取得高效的 I/O,他们花费大量的时间和金钱来设计和优化应用程序。

  现在,大多数常用的企业硬盘驱动器(HDD)都受到磁头移动速度、盘片旋转速度和查找延时的限制。固态硬盘驱动器(solid-state drive,SSD,也称闪存驱动器)可以解决这些挑战,它提供快速、低延时数据访问,并减少能源消耗(IOPS/watt);图 1 显示 SSD 与企业 HDD 在一些关键指标上的大致比较。最近,SSD 的密度已经大大提高;已经出现 200 GB 以上的驱动器,并且在未来 6 个月内容量有望再次翻番。如此急剧的进步使得 SSD 成为性能敏感或关键任务数据库应用程序的首选。

  在很多情况下,组织可以把所有数据库放在 SSD。但是,虽然 SSD 的成本每个季度都在递减,但是 SSD 仍然比 HDD 昂贵。不过,有了 IBM DB2,组织就可以将精心挑选的数据迁移到更高性能的存储媒介,从而提高应用程序整体性能。本文探索 IBM 的一个团队如何用在线事务处理(OLTP)工作负载下的 DB2 来测试 SSD 的行为,以及如何发现挑选数据放到 SSD 上的方式,使有限的 SSD 资源带来最大的好处。

  将 SSD 存储用于 DB2

  DB2 提供的丰富的分区选项使您可以利用不同类型的存储。特别是,可以使用范围分区将大型表和索引划分到较小的按范围(通常是数据范围,但也可能是其他参数)组 织的分区中,并将它们放到由 SSD 存储支持的不同表空间中。然后,随着较旧的数据使用率下降,再使用 DB2 的范围分区特性将较新的数据转入常用或“热”表空间。

 


  为了利用低延时的 SSD 资源,还可以挑出热表,然后使用 ADMIN_TABLE_ MOVE 存储过程将这样的表转移到 SSD 存储所支持的表空间上。

  选择热数据对于充分利用 SSD 资源十分有益。SSD 最适合随机 I/O,与连续 I/O 相对 HDD 提升 10 倍性能相比,SSD 相对 15,000 rpm HDD 可以提升超过 100 倍性能(以 IOPS 度量)。

  为了证实 DB2 对象在 SSD 上的性能效果,我们选择一个 IBM DB2 OLTP 工作负载来进行一系列的测试,首先以所有数据库文件放在 HDD 上的场景作为基准。当我们将整个数据库转移到 SSD 上时,取得了 10 倍的性能提升(以每秒事务数度量)。 编辑注:对使用 SSD 的 IBM Informix Dynamic Server 的实验室测试也显示有性能提升。 然后,我们将数据库应用程序的一部分迁移到 SSD,对一系列的场景进行测试。首先采取随意安排的策略将数据库索引文件放到 SSD 存储上,但是这样做只获得不多的性能提升(不超过 2 倍)。显然,为获得更大的性能提升,需要将 SSD 空间预留给那些能导致最多随机物理 I/O 传输和对应用程序性能最为关键的数据库对象。通过对 DB2 监视数据和操作系统性能指标的实验,我们取得了表和索引在 SSD 上的优化安排策略,只需将整个数据库的 30% 放在 SSD 上,便可以获得超过 8 倍的性能提升(见图 2)。

 

  冷、暖、热:识别所需数据

     那么,确定将哪些 DB2 表或索引放在 SSD 上的最佳方式是什么?先前基于数据模型的应用程序知识便是很好的起点。但是,我们想开发一种更客观的方式来评价哪些文件和数据放到 SSD 上将带来最大的性能收益。不断地确定哪些数据是热的或冷的,然后据此将数据放到不同的存储层,这样做会给 DBA 带来额外的负担。但是,可以使用一些操作系统监视工具,例如 AIX filemon 和 iostat 实用程序,来确定哪些逻辑卷、文件系统和/或磁盘卷是热的,从而获得更多的 IOPS 和更短的访问延时。

  DB2 提供了快照监视功能,可以用于在不同级别上对所有连接的应用程序数据库、缓冲池、表空间、表、应用程序、锁等进行性能监视。该信息可以在命令行处理器 (CLP)中使用快照命令、借助 SQL 表函数或者在 C/C++ 程序中使用快照监视应用程序编程接口(API)进行收集。此外,还可以使用具有 Extended Insight 特性的 IBM DB2 Performance Expert,根据当前和历史监视数据获得丰富的洞察力。通过分析这些监视结果,可以对数据库应用程序的 I/O 特征形成有价值的洞察力。

  通过将来自 filemon、iostat 和 DB2 快照监视的数据与缓冲池监视开关相结合,可以得到以下信息:

  表空间页宽(4 KB、8 KB、16 KB 或 32 KB)

  使用页数(以表空间页宽为单位定义)

  缓冲池数据物理读数(以表空间页宽为单位定义)

  缓冲池索引物理读数(以表空间页宽为单位定义)

  缓冲池 xda 物理读数(以表空间页宽为单位定义)

  缓冲池读取时间(以秒为单位)

  根据该数据,可以使用图 3 中的公式计算 4 个指标,这些指标将帮助确定哪些表空间更适合放在 SSD 上:

  访问密度(Access density):物理 I/O 数除于表空间中的使用页数

  访问延时(Access latency):那些物理 I/O 的延时

  相对表空间权重(Relative tablespace weight):访问密度和访问延时的函数

  连续率(Sequentiality ratio):对给定表空间的 I/O 访问的随机或连续程度

  对于所有表空间,综合上述指标,按权重因子降序排列,那些具有较高权重因子的表空间更适合放在 SSD 上。具有较低连续率的表空间也比较适合放在 SSD 上。

 

  更多性能选项

  图 3 中计算的权重因子和连续率将帮助您发现最适合放在 SSD 上的表空间。但是,取决于您的环境和可用 SSD 资源,还有两种选项也应该知道一下。

  首先,如果容量允许,考虑将 DB2 临时表空间放在 SSD 上。这样可以帮助缩短复杂的 “group by” 或 “order by” 查询所需的排序时间。这对于经常需要对大量数据进行排序,然后统统装入磁盘的数据仓库工作负载来说,特别有用。最后,活动日志文件不太需要放在 SSD 上,因为这些操作通常导致连续 I/O,通常在存储器写缓存上出现。但是,如果应用程序受累于大量的提交时间和较长的日志 I/O 延时,那么将活动日志放在 SSD 将有所帮助。

 

更多精彩内容请关注:
IBM存储化官方微博
IBM存储化官方网站