Processing math: 1%
  • 中国精品科技期刊
  • CCF推荐A类中文期刊
  • 计算领域高质量科技期刊T1类
高级检索

ZB+-tree:一种ZNS SSD感知的新型索引结构

刘扬, 金培权

刘扬, 金培权. ZB+-tree:一种ZNS SSD感知的新型索引结构[J]. 计算机研究与发展, 2023, 60(3): 509-524. DOI: 10.7544/issn1000-1239.202220502
引用本文: 刘扬, 金培权. ZB+-tree:一种ZNS SSD感知的新型索引结构[J]. 计算机研究与发展, 2023, 60(3): 509-524. DOI: 10.7544/issn1000-1239.202220502
Liu Yang, Jin Peiquan. ZB+-tree: A Novel ZNS SSD-Aware Index Structure[J]. Journal of Computer Research and Development, 2023, 60(3): 509-524. DOI: 10.7544/issn1000-1239.202220502
Citation: Liu Yang, Jin Peiquan. ZB+-tree: A Novel ZNS SSD-Aware Index Structure[J]. Journal of Computer Research and Development, 2023, 60(3): 509-524. DOI: 10.7544/issn1000-1239.202220502
刘扬, 金培权. ZB+-tree:一种ZNS SSD感知的新型索引结构[J]. 计算机研究与发展, 2023, 60(3): 509-524. CSTR: 32373.14.issn1000-1239.202220502
引用本文: 刘扬, 金培权. ZB+-tree:一种ZNS SSD感知的新型索引结构[J]. 计算机研究与发展, 2023, 60(3): 509-524. CSTR: 32373.14.issn1000-1239.202220502
Liu Yang, Jin Peiquan. ZB+-tree: A Novel ZNS SSD-Aware Index Structure[J]. Journal of Computer Research and Development, 2023, 60(3): 509-524. CSTR: 32373.14.issn1000-1239.202220502
Citation: Liu Yang, Jin Peiquan. ZB+-tree: A Novel ZNS SSD-Aware Index Structure[J]. Journal of Computer Research and Development, 2023, 60(3): 509-524. CSTR: 32373.14.issn1000-1239.202220502

ZB+-tree:一种ZNS SSD感知的新型索引结构

基金项目: 国家自然科学基金项目(62072419)
详细信息
    作者简介:

    刘扬: 2000年生. 硕士研究生. 主要研究方向为面向新型硬件的数据库技术

    金培权: 1975年生. 博士,副教授,博士生导师. CCF杰出会员. 主要研究方向为数据库与大数据

    通讯作者:

    金培权(jpq@ustc.edu.cn)

  • 中图分类号: TP311.13

ZB+-tree: A Novel ZNS SSD-Aware Index Structure

