提升查询性能的SSD感知临时数据管理策略
立即解锁
发布时间: 2025-08-22 01:46:29 阅读量: 2 订阅数: 17 


网络时代的个性化标签推荐系统
### 提升查询性能的SSD感知临时数据管理策略
#### 1. 引言
在数据库应用,如在线分析处理(OLAP)和地理信息系统(GIS)中,常常需要处理复杂查询。在执行这些查询时,查询处理操作符会生成大量临时数据。例如,哈希连接算法会将每个输入表划分为哈希桶,然后逐个处理这些桶;排序算法通常将输入数据集划分为较小的运行段,分别对这些运行段进行排序,然后将它们合并为一个排序文件。
随着数据量的快速增长,临时数据无法全部保存在内存中,通常会以临时文件的形式存储在磁盘上。在生成和使用这些临时文件的过程中,会产生大量随机I/O操作。由于硬盘驱动器(HDD)存在旋转延迟,随机I/O操作的成本很高。如果将临时数据存储在HDD上,随机访问时间将主导查询处理时间,从而限制整体性能。
近年来,固态硬盘(SSD)的出现为存储临时数据提供了一个很好的选择。与HDD相比,SSD可以提供更多的随机IOPS和相当的顺序带宽,并且具有重量轻、抗震性好和功耗低等优点。经过多年的发展,SSD已广泛应用于个人和服务器计算机中。
然而,由于SSD每GB的价格比HDD贵得多,企业用户通常采用由SSD和HDD组成的混合系统。在设计使用SSD存储临时数据的混合存储系统时,需要考虑两个问题:一是SSD的随机写入性能较差,因为存在写入放大问题;二是需要提供高效的内存索引结构,以便在内存或SSD中定位数据,并快速回收SSD空间。
为此,我们提出了一种名为STDM(SSD感知临时数据管理策略)的新型临时数据管理策略。STDM综合考虑了临时数据的I/O行为和SSD的物理特性。为了验证STDM的有效性,我们基于PostgreSQL 9.2实现了一个原型系统,并在TPC - H基准测试中评估其性能。实验结果表明,与传统的临时数据组织方法相比,STDM显著提高了查询处理性能。
#### 2. 相关工作
近年来,由于SSD的诸多优势,预计它将逐渐取代HDD,成为个人和服务器计算机的主要永久存储介质。这一趋势也吸引了研究人员从优化查询处理的角度来提高数据库性能。
一些工作专注于优化查询算法和页面布局,例如RARE - join专为闪存上的基于列的页面布局而设计,它结合了随机读取和顺序I/O,当只需要部分行或列时,利用SSD的快速随机读取功能来检索和处理较少的数据,从而提高性能。D. Tsirogiannis引入了FlashJoin,这是一种通用的流水线连接算法,可最大限度地减少对数据库和中间关系数据的访问。类似地,DigestJoin通过减少基于行的数据库中的中间结果大小来优化非索引连接处理。
还有一些工作利用SSD的内部并行性,如B + - 树变体PIO B - 树提出了一种新的I/O请求概念psyncI/O,可以在单个进程中利用SSD的内部并行性。另一个工作提出了并行表扫描操作符ParaScan和哈希连接操作符ParaHashJoin,以充分利用SSD的内部并行性。
从与我们工作相同的角度来看,hStorage - DB通过利用语义信息优化临时数据管理,它将请求分类为不同类型,并为临时数据分配相应的QoS,以确保它们在生成时被缓存,并在生命周期结束时被逐出。但与hStorage - DB不同的是,STDM仅使用SSD存储临时数据,而不将其与查询结果数据混合。
#### 3. 问题定义
一般来说,每个查询操作符会保留一小部分内存来缓冲临时数据块。当缓冲区满时,会在HDD中创建一个文件,并将数据块写入其中。对于复杂查询,可能有多个操作符并行运行,每个操作符在开始将数据写入临时文件之前,会使用与该缓冲区大小相同的内存。此外,多个运行会话可能会同时进行此类操作,因此总内存使用量可能是该缓冲区大小的数倍。
由于数据库系统可用的内存大小有限,需要将该缓冲区保持足够小,以支持更多的并发连接。但这会导致生成大量小文件。为了更好地理解临时数据文件的生成情况,我们在TPC - H基准测试中以30的规模因子运行了所有22个查询。TPC - H用于模拟决策支持系统,该系统需要检查大量数据、执行高度复杂的查询并回答关键业务问题。
测试结果如下表所示(忽略了只生成极少量临时文件的查询):
| 查询编号 | 2 | 3 | 5 | 7 | 8 | 9 | 10 | 14 | 16 | 18 | 19 | 21 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 临时文件数量 | 15 | 317 | 19 | 26 | 324 | 551 | 32 | 2171 | 511 | 126 | 258 | 191 |
| 临时数据总大小(MB) | 988 | 2530 | 650 | 2521 | 2812 | 5528 | 1918 | 223 | 550 | 124 | 277 | 300 |
从表中可以看出,临时文件的数量取决于相应查询的复杂度,从几十到数千不等。每个查询的总文件大小与文件数量不成比例,这是因为在排序算法中,还会计算大的排序文件。
传统的临时数据管理策略效率低下,对二级存储不友好,主要原因有两个:一方面,管理大量文件的成本不可忽视,操作系统会限制同时打开的文件描述符数量,因为每个打开的文件需要内存来管理;另一方面,在临时文件的生命周期内,无论是生成还是使用阶段,都存在随机I/O操作。随着并发连接数的增加,文件系统的性能会急剧下降。行业中常用的做法是将多个小文件合并为一个大
0
0
复制全文
相关推荐