Funds: This work was supported by the National Natural Science Foundation of China (62072419).
  • 摘要:

    ZNS SSD是近年来提出的一种新型固态硬盘(solid state drive,SSD),它以分区(Zone)的方式管理和存取SSD内的数据.相比于传统SSD,ZNS SSD可以有效提升SSD的读写吞吐,降低写放大,减少SSD的预留空间.但是,ZNS SSD要求Zone内必须采用顺序写模式,并且Zone上的空间分配、垃圾回收等任务都需要用户自行控制.ZNS SSD的这些特性对于传统数据库系统的存储管理、索引、缓存等技术均提出了新的挑战.针对如何使传统的B+-tree索引结构适配ZNS SSD的问题,提出了一种ZNS SSD感知的新型索引结构——ZB+-tree (ZNS-aware B+-tree).ZB+-tree是目前已知的首个ZNS SSD感知的索引,它以B+-tree为基础,利用ZNS SSD内部支持少量随机写的常规Zone(conventional zone,Cov-Zone)和只支持顺序写的顺序Zone(sequential zone,Seq-Zone),通过常规Zone来吸收对ZNS SSD的随机写操作.ZB+-tree将索引节点分散存储在常规Zone和顺序Zone中,并为2种Zone内的节点分别设计了节点结构,使ZB+-tree不仅能够吸收对索引的随机写操作,而且又可以保证顺序Zone内的顺序写要求.在实验中利用null_blk和libzbd模拟ZNS SSD设备,并将现有的CoW B+-tree修改后作为对比索引.结果表明,ZB+-tree在运行时间、空间利用率等多个指标上均优于CoW B+-tree.

    Abstract:

    ZNS SSD is a newly emerging solid state drive (SSD). It supports zone-based storage and access of data in SSD. Compared with traditional SSDs, ZNS SSD can effectively improve the read-write throughput of SSD, reduce write amplification and over-provisioning in SSD. However, ZNS SSD requires that data must be written to zones sequentially, and tasks such as space allocation and garbage collection need to be controlled by users. These characteristics of ZNS SSD pose new challenges to many components in traditional database systems, such as storage management, indexing, and buffer management. This paper mainly studies how to adapt the traditional B+-tree index structure to ZNS SSD. We propose a new ZNS SSD-aware index structure called ZB+-tree (ZNS-aware B+-tree), which is the first ZNS SSD-aware index so far. ZB+-tree takes B+-tree as the base structure, and utilizes the two kinds of zones inside ZNS SSD, namely conventional zones supporting a few random writes and sequential zones only supporting sequential writes. In particular, it uses conventional zones to absorb random writes to ZNS SSD and stores the index nodes in conventional and sequential zones separately. We design different node structures for the nodes in the two zones. By using different types of nodes on the two zones, ZB+-tree can absorb random writes on the index and ensure the sequential write requirements on sequential zones. We conduct experiments by simulating ZNS SSD using null_blk and libzbd. Also, we modify the existing copy-on-write (CoW) B+-tree as the competitor. The results show that ZB+-tree outperforms CoW B+-tree in various metrics including running time and space efficiency.

  • 嵌入式实时系统广泛存在于生产和生活当中,例如航空航天、轨道交通、无人驾驶、互联通信等.在实时系统中,其正确性不仅仅依赖于逻辑结果的正确性,同时还依赖于结果产生的时间[1].实时系统中的任务执行时间具有严格的约束,如果错过任务截止时间将会导致灾难性后果.因此,实时系统在任务调度设计和可调度性分析时都必须保证任务的执行在一个安全的时间上界之内,此上界的计算方法即任务的最坏情况执行时间(worst-case execution time,WCET)分析.当前主流的WCET分析方法分为静态分析和动态分析,动态分析也称为基于测试的分析方法,通过大量的测试用例来获取精确的WCET分析结果,由于无法穷尽所有的测试用例,动态分析无法保证分析结果的安全性,工业界通常会在分析结果的基础上增加一定的裕量(例如20%)[2]作为最终的WCET分析结果.静态分析方法则是通过对处理器硬件结构和程序流信息进行分析估算程序的WCET值,静态分析方法能够保证分析结果的安全性,并且不需要运行程序便可获得WCET结果,所以大多数WCET分析工具都采用静态分析方法.单核处理器WCET分析方法经过多年的研究已经取得较高的分析精度,然而多核处理器中加速部件的使用和共享资源干扰的存在,导致原有的单核处理器WCET分析方法无法直接适用于多核处理器,这对于多核处理器的WCET分析提出了新的挑战.

    在硬件结构方面,多核处理器的WCET分析主要考虑Cache、内存、核间互联和流水线等部件的影响[3],Rapita Systems公司的实验表明,由于L3 Cache的争用导致YOLO算法的帧率降低90%左右.当前对于Cache的研究主要集中在指令Cache带来的干扰分析[4-7],并已经获得了较高的分析精度,而对于数据Cache的关注则不足,其原因有2方面:1)处理器寻址方式的不同导致数据Cache的访问地址分析更加困难;2)数据Cache在循环的不同轮次中访问的数据不同,正是由于数据Cache和指令Cache在时空特性上的差异,造成数据Cache的分析更加复杂.如果简单将指令Cache的分析技术套用到数据Cache上,会导致分析结果过于悲观[8].对于数据Cache的分析除了以上问题之外,另一个需要特别关注的影响因素就是数据一致性协议.有研究表明,由于Cache一致性协议的影响,并行程序执行比串行程序慢74%[9].但是相关的调研表明[10],极少数研究人员关注Cache一致性造成的干扰.

    针对现有多核处理器WCET分析方法对数据Cache一致性协议考虑不足的问题,本文主要研究一种基于多级一致性协议的多核处理器WCET分析方法.该方法通过建立多级一致性域,抽象出一致性协议嵌套的共享数据管理机制,分别从一致性域内部、跨一致性域2个层面来分析内存访问延迟,从而实现对多核处理器中数据Cache的精确分析.

    Ferdinand等人[11]提出基于抽象解释理论[12]的Cache行为分析方法,由于其具有较高的精确度和效率,在基于Cache的WCET分析中占据了统治地位[8].如图1所示,基于抽象解释的Cache分析方法对Cache的物理状态和替换策略进行抽象,得到抽象缓存状态(abstract cache state)和函数Join、函数Update,通过May分析、Must分析和Persistence分析3种方法得出Cache的“Cache命中/失效分类”(cache hit miss classification, CHMC),从而确定Cache的访问延迟.Huynh等人[13]经过分析证明了原有的Persistence分析方法存在不安全性,其原因在于更新函数lhˆs(lh1)(ˆs(lh){m})未将可能被替换出去的内存块的年龄进行增加,导致分析结果不正确.为解决此问题,该小组提出Younger Set的概念,并将Younger Set引入到函数Join和函数Update中,保证了Persistence分析的安全性.在过去的20多年,研究人员对Persistence分析进行了广泛的研究,仍然不能保证其发现所有的Persistent Cache块,直到Stock[14]给出Exact Persistence分析方法,才使得Persistence分析趋于完善.

    图  1  基于抽象解释的Cache分析方法
    Figure  1.  Cache analysis based on abstract interpretation

    模型检测[15]方法是另一个广泛研究的Cache行为分析方法,模型检测作为实时系统中常用的时序验证手段,将各类时序分析问题转化为时间自动机的可达性问题,从而实现对问题的求解.Wilhelm[16]讨论了模型检测技术在WCET分析中的优缺点,Metzner[17]认为模型检测方法能够提高分析结果的精度.Dalsgaard等人[18]基于模型检测方法实现了模块化任务执行时间分析框架;Gustavsson等人[19]的研究表明,UPPAAL可以用于多核处理器中并行任务的WCET分析,Cassez等人[20]将WCET分析问题转换为寻找最长路径的问题,并通过扩展模型检测工具UPPAAL实现了一个任务WCET分析工具WUPPAAL;Lü等人[21]在开源工具Chronos的基础上,将模型检测的方法用于Cache的行为分析,实现了一个多核处理器WCET分析工具McAiT;陈芳园等人[22]改进多核处理器中Cache冲突分析方法,在取指阶段考虑取指操作之间的时序关系,该方法能够排除部分非干扰状态,使得WCET计算精度最高提高12%.上述对于Cache行为分析多是针对指令Cache展开的,而对于数据Cache的分析研究较少,尤其是对于多核处理器中Cache一致性协议的讨论更为少见.直到2015年,Uhrig等人[23]研究数据Cache对多核处理器WCET分析的影响,并研究了基于监听的一致性协议和TDMA总线对多核处理器中延迟时间的影响,最终得出结论:采用写失效的基于总线监听的一致性协议不具备可预测性,而采用写更新双通道直接映射的bus-snarfing一致性协议配合TDMA总线能够实现时间可预测.但文献[23]未对Cache一致性协议带来的内存访问延迟进行更为细致的分析.而Hassan等人[24]的分析也得出了基于总线监听MSI一致性协议配合TDMA总线的多核处理器的WCET值不具有可预测性,重点分析了TDMA总线导致的不可预测性,而对于多核处理器中基于MESI一致性协议的WCET估计,同样未给出详细的分析方法.Tsoupidi[25]针对对称多处理器,提出一种考虑Cache一致性协议的WCET分析方法,该方法在计算共享Cache读访问延迟时认为hsh=max,上述情况仅发生在Cache使用写回(write-back)策略时,对于写直达(write-through)策略,数据同时存在于私有Cache和共享Cache中,该计算方式存在较大的悲观性,且该文仅仅讨论了单级一致性协议下的WCET分析方法,而对于多核处理器中存在多级Cache一致性协议的情况,尚未见到相关的研究.

    为此,本文针对数据Cache中共享数据的访问,提出了基于多级一致性协议的多核处理器WCET分析方法,解决多级一致性协议嵌套情况下的WCET分析问题,完善了多核处理器Cache的分析框架,并实现一个基于MESI(modify exclusive shared invalid)协议的高精度多核处理器WCET分析工具,为多核实时系统的WCET分析提供了支撑.

    本节的核心工作在于提出一种多级一致性域的WCET分析方法,实现对多核处理器中多级一致性域的WCET分析.通过对一致性域内部的Cache访问延迟和状态转换情况进行分析,得出一致性域内部的分析结果,根据是否进行跨域数据访问决定下一步是否需要进行跨域分析,从而实现一致性协议嵌套情况下的共享数据访问延迟分析.本文将该方法与当前主要考虑指令Cache的分析方法相结合,增加了数据Cache中共享数据的访问分析,扩展了多核处理器中Cache的干扰分析框架,进一步完善了多核处理器WCET分析方法.

    共享存储结构是当前应用最为广泛的多核处理器架构,此种结构对于每一个内核而言都是对等的,每一个内核的访问时间都是相同的,因此多核处理器属于对称多处理器(symmetric multi-processor,SMP).最初的多核处理器中只存在私有Cache和共享Cache,随着CPU制造工艺的发展,当前多核处理器已集成多级Cache.

    采用SMP架构的多处理器需要支持共享数据的Cache,通过读写共享数据实现内核之间的通信.在缓存共享数据时,可能会存在多个内核对共享数据的争用,也可能会在多个Cache中复制共享数据,导致多个数据副本不一致,因此共享数据Cache引入了一个新的问题——Cache一致性问题,需要引入一致性协议保证数据一致性.

    MESI是一种典型的Cache一致性协议,也被称为Illinois MESI协议,是在原MSI协议的基础上引入E状态,用于表示独占状态.在写入一个共享数据块时,通常有2种写策略:写直达和写回.对于图2所示的多级Cache组织结构,由于写回策略对存储器的带宽要求低,能够支持更多、更快速的处理器,所以最外层级别(簇(cluster)间)通常采用写回策略[3];而对于簇内的写入共享数据的策略,如果采用写回策略,会造成簇内L1 Cache中数据和L2 Cache中的数据不一致的情况,在维护簇内数据一致性的同时,还要考虑簇间一致性,造成一致性协议非常复杂,不利于硬件的实现,因此簇内采用写直达的策略.

    图  2  多级Cache组织结构
    Figure  2.  Multi-level Cache arrangement

    写直达和写回适用于访问命中的情况,当访问缺失时所采用的写策略为写分配(write allocation)和非写分配(no write allocation)两种方式,通常写回与写分配策略配合使用,写直达和非写分配策略配合使用.

    多核处理器任务调度时存在多个内核共同完成一个任务,或者将某些关键等级高的任务映射到特定的内核上,因此,这些任务之间的数据交换仅仅在特定内核之间进行,如果使用一个一致性协议维护所有内核的数据副本,将会产生大量的数据交互操作,造成网络拥塞,降低执行效率, 一种可行的方法是将所有的内核进行区域划分[26],每个区域使用独立的一致性协议管理数据副本,该方法既能充分利用局部性原理,又能降低网络负载.

    定义1. 一致性域.使用相同一致性协议管理数据副本的内核集合,称之为一致性域.

    一致性域的示意图如图3所示.

    图  3  一致性域
    Figure  3.  Coherence domain

    一致性域具有2个性质:

    性质1.一致性域具有独立性,即任意2个一致性域之间不存在交集.

    性质2.一致性协议在一致性域内具有唯一性.

    由于一致性协议只能维护域内数据的一致性,当存在跨域数据交互时,会导致无法保证域间数据的一致性,需要使用多级一致性协议进行数据维护,相应地,需要定义多级一致性域.多级一致性域采用分层划域的思想,下层一致性域是上层一致性域的一个结点(clump).

    针对如图2所示的硬件架构,根据一致性域的定义,簇内为1级一致性域,整个多核处理器构成2级一致性域.处理器内核在访问数据时,首先会访问私有Cache,如果访问缺失,则会访问下一级共享Cache,即簇内共享Cache,此时数据访问范围仍在一致性域内.如果访问命中,只需进行域内WCET分析即可;如果访问缺失,根据存储器层次结构访问次序,则需要进行跨一致性域WCET分析.

    在进行多核处理器的Cache行为分析时,假设总线是完美的并且不存在读和写队列的限制,在此基础上分析Cache一致性协议对内存访问时间的影响.

    首先假设处理器拥有私有Cache、共享Cache和内存,Cache采用写回和写分配策略,Cache的访问分为读和写,读和写都会出现访问命中或缺失,我们从读和写2个方面对Cache行为进行分析,在开始分析之前定义如下符号:

    1) {\psi _{\text{R}}}(m,m') / {\psi _{\text{W}}}(m,m') .表示域内Cache读/写访问时间延迟和状态转换情况,m表示被访问的数据,m'表示被访问数据的副本.

    2) {H_{{\text{L}}i}} .表示在第i级Cache访问命中时间延迟.

    3) {L_{{\text{L}}i \to {\text{L}}j}} .表示数据从第i级Cache加载到第j级Cache的时间延迟.

    4){H_{{\text{memory}}}}.表示主存访问命中时间延迟.

    5) Inv / Inv' .表示域内/跨域使其他数据副本失效的时间延迟.

    6){\psi '_{\text{R}}}(m,m')/ {\psi '_{\text{W}}}(m,m') .表示跨域Cache读/写访问时间延迟和状态转换情况.

    7) {m_{\text{s}}} / {m'_{\text{s}}} .表示本地/远程Cache状态.

    8) {\text{Replacement}} / \neg {\text{Replacement}} .表示被访问共享数据被替换出Cache,导致替换缺失发生/未发生.

    现有工作对于Cache的分析主要集中在指令Cache,对于数据Cache的分析也仅限于本地数据的分析.本文在基于抽象解释的多级Cache分析框架基础上,扩展了共享数据分析这一功能.

    图4所示,该分析框架的输入为待分析程序和Cache模型.其中待分析程序提供控制流、地址信息,Cache模型中包括了Cache组织结构、替换策略、读写策略以及一致性协议,这些参数作为分析框架的输入信息,提供给Cache分析方法.Cache的分析可分为2部分:数据Cache和指令Cache,其中数据Cache中共享数据的分析为本文的主要工作,将在后文中详细介绍.最后,根据分析结果得出内存访问的分类以及访问的时间延迟,从而得出WCET的分析结果.

    图  4  基于一致性协议的WCET分析框架
    Figure  4.  WCET analysis framework based on coherence protocol

    当内核发出读数据m的读请求时,如果m存在于L1中,其状态可能为E或者S并且未发生替换缺失,在L1中能够读命中,数据访问延迟为 {H_{{\text{L}}1}} ,所有Cache块的状态不会发生改变.

    如果数据m在域内,m的状态为E或者S但是发生替换缺失,此时数据访问延迟为读取L2中数据的时间 {\psi '_{\text{R}}} ,同时需要将数据从L2 Cache加载到本地L1 Cache中,考虑连贯性要求,数据访问延迟为 \max ({\psi '_{\text{R}}},{L_{{\text{L}}2 \to {\text{L}}1}}) ,Cache状态不发生变化,如图5 (a)(b)所示.

    图  5  域内读访问时间延迟及状态转换图
    Figure  5.  Read-visit latency and state transition diagram of intra-domain

    如果数据m在域内,m的状态为I,且副本m'的状态为E或者S时,此时数据访问延迟为读取L2中数据的时间 {\psi '_{\text{R}}} ,同时需要将数据从L2 Cache加载到本地L1 Cache中,考虑连贯性要求,数据访问延迟为\max ({\psi '_{\text{R}}},{L_{{\text{L}}2 \to {\text{L}}1}})m的状态转换为S,副本m'的状态转换为S,如图5 (c)所示.

    如果数据m不在域内,在L2 Cache中会出现访问缺失,假定访问L2 Cache的时间为 {\psi '_{\text{R}}} ,对于 {\psi '_{\text{R}}} 的取值我们将在2.7.1节中进行分析.此时m的状态由I转换为E,L2 Cache的状态需要根据L2的一致性协议进一步分析,如图5(d)所示.

    根据以上分析,可以得出Cache域内读访问时间延迟和状态转换的状态更新函数:

    \begin{aligned}&{\psi }_{{{\rm{R}}}}(m,{m}^{\prime })=\\ &\left\{ {\begin{aligned} &{H}_{{{\rm{L}}}1},{m}_{{{\rm{s}}}}\mapsto {m}_{{{\rm{s}}}},{m}'_{{{\rm{s}}}}\mapsto {{m}'_{{{\rm{s}}}}}; \\ &\ \ \ m存在于\text{L}1\wedge \neg {{\rm{Replacement}}}.\\ &{{\rm{max}}}({{\psi }'_{\text{R}}},{L}_{\text{L}2\to {{\rm{L}}}1}),{m}_{{{\rm{s}}}}\mapsto {m}_{{{\rm{s}}}},{m}'_{{{\rm{s}}}}\mapsto {m}'_{{{\rm{s}}}};\\ &\ \ \ m存在于\text{L}1\wedge {{\rm{Replacement}}}.\\ &{{\rm{max}}}({{\psi }'_{\text{R}}},{L}_{{{\rm{L}}}2\to {{\rm{L}}}1}),{m}_{{{\rm{s}}}}:{{\rm{I}}}\to {{\rm{S}}},{m}'_{{{\rm{s}}}}:{{\rm{E}}}/{{\rm{S}}}\to {{\rm{S}}};\\ &\ \ \ m不存在于{{\rm{L}}}1\wedge m存在于{{\rm{L}}}2\wedge {m}^{\prime }存在于{{\rm{L}}}1.\\ &{{\psi } '_{\text{R}}},{m}_{{{\rm{s}}}}:{{\rm{I}}}\to {{\rm{E}}};m不在域内. \end{aligned}} \right.\end{aligned} (1)

    当内核发出写m的请求时,如果m仅存在本地L1 Cache且状态为E时,此时会发生Cache写命中.首先需要将数据写入到L1中,由于使用写直达策略,需要同时写入到L2当中,因此数据访问时间为 {H_{{\text{L}}1}} + {\psi '_{\text{W}}} ,Cache状态不发生改变,如图6(a)所示;如果m存在于L1 Cache中且状态为S时,此时会发生Cache写命中,数据访问延迟为 {H_{{\text{L}}1}} + {\psi '_{\text{W}}} ,状态转换为E,由于采用写失效的一致性协议,因此需要将副本的状态修改为I,考虑连贯性要求,数据访问最终的延迟为 \max ({H_{{\text{L}}1}} + {\psi '_{\text{W}}},Inv) ,如图6(b)所示.

    图  6  域内写访问时间延迟及状态转换图
    Figure  6.  Write-visit latency and state transition diagram of intra-domain

    如果数据m位于本地L1 Cache中,m的状态为E或者S,并且发生替换缺失,此时会出现写缺失.如果m的状态为E,此时数据访问时间为 {\psi '_{\text{W}}} ,并且状态转换为I,如图6(c)所示;如果m的状态为S,在进行L2 Cache写操作之后,需要对其他副本进行写失效,所以访问时间为 \max ({\psi '_{\text{W}}},Inv) m和副本m'的状态都转换为I,如图6(d)所示.

    如果数据m在域内, m的状态为I且副本m'的状态为E或者S时,此时会对L2进行写操作, 并将其他副本中的数据写失效, 考虑数据连贯性要求, 数据的写延迟为 \max ({\psi '_{\text{W}}},Inv) , 由于采用非写分配的方式, 本地L1的状态不发生改变,其他副本的状态从E/S转换为I, 如图6(e)所示.

    如果数据m不在域内,类比读访问的情况,假定写L2 Cache的访问时间为 {\psi '_{\text{W}}} .由于域内采用非写分配法,所以此时m的状态不发生任何变化,如图6(f)所示.

    根据以上分析,可以得出Cache域内写访问时间延迟和状态转换的状态更新函数:

    \begin{aligned}&{\psi }_{{{\rm{W}}}}(m,{m}^{\prime })=\\ &\left\{ {\begin{aligned} &{H}_{\text{L}1}+{\psi }'_{\text{W}},{m}_{\text{s}}\mapsto {m}_{\text{s}},{{m}}'_{\text{s}}\mapsto {{m}}'_{\text{s}};\\ &\ \ \ m存在于\text{L}1\wedge {m}^{\prime }不存在于\text{L}1\wedge \neg \text{Replacement}.\\ &\mathrm{max}({H}_{\text{L}1}+{{\psi }}'_{\text{W}},Inv),{m}_{\text{s}}:\text{S}\to \text{E},{{m}}'_{\text{s}}:\text{S}\to \text{I};\\ &\ \ \ m存在于\text{L}1\wedge {m}^{\prime }存在于\text{L}1\wedge \neg \text{Replacement}.\\ &{{\psi }}'_{\text{W}},{m}_{\text{s}}:\text{E}\to \text{I};\\ &\ \ \ m存在于\text{L}1\wedge {m}^{\prime }不存在于\text{L}1\wedge \text{Replacement}.\\ &\mathrm{max}({{\psi }}'_{\text{W}},Inv),{m}_{\text{s}}:\text{S}\to \text{I},{{m}}'_{\text{s}}:\\ &\ \ \ m存在于\text{L}1\wedge {m}^{\prime }存在于\text{L}1\wedge \text{Replacement}.\\ &\mathrm{max}({{\psi }}'_{\text{W}},Inv),{m}_{\text{s}}\mapsto {m}_{\text{s}},{{m}}'_{\text{s}}:\text{E}/\text{S}\to \text{I};\\ &\ \ \ m存在于\text{L}1\wedge {m}^{\prime }存在于\text{L}1.\\ &{{\psi }}'_{\text{W}},{m}_{\text{s}}\mapsto {m}_{\text{s}};m不在域内. \end{aligned}} \right.\end{aligned} (2)

    当内核发出读数据m的读请求时,如果需要对L2 Cache进行读访问,此时将会由上级一致性协议管理共享数据.

    如果数据m存在于域内,并且位于本地L2 Cache中,对应域内读访问的图5(a)~(c),此时数据访问时间为 {H_{{\text{L}}2}} ,域间所有的Cache的状态都不发生变化,如图7(a)所示.

    图  7  跨域读访问时间延迟及状态转换图
    Figure  7.  Read-visit latency and state transition diagram of cross-domain

    当被访问数据m存在于L2 Cache中并且发生替换缺失,对应域内读访问的图5(d),此时数据访问延迟为 {H_{{\text{L}}3}} ,同时需要将数据加载到L1 Cache中,考虑到连贯性要求,数据访问的延时为 \mathrm{max}({H}_{\text{L}3},{L}_{\text{L}3\to \text{L}1}) ,如果m的状态为M或者E,则状态会转换为E,如果m的状态为S,则状态不发生改变,副本m'的状态不发生改变,如图7(b)(c)所示.

    如果被访问数据m不存在于域内,对应域内读访问的图5(d),存在2种可能性:1)数据m本身不存在Cache中;2)数据m存在于其他域的Cache中.如果数据m不存在Cache中,此时需要通过内存来读取数据m,数据访问延迟为 H_\text{memory},同时需要将数据从内存中写回到L1 Cache中,考虑连贯性要求,数据访问延迟为 \max ({H_\text{memory}},{L_{m \to {\text{L}}1}}) ,L2的状态从I转换为E,如图7(d)所示.

    如果数据存在于其他域中,即存在数据副本m',如果其状态是M,首先要将数据从其他域的L2 Cache中加载到本地域的L2中,然后再加载到L1中,最后从L1中读取数据,其访问延迟为 {L_{{\text{L}}2 \to {\text{L}}2}} + {L_{{\text{L}}2 \to {\text{L}}1}} + {H_{{\text{L}}1}} ,此时L2中数据m的状态从I转换为S,其他域L2中数据副本m'状态从M转换为S图7(e)所示.

    如果数据副本m'的状态为E或者S,将会在L3中读取命中数据,此时数据访问延迟为 {H_{{\text{L}}3}} ,与此同时,数据将会加载到L1中,考虑连贯性要求,此时数据访问延迟应取 \max ({H_{{\text{L}}3}},{L_{{\text{L}}3 \to {\text{L}}1}}) ,此时L2中数据m的状态从I转换为S,其他域L2中数据副本m'状态换为S图7(f)所示.

    根据以上分析,可以得出Cache跨域读访问时间和状态转换的状态更新函数:

    \begin{aligned}&{{\psi }}_{\text{R}}^{\prime }(m,{m}^{\prime })=\\ &\left\{ {\begin{aligned} &{H}_{\text{L}2},{m}_{\text{s}}\mapsto {m}_{\text{s}},{{m}}'_{\text{s}}\mapsto {{m}}'_{\text{s}}; \\ &\ \ \ m存在于\text{L}2\wedge \neg \text{Replacement}.\\ &\mathrm{max}({H}_{\text{L}3},{L}_{\text{L}3\to \text{L}1}),{m}_{\text{s}}:\text{M}/\text{E}\to \text{E};\\ &\ \ \ m存在于\text{L}2\wedge {m}^{\prime }不存在于\text{L}2\wedge \text{Replacement}.\\ &\mathrm{max}({H}_{\text{L}3},{L}_{\text{L}3\to \text{L}1}),{m}_{\text{s}}\mapsto {m}_{\text{s}},{{m}}'_{\text{s}}\mapsto {{m}}'_{\text{s}};\\ &\ \ \ m存在于\text{L}2\wedge {m}^{\prime }存在于\text{L}2\wedge \text{Replacement}.\\ &\mathrm{max}({H}_\text{memory},{L}_{m\to \text{L}1}),{m}_{\text{s}}:\text{I}\to \text{E};\\ &\ \ \ m不存在于\text{Cache}中.\\ &{L}_{\text{L}2\to \text{L}2}+{L}_{\text{L}2\to \text{L}1}+{H}_{\text{L}1},{m}_{\text{s}}:\text{I}\to \text{S},{{m}}'_{\text{s}}:\text{M}\to \text{S};\\ &\ \ \ m不存在于\text{L}2\wedge {m}^{\prime }存在于\text{L}2\wedge {m}^{\prime }不存在于\text{L}3.\\ &\mathrm{max}({H}_{\text{L}3},{L}_{\text{L}3\to \text{L}1}),{m}_{\text{s}}:\text{I}\to \text{S},{{m}}'_{\text{s}}:\text{E}/\text{S}\to \text{S};\\ &\ \ \ m不存在于\text{L}2\wedge {m}^{\prime }存在于\text{L}2\wedge m存在于\text{L}3. \end{aligned}} \right.\end{aligned} (3)

    当内核发出写数据m的写请求时,如果需要对L2 Cache进行写访问,此时将由上级一致性协议管理共享数据.

    如果数据m在域内(对应域内写访问图6(a)~(e)的情况),并且位于本地L2 Cache中,状态为S,需要将其他副本中的数据写失效,考虑连贯性要求,数据访问时间为 \max ({H_{{\text{L}}2}},Inv') ,状态转换为M,副本的状态由S转换为I,如图8(a)所示;如果m的状态为M或者E,此时数据访问时间为 {H_{{\text{L}}2}} ,状态转换为M,其他Cache状态不变,如图8(b)所示.

    图  8  跨域写访问时间延迟及状态转换图
    Figure  8.  Write latency and state diagram of cross-domain

    如果被访问数据m不存在于域内(对应域内写访问图6(f)的情况), 存在2种可能性:1)数据m本身不存在Cache中;2)数据m存在于其他域的Cache中.如果数据m不存在Cache中, 由于域间采用写分配,首先要将数据从内存加载到L2 Cache中, 然后在L2 Cache中修改数据, 此时数据访问延迟为 {H_{{\text{L}}2}} + {L_{m \to {\text{L}}2}} ,L2 Cache的状态从I转换为M, 如图8(c)所示.

    如果数据存在于其他域内,数据m的状态为I,如果数据副本m'的状态为M,首先要将数据从其他域加载到本地L2中,然后修改本地L2 Cache中的数据,状态转换为M,并且要将其他副本写失效,考虑连贯性要求,数据访问延迟为 \max ({H_{{\text{L}}2}} + {L_{{\text{L}}2 \to {\text{L}}2}},Inv') ,其他副本的状态转换为I,如图8(d)所示;如果副本的状态为E或者S,此时需要将数据从L3 Cache加载到本地L2 Cache中,状态转换为M,并且要将其他副本写失效,考虑连贯性要求,数据访问延迟为 \max ({H_{{\text{L}}2}} + {L_{{\text{L}}3 \to {\text{L}}2}},Inv') ,副本的状态准换为I,如图8(e)所示.

    如果m为M, E, S状态并且发生替换缺失时(对应域内写访问图6(f)的情况), 此时会发生Cache写缺失.首先将数据从L3 Cache加载到L2 Cache, 然后执行写操作.对于m的状态为M和E的情况, 此时数据访问延迟为 {H_{{\text{L}}2}} + {L_{{\text{L}}3 \to {\text{L}}2}} , m的状态转换为M, 如图8(f)所示;如果m的状态为S, 需要将其他副本中的数据写失效, 考虑连贯性要求, 数据访问延迟为 \max ({H_{{\text{L}}2}} + {L_{{\text{L}}3 \to {\text{L}}2}},Inv') , m的状态由S变为I, 如图8(g)所示.

    根据以上分析,可以得出Cache跨域写访问时间和状态转换的状态更新函数:

    \begin{aligned} &{{\psi }}'_{\text{W}}(m,{m}')=\\ &\left\{ {\begin{aligned} &\mathrm{max}({H}_{\text{L}2},In{v}'),{m}_{\text{s}}:\text{S}\to \text{M},{{m}}'_{\text{s}}:\text{S}\to \text{I}; \\ & \ \ \ m{存在于}\text{L}2\wedge {m}'{存在于}\text{L}2\wedge \neg \text{Replacement}.\\ &{H}_{\text{L}2},{m}_\text{s}:\text{M}/\text{E}\to \text{M},{m}'_{\text{s}}\mapsto {m}'_{\text{s}};\\ &\ \ \ m{存在于}\text{L}2\wedge {m}'{不存在于}\text{L}2\wedge \neg \text{Replacement}.\\ &{H}_{\text{L}2}+{L}_{m\to \text{L}2},{m}_{\text{s}}:\text{I}\to \text{M};\\ &\ \ \ m{不存在}\text{Cache}{中}.\\ &\mathrm{max}({H}_{\text{L}2}+{L}_{\text{L}2\to \text{L}2},In{v}'),{m}_{\text{s}}:\text{I}\to \text{M},{m}'_{\text{s}}:\text{M}\to \text{I};\\ &\ \ \ m{不存在于}\text{L}2\wedge {m}'{存在于}\text{L}2\wedge m{不存在于}\text{L}3.\\ &\mathrm{max}({H}_{\text{L}2}+{L}_{\text{L}3\to \text{L}2},In{v}'),{m}_{\text{s}}:\text{I}\to \text{M},{m}'_{\text{s}}:\text{E}/\text{S}\to \text{I};\\ &\ \ \ m{不存在于}\text{L}2\wedge {m}'{存在于}\text{L}2\wedge m{存在于}\text{L}3.\\ &{H}_{\text{L}2}+{L}_{\text{L}3\to \text{L}2},{m}_{\text{s}}:\text{M}/\text{E}\to \text{M};\\ &\ \ \ m{存在于}\text{L}2\wedge {m}'{不存在于}\text{L}2\wedge \text{Replacement}.\\ &\mathrm{max}({H}_{\text{L}2}+{L}_{\text{L}3\to \text{L}2},In{v}''),{m}_{\text{s}}:\text{S}\to \text{M},{m}'_{\text{s}}:\text{S}\to \text{I};\\ &\ \ \ m{存在于}\text{L}2\wedge {m}'{存在于}\text{L}2\wedge \text{Replacement}. \end{aligned}} \right.\end{aligned} (4)

    本文在实验室原有多核处理器WCET分析工具的基础上,扩展其中数据Cache的分析方法,增加了对MESI一致性协议的支持,设计并实现了一个支持Cache一致性协议的多核处理器WCET分析工具Roban.通过该工具对多核处理器进行WCET分析,并将分析结果与GEM5仿真工具模拟执行得到的时间进行对比,从而验证分析方法的有效性.

    实验针对4核处理器展开分析,每2个内核组成1簇,即2个1级一致性域和1个2级一致性域,处理器存储结构参照图2,关键参数配置如表1所示.从Mälardalen大学WCET研究小组测试用例集中选取典型测试用例进行测试.

    表  1  多核处理器参数配置
    Table  1.  Parameters Configuration of Multi-Core Processor
    Cache
    层次结构
    数据访问延时/cycle一致性
    协议
    替换策略
    L1L2L3
    4 核, 2 簇41442MESILRU
    注:LRU为最近最少使用(least recently used)替换策略.
    下载: 导出CSV 
    | 显示表格

    实验一共分为2组,第1组Cache相联度为4路组相联,第2组Cache相联度为8路组相联.分别调整L1,L2,L3 Cache的容量,得出在不同Cache配置情况下的WCET值,结果如图9所示.

    图  9  GEM5仿真结果与分析结果对比
    Figure  9.  Comparison of GEM5 simulation results and analysis results

    图9可以看出, Roban工具得到的WCET分析结果均大于GEM5仿真得到的结果,证明了本文方法的安全性.

    为了验证本文方法的有效性,采用Spearman相关性分析法对图9中Roban分析结果与GEM5仿真结果进行相关性分析,得出的相关性系数矩阵如图10所示,其中横坐标为Roban分析工具对应的测试结果,纵坐标表示GEM5仿真结果.从图10中可以看出,带有数字标签的矩阵元素为相同测试用例在不同Cache参数配置情况下得到WCET结果的相关性系数,相关性系数不小于0.98,说明Roban和GEM5两种工具得出的结果显著相关,同时表明了图9中的曲线变化趋势基本一致.

    图  10  GEM5与Roban相关性系数矩阵图
    Figure  10.  Correlation coefficient matrix diagram of GEM5 and Roban

    为了验证本文提出分析方法的精确性,采用过估计率这一指标对分析结果进行评估,过估计率 \mathcal{R} 计算方式为

    \mathcal{R} = \frac{{T_{{\text{WCET}}}^{{\text{estimation}}}}}{{T_{{\text{WCET}}}^{{\text{simulation}}}}} , (5)

    其中, {{T_{{\text{WCET}}}^{{\text{estimation}}}}} {{T_{{\text{WCET}}}^{{\text{simulation}}}}} 分别表示WCET的估计结果和仿真结果.

    过估计率的统计结果如图11所示.由图11可知,本文方法分析得出的过估计率最大值为1.476,最小值为1.158,平均值为1.30,对比瑞典皇家理工学院[25]设计实现的WCET分析工具KTA(KTH’s timing analysis),其平均过估计率为2.08,本文方法的过估计率降低了0.78.

    图  11  过估计率统计结果
    Figure  11.  Statistical results of over estimation rate

    本文通过分析多级一致性协议体系架构下的Cache状态转换和内存访问延迟,得出多级一致性域WCET分析方法.实验表明,本文方法能够精确估算出多核处理器任务WCET,在改变Cache配置参数的情况下,GEM5仿真结果与本文工具Roban分析结果相关性系数不低于0.98,表明本文方法分析结果的变化趋势与GEM5仿真结果一致;通过与当前分析方法进行对比,证明本文方法相比现有方法的过估计率降低了0.78.

    本文在进行Cache行为分析时,将总线假设为理想状态,而在实际的一致性协议中,如果存在大量的数据交互,将会导致总线发生阻塞,在以后的工作中,应将Cache之间共享总线纳入到分析范围中,进一步提高WCET分析结果的准确性.另外本文在考虑一致性协议时仅考虑了MESI协议,而在实际工程领域存在多种一致性协议,如Intel i7使用的MESIF协议、AMD Opteron使用的MOESI协议等,在后续的工作中将针对不同的一致性协议展开分析.

    作者贡献声明:朱怡安提出研究思路和指导意见;史先琛提出了算法并撰写论文;姚烨、李联负责实现算法并设计实验方案;任鹏远、董威振、李佳钰参与实验方案设计并整理实验数据.

  • 图  1   ZNS SSD和传统SSD数据放置对比

    Figure  1.   Comparison of ZNS SSD and conventional SSD data placement

    图  2   Zone的结构

    Figure  2.   The structure of Zone

    图  3   CoW B+-tree更新过程示例

    Figure  3.   An example of CoW B+-tree update

    图  4   ZB+-tree逻辑结构

    Figure  4.   ZB+-tree logical structure

    图  5   ZB+-tree节点在ZNS SSD上的分布

    Figure  5.   Distribution of ZB+-tree nodes on ZNS SSD

    图  6   ZB+-tree节点状态转换

    Figure  6.   ZB+-tree node state transition

    图  7   leaf 和对应的leaf-log示例

    Figure  7.   An example of leaf and corresponding leaf-log

    图  8   leaf-head的结构

    Figure  8.   The structure of leaf-head

    图  9   Normal_apply 示意图

    Figure  9.   Normal_apply schematic

    图  10   Switch_apply 示意图

    Figure  10.   Switch_apply schematic

    图  11   Zipfian分布下运行时间对比

    Figure  11.   Running time comparison under the Zipfian distribution

    图  12   uniform分布下运行时间对比

    Figure  12.   Running time comparison under the uniform distribution

    图  13   latest分布下运行时间对比

    Figure  13.   Running time comparison under the latest distribution

    图  14   Zipfian分布下读次数对比

    Figure  14.   Read counts comparison under the Zipfian distribution

    图  15   uniform分布下读次数对比

    Figure  15.   Read counts comparison under the uniform distribution

    图  16   latest分布下读次数对比

    Figure  16.   Read counts comparison under the latest distribution

    图  17   Zipfian分布下写次数对比

    Figure  17.   Write counts comparison under the Zipfian distribution

    图  18   uniform分布下写次数对比

    Figure  18.   Write counts comparison under the uniform distribution

    图  19   latest分布下写次数对比

    Figure  19.   Write counts comparison under the latest distribution

    图  20   Cov-Zone和Seq-Zone不同比例下运行时间对比

    Figure  20.   Comparison of running time under different ratios of Cov-Zone and Seq-Zone

    图  21   ZB+-tree对Cov-Zone的占用率变化

    Figure  21.   Changes in the occupancy rate of Cov-Zone by ZB+-tree

    表  1   实验配置

    Table  1   Experimental Configuration

    服务器组件说明
    OSUbuntu 20.04.1 LTS
    CPUAMD EPYC 7742 64-Core@2.60GHz
    DRAM256GB DDR4 (2666 MHz)
    GCC version9.4.0
    libzbd version2.0.3
    下载: 导出CSV

    表  2   不同数据规模下Workload1下对Seq-Zone的占用率

    Table  2   Occupancy Rate of Seq-Zone Under Workload1 at Different Data Scales

    方案50万150万 250万
    ZB+-tree0.0004690.001543 0.002439
    CoW B+-tree0.1204310.402918 0.678303
    下载: 导出CSV

    表  3   不同数据规模下Workload2下对Seq-Zone的占用率

    Table  3   Occupancy Rate of Seq-Zone Under Workload2 at Different Data Scales

    方案50万150万 250万
    ZB+-tree0.0003850.001161 0.001882
    CoW B+-tree0.0866330.300859 0.513317
    下载: 导出CSV

    表  4   不同数据规模下Workload3下对Seq-Zone的占用率

    Table  4   Occupancy Rate of Seq-Zone Under Workload3 at Different Data Scales

    方案50万150万 250万
    ZB+-tree0.0004170.001371 0.002141
    CoW B+-tree0.1032620.353144 0.599624
    下载: 导出CSV

    表  5   不同数据规模下Workload4下对Seq-Zone的占用率

    Table  5   Occupancy Rate of Seq-Zone Under Workload4 at Different Data Scales

    方案50万150万 250万
    ZB+-tree0.0004980.001617 0.002613
    CoW B+-tree0.1322330.432777 0.739822
    下载: 导出CSV

    表  6   不同数据规模下Workload5下对Seq-Zone的占用率

    Table  6   Occupancy Rate of Seq-Zone Under Workload5 at Different Data Scales

    方案50万150万 250万
    ZB+-tree0.0003630.001025 0.001729
    CoW B+-tree0.0734750.262106 0.450943
    下载: 导出CSV

    表  7   不同比例下Workload1下对Seq-Zone的占用率

    Table  7   Occupancy Rate of Seq-Zone Under Workload1 at Different Ratios

    方案1∶321∶48 1∶64
    ZB+-tree0.0011250.000751 0.000562
    CoW B+-tree0.3211450.216282 0.163043
    下载: 导出CSV

    表  8   不同比例下Workload2下对Seq-Zone的占用率

    Table  8   Occupancy Rate of Seq-Zone Under Workload2 at Different Ratios

    方案1∶321∶48 1∶64
    ZB+-tree0.0009590.000638 0.000478
    CoW B+-tree0.2403390.161861 0.122018
    下载: 导出CSV
  • [1]

    Bjørling M, Aghayev A, Holmberg H, et al. ZNS: Avoiding the block interface tax for flash-based SSDs [C] //Proc of 2021 USENIX Annual Technical Conf (USENIX ATC 21). Berkeley, CA: USENIX Association, 2021: 689−703

    [2]

    Han K, Gwak H, Shin D, et al. ZNS+: Advanced zoned namespace interface for supporting in-storage zone compaction [C] //Proc of the 15th USENIX Symp on Operating Systems Design and Implementation (OSDI 21). Berkeley, CA: USENIX Association, 2021: 147−162

    [3]

    Stavrinos T, Berger D S, Katz-Bassett E, et al. Don't be a blockhead: Zoned namespaces make work on conventional SSDs obsolete[C] //Proc of the Workshop on Hot Topics in Operating Systems. New York: ACM, 2021: 144−151

    [4]

    Maheshwari U. From blocks to rocks: A natural extension of zoned namespaces[C] //Proc of the 13th ACM Workshop on Hot Topics in Storage and File Systems. New York: ACM, 2021: 21−27

    [5]

    Choi G, Lee K, Oh M, et al. A new LSM-style garbage collection scheme for ZNS SSDs [C] //Proc of the 12th USENIX Workshop on Hot Topics in Storage and File Systems (HotStorage 20). Berkeley, CA: USENIX Association, 2020: Article 1

    [6]

    Purandare D R, Wilcox P, Litz H, et al. Append is near: Log-based data management on ZNS SSDs[C/OL] //Proc of the 12th Annual Conf on Innovative Data Systems Research (CIDR’22). 2022[2022-08-20].https://www.ssrc.ucsc.edu/media/pubs/8698b15f3152427d1285a995af615fbe7be26c7b.pdf

    [7]

    Shin H, Oh M, Choi G, et al. Exploring performance characteristics of ZNS SSDs: Observation and implication[C/OL] //Proc of the 9th Non-Volatile Memory Systems and Applications Symp (NVMSA). Piscataway, NJ: IEEE, 2020[2022-08-20].https://ieeexplore.ieee.org/abstract/document/9188086

    [8]

    Park C, Cheon W, Kang J, et al. A reconfigurable FTL (flash translation layer) architecture for NAND flash-based applications[J/OL]. ACM Transactions on Embedded Computing Systems, 2008[2022-08-20].https://people.eecs.berkeley.edu/~kubitron/courses/cs262a/handouts/papers/a38-park.pdf

    [9]

    Bux W, Iliadis I. Performance of greedy garbage collection in flash-based solid-state drives[J]. Performance Evaluation, 2010, 67(11): 1172−1186 doi: 10.1016/j.peva.2010.07.003

    [10]

    Smith K. Understanding SSD over-provisioning [EB/OL]. 2022[2022-08-20].https://www.edn.com/understanding-ssd-over-provisioning

    [11]

    Hu Xiaoyu, Eleftheriou E, Haas R, et al. Write amplification analysis in flash-based solid state drives[C/OL] //Proc of 2009 Israeli Experimental Systems Conf (SYSTOR). New York: ACM , 2009[2022-08-20]. http://roman.pletka.ch/publications/hu2009write-ampl.pdf

    [12]

    Bjørling M. ZNS SDDs in Western Digital [EB/OL]. 2020[2022-08-20].https://snia.org/sites/default/files/SDC/2020/075-Bjørling-Zoned-Namespaces-ZNS-SSDs.pdf

    [13]

    Western Digital. NVMe Zoned Namespaces (ZNS) SSDs [EB/OL]. 2021[2022-08-20].https://zonedstorage.io/docs/introduction/zns

    [14]

    NVMe. Zoned Namespaces Command Set [EB/OL]. 2022[2022-08-20].https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-1.1b-2022.01.05-Ratified.pdf

    [15]

    Roh H, Park S, Kim S, et al. B+-tree index optimization by exploiting internal parallelism of flash-based solid state drives[J]. Proceedings of the VLDB Endowment, 2011, 5(4): 286−297 doi: 10.14778/2095686.2095688

    [16]

    Na G J, Lee S W, Moon B. Dynamic in-page logging for B+-tree index[J]. IEEE Transactions on Knowledge and Data Engineering, 2011, 24(7): 1231−1243

    [17]

    Agrawal D, Ganesan D, Sitaraman R, et al. Lazy-adaptive tree: An optimized index structure for flash devices[J]. Proceedings of the VLDB Endowment, 2009, 2(1): 361−372 doi: 10.14778/1687627.1687669

    [18]

    Ahn J S, Kang D, Jung D, et al. μ*-tree: An ordered index structure for NAND flash memory with adaptive page layout scheme[J]. IEEE Transactions on Computers, 2012, 62(4): 784−797

    [19]

    Fang Huawei, Yeh M, Suei P, et al. An adaptive endurance-aware B+-tree for flash memory storage systems[J]. IEEE Transactions on Computers, 2013, 63(11): 2661−2673

    [20]

    Jin Peiquan, Yang Chengcheng, Jensen C, et al. Read/write-optimized tree indexing for solid-state drives[J]. The VLDB Journal, 2016, 25(5): 695−717 doi: 10.1007/s00778-015-0406-1

    [21]

    Lv Yanfei, Li Jing, Cui Bin, et al. Log-compact R-tree: An efficient spatial index for SSD[C]//Proc of the Int Conf on Database Systems for Advanced Applications (DASFAA 11). Berlin: Springer, 2011: 202−213

    [22]

    Jin Peiquan, Yang Chengcheng, Wang Xiaoliang, et al. SAL-Hashing: A self-adaptive linear hashing index for SSDs[J]. IEEE Transactions on Knowledge and Data Engineering, 2020, 32(3): 519−532 doi: 10.1109/TKDE.2018.2884714

    [23]

    Ho V, Park D. WPCB-tree: A novel flash-aware B-tree index using a write pattern converter [J/OL]. Symmetry, 2018[2022-08-20].https://www.mdpi.com/2073 − 8994/10/1/18/pdf

    [24]

    Jin R, Cho H, Lee S, et al. Lazy-split B+-tree: A novel B+-tree index scheme for flash-based database systems[J]. Design Automation for Embedded Systems, 2013, 17(1): 167−191 doi: 10.1007/s10617-013-9123-4

    [25]

    Twigg A, Byde A, Miłoś G, et al. Stratified B-trees and versioned dictionaries[C] //Proc of the 3rd Workshop on Hot Topics in Storage and File Systems (HotStorage 11). Berkeley, CA: USENIX Association, 2011: Article 3

    [26] 闫玮,张兴军,纪泽宇,等. 基于持久性内存的单向移动B+树[J]. 计算机研究与发展,2021,58(2):371−383 doi: 10.7544/issn1000-1239.2021.20200403

    Yan Wei, Zhang Xingjun, Ji Zeyu, et al. One-direction shift B+-tree based on persistent memory[J]. Journal of Computer Research and Development, 2021, 58(2): 371−383 (in Chinese) doi: 10.7544/issn1000-1239.2021.20200403

    [27]

    Western Digital. null_blk [EB/OL]. 2022[2022-10-15].https://zonedstorage.io/docs/getting-started/zns-device

    [28]

    Western Digital. libzbd [EB/OL]. 2022[2022-08-20].https://github.com/westerndigitalcorporation/libzbd

    [29]

    Cooper B F, Silberstein A, Tam E, et al. Benchmarking cloud serving systems with YCSB[C] //Proc of the 1st ACM Symp on Cloud Computing (SoCC 10). New York: ACM, 2010: 143−154

  • 期刊类型引用(0)

    其他类型引用(2)

图(21)  /  表(8)
计量
  • 文章访问数:  415
  • HTML全文浏览量:  124
  • PDF下载量:  161
  • 被引次数: 2
出版历程
  • 收稿日期:  2022-06-10
  • 修回日期:  2022-11-03
  • 网络出版日期:  2023-02-26
  • 刊出日期:  2023-02-28

目录

/

返回文章
返回