CN119719052A - 键值存储库与文件系统 - Google Patents

Abstract

本公开的实施例涉及键值存储库与文件系统。键值存储库与文件系统被集成在一起以提供改进的操作。键值存储库可以包括日志引擎、哈希引擎、排序引擎、以及垃圾收集管理器。键值存储库的特征可以被配置为减少涉及文件系统的I/O操作数量，从而提高读取效率、减少写入时延、并且减少组合的键值存储库与文件系统中固有的写入放大问题。

Description

键值存储库与文件系统

技术领域

本公开针对键值存储库与文件系统，特别是用于提供云计算服务的集成的键值存储库与文件系统组合。

背景技术

典型的键值存储库(诸如，现有的数据库系统)使用日志结构化合并树。这些树提供快速的数据摄取，但是在写入放大、资源争用、相对较差的读取性能、以及计算开销方面可能存在权衡。

发明内容

本公开针对键值存储库与文件系统，特别是用于提供云计算服务的集成的键值存储库与文件系统组合。

通过实现减少写入放大和资源争用的键值分离机制，可以提高在数据写入操作期间的性能，尤其是对于处理包含大的值(例如，数十KB)的数据的云服务。

附加地，键值存储库与文件系统可以包括专用化引擎以满足具体的数据访问模式。第一引擎提供类似哈希表的读取性能，从而增强整体读取效率。第二引擎被设计成处理具有时间局部性的数据(诸如，预写入日志或木筏(raft)日志)，从而实现高性能数据摄取。

此外，可以通过优化底层文件系统的日记压缩来处理数据写入期间的被延长的尾时延问题。这种优化有助于减少写入操作的时延，从而提高整体系统性能。整体系统性能的提高可以包括减少CPU和存储消耗、提高吞吐量、以及降低时延。

在实施例中，一种包括键值系统、文件系统、以及协作层的系统。键值系统包括被配置为提供多个日志文件的并行写入的日志引擎，以及被配置为通过将索引信息存储在紧凑索引中来处理点查询的哈希引擎。键值系统还包括排序引擎，该排序引擎被配置为通过使用分区日志结构合并(LSM)树来处理范围扫描。该文件系统包括日志结构的仅附加写入模型。该协作层被配置为促进键值系统和文件系统之间的协作。

在实施例中，该文件系统被配置为基于键值系统更新数据但不更新与数据相关联的元数据。

在实施例中，该键值系统被配置为向文件系统提供数据以使数据在文件系统内持久。

在实施例中，哈希引擎被配置为将紧凑索引保留在高速缓存存储器中。在实施例中，索引信息被压缩。在实施例中，保留在高速缓存存储器中的索引信息是通过根据最近最少使用的策略去除索引信息中的一些索引信息而被选择的部分索引信息。

在实施例中，该日志引擎被配置为将多个用户操作合并成要与文件系统一起执行的单个I/O操作。在实施例中，多个用户操作的合并包括将多个用户操作放入到队列中，并且在预定条件发生时将队列冲刷到文件系统。

在实施例中，该排序引擎被配置为将来自第一LSM的数据拆分成多个分片，多个分片中的每个分片包含具有比第一LSM树更少层数的第二LSM树。在实施例中，该排序引擎包括作业调度器，该作业调度器被配置为优先处理冲刷操作和零级到一级压缩操作。在实施例中，该排序引擎包括分片管理器，该分片管理器被配置为指引对数据拆分，使得第二LSM树中的每个第二LSM树具有在预定范围内的层数。在实施例中，该排序引擎包括时间戳管理器，该时间戳管理器被配置为使得零级或一级应用具有针对相同键严格随时间增加的时间戳值。

在实施例中，该键值系统还包括垃圾收集模块，该模块被配置为将LSM树的多个层合并成LSM树的最后一层。在实施例中，协作层被配置为协调跨键值系统和文件系统的垃圾收集操作。在实施例中，协调垃圾收集操作包括：文件系统将区域使用信息暴露给键值系统，以及键值系统利用区域使用信息来确定要被压缩或垃圾收集的文件。在实施例中，垃圾收集模块被配置为基于与blob文件相关联的SST文件来确定blob文件内的垃圾数据的大小。在实施例中，SST文件包含在SST文件的末尾处的冗余键。

在实施例中，该文件系统包含超级块、日记、以及数据分量，超级块组件包含通用文件系统元数据，而日记包含文件系统操作日志的检查点。

在实施例中，该键值系统包括调度器，该调度器被配置为调度后台任务，使得由上层应用发出的每个输入/输出(I/O)请求具有一致的I/O放大。

在实施例中，该系统被配置为处理即时文件和通用文件，其中该文件系统在预定义的范围内针对通用文件分配存储空间。

附图说明

图1示出了根据实施例的键值存储库与文件系统的示意图。

图2示出了根据实施例的键值存储库与文件系统的模块。

图3示出了根据实施例的处理多个I/O流的键值存储库与文件系统。

图4示出了根据实施例的用于被共享日志的日志引擎的设计。

图5示出了根据实施例的用于共享日志的数据管理。

图6示出了根据实施例的元数据管理。

图7示出了根据实施例使元数据在盘上持久。

图8示出了根据实施例的哈希和排序引擎。

图9示出了根据实施例的哈希引擎。

图10示出了根据实施例的排序引擎。

图11示出了根据实施例的垃圾收集模块。

图12A示出了根据实施例的垃圾收集过程。

图12B示出了根据实施例的垃圾收集过程。

图13示出了根据实施例的垃圾收集的存储装置的模型。

图14示出了根据实施例的文件系统的盘布局。

图15示出了在盘运行时冲刷文件元数据变化和日志记录的方法。

图16示出了根据实施例的文件系统的I/O流路径。

图17示出了根据实施例的文件系统中的故障冗余。

图18示出了根据实施例的文件系统中的同步I/O操作。

具体实现方式

本公开涉及键值存储库与文件系统，特别是用于提供云计算服务的集成的键值存储库与文件系统组合。

在以下详细描述中，参考了构成该描述一部分的附图。在附图中，除非上下文另有规定，否则类似的符号通常表示类似的组件。此外，除非另有说明，否则后续附图的描述可以参考任何先前附图中的特征，以提供更清晰的上下文和当前示例实施例的实质性解释。然而，在详细描述、附图、以及权利要求中描述的示例实施例并非旨在限制。可以利用其他实施例，并且可以做出其他改变，而不会背离本文所呈现的主题的精神或范围。将容易理解的是，如本文中一般描述和叙述的以及附图中所示的本公开各方面可以以各种不同的配置进行布置、替换、组合、分离、以及设计，而所有这些在本文中都有明确考虑。

另外，本公开的各部分可以在本文中按照功能块组件和各种处理步骤来描述。应当了解，这种功能块可以由被配置为执行指定功能的任意数量的固件、软件、和/或硬件组件来实现。

图1示出了根据实施例的键值存储库与文件系统。键值存储库与文件系统100包括键值系统102。键值系统102包括日志引擎104、哈希引擎106、排序引擎108、以及垃圾收集管理器110。键值存储库与文件系统100还包括协作层112和文件系统114。键值存储库与文件系统100可以与内核空间116交互，内核空间116包括一个或多个盘118。键值存储库与文件系统100可以与应用120交互。

键值与文件系统100可以被用于云应用中的存储装置，例如，以提供云服务所需的数据持久性。键值系统102被配置为提供键值存储库，例如，作为云服务的存储后端的一部分。使用键值系统102的云服务的非限制性示例包括购物、社交媒体、元数据管理等。文件系统114可以是专用的用户级仅附加文件系统，其被配置为提供专门用以促进键值系统102操作的存储装置。

日志引擎104被配置为允许同时写入多个日志文件，从而减少压缩和垃圾收集操作的数量。日志引擎104写入的日志可以被配置为使得处理日志不需要强排序。日志引擎104被配置为，通过将日志的同步写入开销从多个输入/输出(I/O)操作减少到单个I/O操作、使用无锁队列聚合写入以控制时延并提高吞吐量、和/或提供异步接口以增强线程模型，改善日志写入中的吞吐量性能问题并提高恢复速度。在键值系统102和文件系统114被集成并且协作的情况下，日志引擎104可以被用于存储具有预定义结构的预写入日志(WAL)，该预定义结构具有所定义的实际文件大小。用于WAL的定义文件大小反过来可以引起需要更少的I/O操作，从而提高性能，同时减轻与数据一致性有关的潜在权衡。日志引擎104的操作在图4-图7中被进一步详述并且在下文中被描述。

哈希引擎106被配置为处理键值系统102内的点查询。特别地，哈希引擎106被配置为减少点查询中的尾时延。哈希引擎106包括数据和索引分量的分离，以及例如通过压缩索引和/或缓存部分数据而在高速缓存存储器中维持索引。可以使用例如最近最少使用的策略来选择该部分数据。哈希引擎106的操作在图8和图9中被进一步详述并且在下文中被描述。

排序引擎108被配置为执行范围扫描操作，同时减少与这种操作相关联的写入放大因子和/或读取/写入时延。排序引擎108被配置为可以使用分区日志结构合并(LSM)树。排序引擎108还可以执行对I/O流的分类和任务调度。排序引擎108的操作在图8和图10中被进一步详述并且在下文中被描述。

垃圾收集管理器110被配置为在键值存储库与文件系统100中执行垃圾收集和/或压缩操作。垃圾收集管理器110可以被配置为减少在键值存储库与文件系统100中进行垃圾收集和/或压缩操作期间不必要的数据移动。垃圾收集管理器110可以基于对应用侧数据删除(诸如，页面过期)的了解来进行垃圾收集和/或压缩操作。垃圾收集管理器110执行的垃圾收集和压缩可以被配置为布置数据以支持诸如排序引擎108的其他模块。垃圾收集管理器110可以在垃圾收集和/或压缩操作期间协调对数据的保存。垃圾收集管理器110的操作在图11-图13中被进一步详述并且在下文中被描述。

协作层112被配置为促进键值系统102与文件系统114之间的协作。基于键值系统102与文件系统114之间的协作，协作层112还可以促进键值系统102中的高效压缩和/或垃圾收集操作。该协作可以减少由压缩和/或垃圾收集操作引起的写入放大问题。在实施例中，协作层112可以将来自键值系统102的区域使用信息暴露给文件系统114。

文件系统114可以被配置为从日志中拆分出数据并使用日志结构的仅附加写入作为写入模型。在实施例中，该文件系统还可以提供预分配的数据空间，其中同步写入仅针对数据持久性而发生，并且在实施例中不需要使元数据持久。在实施例中，可以单独执行不同文件的数据持久性和全局日志持久性。文件系统的这些方面可以允许该文件系统避免一些元数据持久性操作，诸如由单个数据写入持久性操作引起的操作。

文件系统114可以被配置为支持通用文件和即时文件。通用文件和即时文件都可以被顺序写入，并且都可以被顺序或随机读取。通用文件可以针对顺序或随机读取中的持续低时延进行优化。通用文件可以被用于批量写入数据，每次写入后无需将数据(诸如，SST文件)冲刷到盘。存储空间以大的单元进行分配，单元大小的非限制性示例是1MB。大的分配单元可以减少通用文件的元数据大小，使得所有通用文件的元数据都可以在正常的文件系统操作期间被保存在存储器中。通过将元数据保存在存储器中，无论读取偏移量如何，对通用文件的读取操作都不需要进一步的I/O来访问元数据。这可以减少通用文件的读取尾时延。即时文件可以针对快速、增量的同步写入进行优化，同时在尾附近具有良好的顺序且随机的读取性能。即时文件可以被用于写入需要频繁冲刷到盘以实现即时耐久性的数据，诸如键值系统的预写入日志文件。对于即时文件，可以将每次单独写入的数据和元数据捆绑在一起。捆绑的数据和元数据可以被写入所有即时文件共享的日记文件。将数据捆绑并写入日记文件可以提高增量写入和同步操作的速度。这种方法被构造为支持顺序读取，但是在随机读取方面可能会有所权衡。由于即时文件预计大部分是顺序读取的，而随机读取主要集中在尾附近，因此可以缓存正在主动被写入的每个即时文件的最近写入的数据以提高读取性能。

文件系统114可以包括用户空间I/O调度器，以将I/O优先级分配给不同的I/O类型。I/O调度器将前台I/O标记为高优先级，而后台I/O将被标记为低优先级。另外，键值系统102可以包括用以调度其后台任务的调度器，以便确保上层应用发出的每个I/O具有一致的I/O放大。通过在键值系统102和文件系统114中共同设计I/O调度，由于I/O放大和I/O时延都是一致的，因此尾时延可以保持稳定且低。此外，从文件系统读取通用文件不需要元数据的I/O，并且将大空间用于通用文件可以确保大多数读取操作只需要单个I/O。

内核空间116可以包含盘118。盘118可以包括一个或多个存储介质，诸如固态驱动器(SSD)。在实施例中，至少一些盘118是分区存储(ZNS)SSD。

应用120是利用键值与文件系统100的任何合适的应用，例如，在线购物、社交媒体、元数据管理应用等。应用120可以通过任何合适的应用编程接口(API)与键值与文件系统100接合。在实施例中，该API可以特定于特定类型的文件，例如，该文件的性质是通用文件还是即时文件是由接收该文件的API确定的。

图2示出了根据实施例的键值存储库与文件系统的模块。键值存储库与文件系统200包括日志引擎202、哈希引擎204、排序引擎206、垃圾收集管理器208、以及文件系统210。

日志引擎202被配置为允许同时写入多个日志文件，从而减少压缩和垃圾收集操作的数量。日志引擎202写入的日志可以被配置为使得不需要强排序来处理日志。日志引擎202被配置为通过将日志的同步写入开销从多个输入/输出(I/O)操作减少到单个I/O操作、使用无锁队列聚合写入以控制时延、以及提高吞吐量、和/或提供异步接口以增强线程模型来改善日志写入中的吞吐量性能问题并提高恢复速度。日志引擎202的操作在图4-图7中被进一步详述并且在下文中被描述。

哈希引擎204被配置为处理键值存储库和文件存储系统200内的点查询。特别地，哈希引擎204被配置为减少点查询中的尾时延。哈希引擎204包括数据和索引分量的分离，以及例如通过压缩索引和/或缓存部分数据而在高速缓存存储器中维护索引。可以使用例如最近最少使用的策略来选择该部分数据。哈希引擎204的操作在图8和图9中被进一步详述并且在下文中被描述。

排序引擎206被配置为执行范围扫描操作，同时减少与这种操作相关联的写入放大因子和/或读取/写入时延。排序引擎206被配置为可以使用分区日志结构合并(LSM)树。I/O流分类和任务调度还可以由排序引擎206执行。排序引擎206的操作在图8和图10中被进一步详述并且在下文中被描述。

垃圾收集管理器208是用于键值存储库与文件系统200的主动垃圾收集管理器。垃圾收集管理器208可以被配置为在键值存储库与文件系统200中的垃圾收集和/或压缩操作期间减少不必要的数据移动。垃圾收集管理器208可以基于对应用侧数据删除(诸如，页面过期)的了解来进行垃圾收集和/或压缩操作。垃圾收集管理器208执行的垃圾收集和压缩可以被配置为布置数据以支持其他模块(诸如，排序引擎206)。垃圾收集管理器208可以在垃圾收集和/或压缩操作期间协调对数据的保存。垃圾收集管理器208的操作在图11-图13中被进一步详述并且在下文中被描述。

文件系统210可以是用于键值存储库的仅附加文件系统。文件系统210可以被配置为从日志中拆分出数据并使用日志结构的仅附加写入作为写入模型。在实施例中，文件系统210还可以提供预分配的数据空间，其中同步写入仅针对数据的持久性而发生，并且在实施例中不需要使元数据持久。在实施例中，可以单独执行不同文件的数据持久性和全局日志持久性。文件系统的这些方面可以允许文件系统避免一些元数据持久性操作，诸如由单个数据写入持久性操作引起的那些操作。

图3示出了根据实施例的处理多个I/O流的键值存储库与文件系统。图3示出了在图1和图2中所示并在本文中进一步描述的模块的利用。在图3中所示的实施例中，键值存储库与文件系统与MySQL兼容的OTLP数据库的页面服务器相接口。与MySQL兼容的OTLP数据库的页面服务器的接合是根据实施例的用于与键值存储库与文件系统接合的一个合适的应用的非限制性示例。如图3中所示，数据库页面服务器利用键值存储库与文件系统来存储基页面、MVPage、增量日志、以及重做日志中的每一项。该键值与文件系统可以使用日志引擎对来自数据库页面服务器的重做日志进行索引并使其持久。这些操作可以具有每个为1的读取和写入放大。MVPage可以利用哈希引擎来被处理。增量日志和元数据可以分别利用排序引擎来被处理。

图4示出了根据实施例的用于被共享日志的日志引擎的设计。该日志引擎被配置为将日志数据存储在上层软件中，例如，存储在数据库软件中。该日志引擎可以提供两个接口类，LogFile和LogFileFactory。LogFile类被配置为充当文件描述符，而LogFileFactory类被配置为作为文件系统。该日志引擎被配置为使得减少在SSD上的随机写入。减少对SSD的随机写入可以减少尾时延，并且可以提高管理存储器内文件元数据更新的效率。可以使用唯一的序列号对操作进行排序，从而确保盘上的顺序。通过对日志文件的循环冗余校验保护实现了高可靠性。由日志引擎提供的冗余校验保护可以实现上层软件的错误恢复。该日志引擎可以被配置为聚合日志数据并实现无锁队列。日志引擎中的排队可以减少用户线程阻塞。另外，该日志引擎可以在存储器内元数据达到一定大小时通过后台线程将其保存到底层文件系统，从而高效使用数据存储器使用。在实施例中，高效的数据存储器使用可以通过大约0.1％或更低的数据存储器使用来表示。

图4中所示的日志引擎可以包括用户界面管理器，该管理器被配置为例如通过同步或异步API来接收用户请求(诸如图4中所示的Op1和Op2)。该日志引擎还可以包括内部层，该内部层被配置为管理元数据、共享日志和后台任务。图4中所示的日志引擎还包括后台层，该后台层被配置为例如通过将日志写入物理日志以便使这些日志持久而与文件系统相接口。图4中所示的日志引擎被配置为创建共享日志，这可以合并多个用户操作。这种用户操作的非限制性示例包括附加、创建、删除、修剪、以及截断操作。这些合并的操作可以用对文件系统的单个I/O请求而被处理，从而允许减少总体I/O请求的数量。特别地，所接收的操作从入队状态变为内部层的输入队列。内部层被配置为在特定条件下(诸如，后台线程可用时)将输入队列与输出队列交换，此时输出队列可以将输入队列的所有先前内容冲刷到文件系统，从而通过单个I/O操作使当前的输入队列中的各种请求持久保存在文件系统中。

在实施例中，可以使用多个共享日志实例来管理不同形式的数据，诸如用户数据、元数据、以及其他文件。用户数据可以是日志引擎所存储的日志数据。用于改进读取操作的元数据也可以被包括在日志引擎内的共享日志实例中。元数据管理可以包括使用标准映射的存储器内元数据存储模块和存储装置存储器上的持久元数据存储装置中的一者或两者。持久元数据存储装置可以采用例如日志结构化合并(LSM)类的格式的形式。日志引擎内的元数据管理在下文中被描述并且在图6中被示出。

图5示出了根据实施例的被共享日志的数据管理。如图5中所示，客户端请求三个分开的“附加”操作。日志引擎在入队时接收这些操作。从入队器中，这些操作如上文关于图4所述而被添加到共享日志中，将接收到的用户操作打包成日志记录并等待后台线程将所有请求冲刷到盘，如DataLog中所示使日志更新持久，其中相应的记录各自包括对应的请求附加。

图6示出了根据实施例的元数据管理。特别地，图6示出了来自客户端的附加、创建、删除、以及修剪请求，以及响应请求在存储器和盘中的操作。如上文所述并在图4和5中示出的，元数据管理可以由日志引擎执行。元数据管理可以包括管理文件系统的命名空间和文件映射、处理每个日志文件的存储器元数据、以及通过写入盘来实现用于元数据持久的机制。命名空间可以维持文件名到文件标识符(fid)的映射，而文件映射可以跟踪fid到持久元数据实例(诸如，上面关于图4讨论的LSM格式元数据)的映射。每个LSM元实例可以维持日志序列号(LSN)到底层文件系统中日志记录地点的映射(例如，lsn:<fid,offset,lsn>)。LSM元实例可以包括存储器中的0级(L0，直接索引)和1级(L1，间接索引)部分。

对于附加操作，对应的条目被添加到相应的日志文件的元数据。在实施例中，建议每个这种条目的大小约为24B左右，从而占1k记录大小的总数据的约3％。随着日志数据的增长，元数据所占用的存储器会显著增长，例如，对于1T的盘，元数据接近30GB。因此，将所有的日志文件元数据存储在存储器中变得不可行。相反，日志引擎可以定期将日志文件元数据写入盘以使日志文件元数据持久。使日志文件元数据持久可以是一种涉及频繁写入和不频繁读取的访问模式，并且读取最近写入的数据的可能性高。为了处理这个问题，日志引擎可以在存储器中维持最新的元数据条目，将较旧的条目写入盘，并且使用存储器中的间接映射表来指向盘上的元数据条目。

图7示出了根据实施例使元数据在盘上持久。使元数据持久可以包括日志文件创建和/或删除。使元数据持久可以包括对命名空间和文件映射的修改、修剪日志文件、要求对LSM元数据采取行动以实现高效的元数据管理、和/或“L0Dump”操作，其涉及通过将L0映射写入盘并在L1中保存L0映射的盘上地点而使L0映射持久。

图8示出了根据实施例的哈希和排序引擎。组合引擎800包括哈希引擎802和排序引擎804。哈希引擎802包括哈希引擎分片806，每个分片806包括存储器存储库808和盘存储库810。排序引擎804包括排序引擎分片812，每个分片812包括存储器存储库814和盘存储库816。组合引擎800还包括预写入日志(WAL)818、存储器存储(Memstore)管理器820、分片管理器822。组合引擎800还可以包括后台工作器824以运行包括组合引擎800的系统的后台任务，例如，压缩和/或垃圾收集。

组合引擎800包括用于处理点查询的哈希引擎802和用于进行范围查询的排序引擎804。

哈希引擎802被配置为处理点查询。在实施例中，哈希引擎802被配置为分离索引和数据分量，并且被配置为将索引分量存储在高速缓存存储器中。该索引分量可以通过压缩(诸如CritBitTrie压缩和/或缓存部分数据(诸如使用用以标识最有可能被查询的数据的最近最少使用(LRU)策略选择的数据))而被存储在高速缓存存储器中，使得高速缓存存储器中的索引命中率可以最大化。哈希引擎802还可以被配置为使得，在发生缓存未命中的情况下(其中与点查询相关的索引数据不在高速缓存存储器中)，需要最少数量的盘I/O请求来响应查询。在实施例中，当发生缓存未命中时，哈希引擎802可以仅需要一次盘I/O请求来响应查询。

哈希引擎802可以被分为哈希引擎分片806，每个哈希引擎分片包括存储器存储库808和盘存储库810。存储器存储库808是高速缓存存储器，其配置为存储索引数据，例如压缩索引数据或使用LRU策略选择的索引数据以便在存储器存储库808内适合。盘存储库810是持久性存储装置，其被配置为包含blob文件和blob文件索引。当缓存命中时，可以例如根据来自存储器存储库808的索引数据而引用blob文件来响应点查询。当缓存未命中时，可以引用blob文件索引以通过访问盘存储库810的最少数量I/O操作而获得所需的索引信息。

排序引擎804被配置为响应范围查询。排序引擎804被配置为减少与响应范围查询相关联的读写时延和写入放大。排序引擎804可以包括对I/O任务进行分类和对应的调度以减少的读写时延。排序引擎804还可以包括对数据库的LSM树进行分割以减少这种树的层数，从而减少写入放大。在实施例中，分割LSM树可以由分片管理器822执行。此外，排序引擎本身可以包括排序引擎分片812。每个排序引擎分片812可以包括用于LSM树的相应分区及其数据的相应存储器存储库814和盘存储库816。有关排序引擎804的示例的更多细节在图10中被提供并且如下所述。

预写入日志(WAL)818可以提供日志，其中可以在通过数据写入操作对数据库进行永久改变之前在安全存储装置中执行数据写入操作。WAL 818可以提供更高的安全性和耐用性，从而在发生崩溃时提高恢复能力。

存储器存储管理器820是用于哈希引擎802和排序引擎812中的一者或两者的存储器管理模块。存储器存储管理器820可以包括任何合适的硬件、软件、及其组合，以用于执行本文所述的存储器管理。存储器存储管理器820可以包括对哈希引擎802的缓存的控制，

分片管理器822控制将哈希引擎802和排序引擎804分片成相应的分片806、812。分片管理器822可以被配置为组织相应的分片806、812，以便提供数据隔离。数据隔离可以减少垃圾收集期间不必要的复制。此外，分片管理器822可以组织分片806、812，使得分片具有其自己的索引管理。通过对分片806、812进行划分以简化索引管理，分片管理器可以由此减少索引开销并减少适应索引开销所需的计算资源。分片管理器822还可以控制哈希引擎802和/或排序引擎804的分片以控制资源需求，以便支持多租户操作。分片管理器822还可以执行数据库的LSM树的分割，以减少用于排序引擎804的写入放大。

图9示出了根据实施例的哈希引擎分片的索引结构。高速缓存存储器900包含第一级紧凑索引902和一个或多个第二级紧凑索引904。存储存储器906包含blob文件908，每个blob文件具有blob文件摘要910。

高速缓存存储器900是与存储装置存储器906分离的高速缓存存储器。高速缓存存储器900可以包括一个或多个适合高速缓存操作的存储器设备，诸如动态随机存取存储器(DRAM)、持久存储器(PMEM)、一个或多个SSD(诸如NVMeSSD)等。高速缓存存储器被配置为存储紧凑索引。在实施例中，可以在不需要访问存储装置存储器906的情况下访问紧凑索引。紧凑索引可以包含通过从blob文件908中的数据分量中分离键值而获得的键值。在实施例中，键值分离机制利用LSM树结构，从而提供诸如块级盘索引和压缩数据块的优点以减少索引开销。在实施例中，紧凑索引可以响应于点查询来标识数据，而无需访问存储装置存储器906。高速存储在高速缓存存储器900中的紧凑索引可以包括第一级紧凑索引902和第二级紧凑索引904。

第一级紧凑索引902将键映射到blob文件908的blob文件编号(blob_file_no)。第一级紧凑索引可以被存储在任何合适的文件中，例如，驻留在SST文件中。每个SST文件可以具有相关联的SST文件摘要，该摘要可以包含第一级紧凑索引902。第一级紧凑索引902可以根据LSM树结构进行组织，从而以LSM树形式接收键值分离的结果并相应地进行存储。

第二级紧凑索引904将键映射到blob文件908内的块偏移量(block_offset)。每个blob文件908可以具有对应的blob文件摘要910，该摘要910包含由相应的第二级紧凑索引904引用的偏移量。对于第二级紧凑索引904，可以为每个对应的blob文件908生成blob文件摘要910以存储与每个第二级紧凑索引904相对应的偏移量。

存储装置存储器906是被配置为存储数据库的数据(诸如blob文件908)的存储器。存储装置存储器906可以是任何合适的存储装置存储器，诸如一个或多个PMEM、SSD、硬盘驱动器(HDD)、及其组合等。Blob文件908是二进制大对象(诸如二进制数据的组块(chunk))，例如，二进制数据编码大对象，作为非限制性示例，诸如视频、音频、图像、及其组合等。Blob文件可以包括Blob文件摘要910，摘要910包含第二级紧凑索引所引用的数据，使得Blob文件摘要910可以根据第二级紧凑索引904中提供的偏移量来标识有效数据块。

图10示出了根据实施例的排序引擎。排序引擎1000被配置为组织和管理数据以支持范围扫描并减少这种过程的写入放大和时延。排序引擎1000包括分片1002、作业调度器1004、I/O分类1006、共同设计的压缩和垃圾收集1008、压缩1010、以及垃圾收集1012。排序引擎1000还可以包括存储器存储管理器1014、分片管理器1016、容错1018、异步API 1020、多租户模块1022、以及时间戳管理器1024。输入/输出(I/O)层1026可以与存储装置1028通信。

排序引擎1000被配置为生成分片1002，以将数据从大型LSM树结构拆分成分片1002内的较小LSM树结构。对LSM树结构进行分片减少了每棵树的层数，从而减少了写入放大。将LSM树分割为分片1002可以由分片管理器1016执行。

作业调度器1004是指这样的组件或模块，其被编程、设计、或以其他方式被配置为协作以确保到和来自存储装置的单独I/O操作的稳定时延。作业调度器1004可以被配置为减少或避免不利条件(诸如写入停顿或写入停止)以增强甚至优化数据取回并减少尾时延。作业调度器1004可以被配置为基于其优先级来区分不同的后台任务并为它们分配不同的I/O带宽资源。在实施例中，后台任务可以被分类为三种不同的优先级类型。在该实施例中，作业调度器1004可以优先确保快速冲刷，这意味着冲刷操作具有最高优先级。快速冲刷在存储器的写入缓冲区中清除足够的空间，从而以及的方式容纳前台写入请求。冲刷速度直接影响到写入尾时延。在该实施例中，L0到L1压缩任务可以有第二优先级。如果L0到L1压缩速度慢，则它直接增加读取I/O操作的数量，从而延长读取尾时延。在本实施例中，可以将L1到L(N)压缩的优先级设置为最低优先级。这些压缩任务主要被用于维持LSM树的形式，并且在短期内不会对读取写入时延产生明显影响。

优先考虑冲刷过程可以减少写入停顿或写入停止的情况，因为这些问题的主要原因是写入缓冲区已满。因此，保持冲刷速度可以减少写入停顿和写入停止。

在排序引擎1000中，读取I/O放大可能受L0文件数量的影响。L0文件数量的增加可能是由于L0到L1压缩速度缓慢而发生的，这可能是由于例如在更高级别的压缩正在进行时L0到L1压缩的排队延迟和/或并发的更高级别的压缩占用了L0到L1压缩的I/O带宽而造成的。因此，作业调度器1004可以优先于其他压缩为L0到L1压缩赋予优先级。

I/O分类1006可以实现优先级分类和调度方法，包括收集性能指标(诸如，请求时延和盘I/O吞吐量)以分析不同操作的模式。通过识别诸如顺序或随机访问的模式，可以为I/O操作分配适当的优先级，诸如“高”、“中”和“低”三个层级。在实施例中，自适应机制可以基于实时观察和优先级分配的历史影响不断地调整优先级。机器学习技术可以提高预测准确性和优先级调整。线程池分配系统可以动态地将线程分配给不同的优先级，从而确保及时执行高优先级任务。在实施例中，还可以提供手动用户覆盖以处理例外情况。

此外，调整优先级的功能可以利用请求并收集性能指标，并且可以基于所识别的模式为请求分配适当的优先级。收集性能指标和识别模式的实际实现包括测量和分析各种指标以做出明智的优先级决策。此外，为了增强模式检测和优先级分配，可以采用机器学习技术，包括聚类、异常检测、时间序列分析、决策树、神经网络、梯度提升、主成分分析、强化学习、以及自组织映射。这些方法共同提供了用于有效自适应行为识别和优先级分配的多功能工具。

共同设计的压缩和垃圾收集1008可以与文件系统协作，通过与文件系统中的垃圾收集协调地执行压缩和垃圾收集来减少端到端写入放大。共同设计的压缩和垃圾收集1008可以例如根据来自文件系统的区域使用信息进行操作。

压缩1010被配置为在排序引擎1000内执行压缩任务。垃圾收集1012被配置为在排序引擎1000内执行垃圾收集任务。压缩1010和垃圾收集1012可以被控制以根据作业调度器1004、I/O分类1006、和/或共同设计的压缩和垃圾收集1008的输出进行操作。

存储器存储管理器1014是用于存储器管理的模块。存储器存储管理器110可以包括任何合适的硬件、软件、及其组合以用于执行存储器管理，例如，在根据分片管理器1016生成分片1002时管理存储器。

分片管理器1016是这样的组件或模块，其被编程、设计、或以其他方式被配置为自动或手动将大型LSM树结构中的数据拆分成较小的LSM树结构(诸如，分片1002)。由分片管理器1016执行的分片从而减少了LSM树中的总层数，从而减少了写入放大。当LSM树结构内的数据达到某阈值时，分片管理器1016可以将LSM树拆分成分片1002，或者将大分片1002拆分成较小的分开的分片1002。相反，当数据结构内的数据由于删除而减并且其数据量低于具体阈值时，分片管理器可以例如在待合的分片的相应数据量低于预定阈值时合并相邻的分片以形成单个较大的分片。

分片管理器1016可以被配置为确保拆分操作的原子性，使得拆分操作完全成功或完全失败，而不会在其他数据失败时拆分相应分片中的任何数据。然后，任何失败的操作被回滚以保持数据完整性。分片管理器1016可以被配置为，例如通过将LSM级别的总数保持在固定范围内，进行操作以便减少对前端I/O操作的影响。如上所述，分割的LSM相对于常规LSM有利地减少了读写放大，因为每个分割的LSM本身都是一个独立的LSM树，因此只需要管理层数较少的较小数据卷，从而减少预读写文件。分片管理器1016提供的分割的LSM还可以允许更积极的层级压缩以减少WAF，促进租户隔离和自适应策略，从而更容易实现自适应策略(诸如，针对各种分割的不同压缩策略)并控制租户隔离，从而实现具有局部性特性的工作负载的更好权衡并同时减少写入放大而不损害读取性能。

容错1018是这样的组件或模块，其被编程、设计、或以其他方式被配置为提供扇区级容错能力，使得文件内的单个扇区损坏不会影响数据一致性和可见性。为了防止盘上的个别扇区损坏导致具体的文件或数据无法读取，从而导致上层分布式系统的整个数据库数据需要重建，可以生成关键文件数据的数据冗余块以确保即使文件内的若干连续扇区损坏也能够正确恢复文件的数据。备选地或者附加地，文件系统可以为元数据提供冗余保护，以防止元数据的不可用导致整个文件系统无法读取。

异步API 1020是这样的组件或模块，其被编程、设计、或以其他方式被配置为管理往返于存储装置的I/O操作，以使I/O等待不会阻塞上层线程执行其他任务。异步API 1020可以与底层文件系统协作以缓解I/O操作的阻塞，从而通过协作选择用于执行异步任务和异步任务回调的执行器来改善并行性、时延、以及响应时间。

多租户模块1022是这样的组件或模块，其被编程、设计、或以其他方式被配置为提供分片级资源限制和隔离，因为上层应用(例如，L0或L1)可能对不同的分片具有不同的资源使用限制。这种资源的非限制性示例包括I/O带宽、存储器大小、以及线程数(例如，异步I/O执行线程/压缩线程的数量)，因为上层应用被配置为具有用于各种引擎和分片的资源使用上限。另外，多租户管理器140被编程、设计、或以其他方式被配置为提供有关每种资源类型使用的定期监视和结果统计，从而允许上层基于其资源监视状态来动态调整不同分片上每种资源类型的配额值，从而促进多租户功能性。多租户模块1022可以被设计、或以其他方式被配置为监视每个分片的实时资源使用状态，例如使得上层应用可以相应地动态调整每个分片的配额值，从而最大化资源利用率。

时间戳管理器1024是这样的组件或模块，其被编程、设计、或以其他方式被配置为自动或手动为每个键值对加盖时间戳。这些时间戳可以被利用来实现多版本并发控制(MVCC)相关特征。时间戳管理器1024可以被配置为使得上层应用(例如L0或L1)具有针对相同键随时间严格增加的时间戳值，从而确保读取过程中的预期行为。用户时间戳可以与用户键组合，并且作为统一键被存储在排序引擎1000内。在编码期间，时间戳可以被用于确保排序引擎1000中的内部键首先被排序。时间戳管理器1024的功能可以得到读取、写入、以及删除功能的支持。例如，时间戳可以与各种操作相关联。垃圾收集和/或压缩过程可以去除过期的时间戳数据以促进数据完整性，由此在达到容量限制时触发主动压缩，从而回收存储空间。如本文所描述和列举的时间戳管理器1024显著增强了稳健性和效率，为时间戳管理提供了全面的支持，确保了数据完整性，并且优化了存储利用率。

图11示出了根据实施例的垃圾收集模块。图11的垃圾收集模块被配置为减少垃圾收集和压缩期间不必要的数据移动。特别地，垃圾收集模块可以提供定期压缩以清理应用的过期页面。定期垃圾收集可以包括将来自LSM树的同一页面的多层合并成最后一层，并且上层可以在压缩过程中执行对应的功能。这可以减少在垃圾收集期间处理的数据量。通过以入口级别而不是以空间级别基于垃圾率，还可以使垃圾收集被更准确并且更精确地被调度。这可以通过选择具有最高垃圾空间的blob文件进行垃圾收集来实现。通过以入口级别执行该计算，可以确保选择具有最高垃圾空间的blob文件，从而实现更高效的GC操作。垃圾收集策略可以被进一步改进，例如使该策略考虑更广泛的场景，从而提高高水位期间的并发性并提高空间回收率。

在实施例中，垃圾收集可以被配置为，通过定期压缩来减少相关的读取放大，以减少在垃圾收集期间对已过期但未被KV侧页面识别的应用数据的不必要的数据移动。可以通过提供API来确定SST内的应用垃圾数据量，该API允许应用处理用于确定应用垃圾数据量的具体决策过程。例如，可以利用来自数据的表属性信息来计算垃圾数据量。在具体的时间点，如果段的可回收日志序列号(LSN)超过阈值，则其表明该SST段内的所有数据都被视为垃圾。通过比较段ID并聚合结果，可以确定整个SST中垃圾数据的精确大小。重要的是要注意，这里提到的垃圾数据的大小不是指SST本身内的垃圾数据的大小，而是指对应的Blob内的大小，这准确地反映了垃圾数据的总量。这可以是随后要经受垃圾收集操作的数据。

图12A和图12B示出了根据实施例的垃圾收集过程。自适应垃圾收集可以包括例如通过与文件系统接合来确定容量使用和/或可用容量。这可以允许扫描该实例的当前目录中的所有文件的大小，使得我们可以了解容量使用情况。自适应垃圾收集过程可以包括基于可用容量来调整垃圾收集阈值、带宽、以及并发性。例如，基于容量情况，可以根据预先设计的策略来调整垃圾比率阈值和GC线程数。图12B示出了图12A的垃圾收集过程，其中存在多个垃圾收集线程，这些线程被分配给资源并基于与阈值相比的这些资源的相应利用程度而被操作。

图13示出了根据实施例的用于垃圾收集的存储装置的模型。在图13的存储装置的模型中，完整的冗余键集1302被存储在SST文件1300的末尾。冗余键集1302的存在使得在垃圾收集的反向检查期间无需扫描整个SST文件1300，这需要检查所有键的有效性，否则需要从头到尾扫描整个SST。在垃圾收集期间，只需要读取在SST文件1300末尾的冗余键集1302。对于无效键，可以跳过对应的值，而对于有效键，可以取回相应的值。跳过无效键可以通过使能仅取回有效值而减少读取放大。在图13中，每个键值对占用一个专用的数据块，存储在索引块中的键信息是数据块中键的完整表示。因此，索引块包含SST的全面键信息。

根据实施例的文件系统可以被配置为从日志中拆分出数据并且使用日志结构的仅附加写入作为写入模型。在实施例中，该文件系统还可以提供预分配的数据空间，其中同步写入仅针对数据持久性而发生，并且在实施例中不需要使元数据持久。在实施例中，可以单独执行针对不同文件的数据持久性和全局日志持久性。文件系统的这些方面可以允许文件系统避免一些元数据持久性操作，诸如由单个数据写入持久性操作引起的那些操作。

根据实施例的文件系统支持通用文件和即时文件。通用文件和即时文件都可以被顺序写入，并且都可以被顺序或随机读取。通用文件可以针对顺序或随机读取中的持续低时延进行优化。通用文件可以被用于批量写入数据，每次写入后无需将数据(诸如SST文件)冲刷到盘。存储空间以大单元进行分配，单元大小的非限制性示例是1MB。大分配单元可以减少通用文件的元数据大小，使得所有通用文件的元数据都可以在正常的文件系统操作期间被保存在存储器中。通过将元数据保存在存储器中，无论读取偏移量如何，对通用文件的读取操作都不需要进一步的I/O来访问元数据。这可以减少通用文件的读取尾时延。即时文件可以针对快速、增量的同步写入进行优化，同时在尾附近具有良好的顺序且随机的读取性能。即时文件可以被用于写入需要频繁冲刷到盘以实现即时耐用性的数据，诸如键值系统的预写入日志文件。对于即时文件，可以将每次单独写入的数据和元数据捆绑在一起。捆绑的数据和元数据可以被写入所有即时文件共享的日记文件。将数据捆绑并写入日记文件可以提高增量写入和同步操作的速度。这种方法被构造为支持顺序读取，但在随机读取方面可能会有所权衡。由于即时文件预计大部分是顺序读取的，而随机读取主要集中在尾附近，因此可以缓存正在主动被写入的每个即时文件的最近写入的数据以提高读取性能。

图14示出了根据实施例的文件系统的盘布局。图14可以被用作本文所述的任何文件系统(诸如上述且分别在图1和图2中示出的文件系统114和210)的盘布局。文件系统1400包括三种不同类型的数据：超级块1402、日记1404、以及数据1406。超级块1402包括必要的全局文件系统元数据，包括日记索引节点(inode)内容、通用唯一标识符(UUID)数据、版本信息、块大小、以及其他相关参数。在实施例中，它被战略性地定位在存储设备的第二个4KB处，其中超级块1402的战略定位被选择以提高可访问性和与其他数据分量的协调性。日记1404是从文件系统的操作日志中捕获最新检查点的数据。日记1404可以在文件系统的安装过程中被有效地重放，以改进存储器内文件元数据的恢复过程。最后，数据1406专用于存储文件系统内各个文件的实际内容。在实施例中，每个数据块被组织为逻辑块地址(LBA)的连续范围。

图15示出了在盘运行时冲刷文件元数据变化和日志记录的方法。方法1500包括更新存储器中的数据1502、将数据同步到设备1504、以及将元数据同步到设备1506。在1502处更新存储器内数据包括使用操作将数据附加到文件的内部写入缓冲区。在附加数据时，系统检查写入缓冲区的长度是否已达到指定阈值，这种阈值的非限制性示例为512KB。如果达到阈值，则将数据冲刷到存储设备。通过在1504处将数据同步到设备，可以将数据冲刷到存储设备。在1504处将数据同步到设备可以包括执行冲刷操作，其中将写入缓冲区中的数据写入存储设备。另外，在1504处将数据同步到设备可以包括标记文件并将文件添加到全局标记文件列表，以指示该文件具有待定的改变。此外，在1506处可以将元数据同步到设备。在1506处将元数据同步到设备可以通过调用用于确保数据持久性的函数来执行。该函数可以强制将文件的内部写入缓冲区写入到存储设备，以确保数据被安全存储。该函数可以是“fsync()”函数。在实施例中，在1504处将数据同步到设备期间标记的所有标记记录都可以在最后一次同步日志数据之后被同步到设备上的日记文件。该步骤有助于在各种计算环境中保持文件元数据变化的耐用性和一致性。另外，在1506处将元数据同步到设备时，可以更新对标记文件的事务记录。该事务记录可以以上一节所述而被格式化，然后被冲刷到日记文件。该过程可以确保文件元数据变化的耐用性和一致性，从而增强各种计算环境中键值存储库与文件系统的可靠性和性能。

图16示出了根据实施例的文件系统的I/O流路径。该文件系统可以包括用户空间I/O调度器，该调度器将I/O优先级分派给不同的I/O类型。I/O调度器可以将前台I/O标记为高优先级，而后台I/O可以被标记为低优先级。另外，键值系统包括调度器来调度其后台任务，以便确保上层应用发出的每个I/O具有一致的I/O放大。通过键值系统和文件系统中I/O调度的这种共同设计，由于I/O放大和I/O时延都是一致的，因此尾时延可以保持稳定且较低。此外，从文件系统读取通用文件不需要元数据1606的I/O，并且通用文件的受控大小可以确保大多数读取需要单个I/O操作。该文件系统可以使用“fdatasync”操作来更新数据，无需更新元数据。除非需要为通用文件创建一个新的受控大小的组块，否则无需同步文件大小即可更新用户数据。这种优化减少了不必要的文件元数据同步，从而提高了性能、增强了数据一致性，并且将日志引擎中的整体写入放大因子降低1，而不会影响同步任务。该文件系统可以利用专用化文件类型来支持高效的同步I/O。该文件系统可以将日志引擎的数据存储在盘上的专用化文件类型中，从而允许进行压缩任务。该文件系统可以协调垃圾收集与键值系统，例如，通过将区域使用信息公开给键值系统，而键值系统可以使用该信息来决定对哪个文件运行压缩或垃圾收集。键值系统可以被配置为设置文件系统的I/O调度器的优先级。例如，键值系统可以将前台I/O标记为高优先级，而后台I/O将被标记为文件系统的低优先级。另外，键值系统可以调度其后台任务，使得由上层应用发出的每个I/O具有一致的I/O放大。通过键值系统和文件系统的这种共同设计，由于I/O放大和I/O时延都是一致的，因此尾时延可以保持稳定且低。此外，读取通用文件1600不需要元数据的I/O，并且定义的大小(诸如，每个1MB)确保大多数读取只需要单个I/O。

图17示出了根据实施例的文件系统中的故障冗余。图17示出了数据存储系统、文件系统、以及键值存储库之间的交互。如图17中所示，文件系统被配置为提供用于文件系统元数据的扇区级冗余。该文件系统的结构允许在一个或两个扇区故障内从数据存储系统恢复数据。在实施例中，该键值系统被配置为向文件系统提供数据，以实现用于键值存储库的文件数据的扇区级冗余。扇区级冗余可以减小故障的冲击半径，从而减小其影响。

图18示出了根据实施例的文件系统中的同步I/O操作。虽然使用普通文件同步可以减少时延，但是该操作包括两个写入操作，一个用于更新元数据，另一个用于更新数据。根据实施例的文件系统和键值系统可以使用文件数据同步，更新数据而不更新元数据。通过减少不必要的文件元数据同步，使用文件数据同步操作可以提高性能、增强数据一致性，并且将整体写入放大因子(WAF)降低1，在同时成功执行必要的同步任务。该键值系统可以将来自日志引擎的数据保存在专门用于同步I/O效率的文件类型中。使用这些专用化文件还可以为非阻塞压缩任务授权键值存储库，如图18中所示。例如通过文件系统将区域使用信息公开给键值系统，文件系统和键值系统还可以协作以减少写入放大。键值系统可以利用区域使用信息做出有关压缩和/或垃圾收集操作的决策。

各方面：

方面1.一种包括键值系统、文件系统、以及协作层的系统，其中：

键值系统包括：

日志引擎，该日志引擎被配置为提供多个日志文件的并行写入，

哈希引擎，该哈希引擎被配置为通过将索引信息存储在紧凑索引中来处理点查询，以及

排序引擎，该排序引擎被配置为通过使用分割的日志结构合并(LSM)树来处理范围扫描；

文件系统包括日志结构的仅附加写入模型；以及

协作层被配置为促进该键值系统与该文件系统之间的协作。

方面2.根据方面1所述的系统，其中该文件系统被配置为基于该键值系统更新数据但不更新与数据相关联的元数据。

方面3.根据方面1-2中任一项所述的系统，其中该键值系统被配置为向该文件系统提供数据以使数据在该文件系统内持久。

方面4.根据方面1-3中任一项所述的系统，其中该哈希引擎被配置为将该紧凑索引保留在高速缓存存储器中。

方面5.根据方面4所述的系统，其中该索引信息被压缩。

方面6.根据方面4-5中任一项所述的系统，其中保留在该高速缓存存储器中的该索引信息是通过根据最近最少使用的策略省略索引信息中的一些索引信息而被选择的部分索引信息。

方面7.根据方面1-6中任一项所述的系统，其中该日志引擎被配置为将多个用户操作合并成要与该文件系统一起执行的单个I/O操作。

方面8.根据方面7所述的系统，其中多个用户操作的所述合并包括将所述多个用户操作放入到队列中，并且在预定条件发生时将该队列冲刷到该文件系统。

方面9.根据方面1-8中任一项所述的系统，其中该排序引擎被配置为将来自第一LSM树的数据拆分成多个分片，多个分片中的每个分片包含具有比该第一日志结构合并树更少层的第二LSM树。

方面10.根据方面9所述的系统，其中该排序引擎包括作业调度器，该作业调度器被配置为优先处理冲刷操作和零级到一级压缩操作。

方面11.根据方面9-10中任一项所述的系统，其中该排序引擎包括分片管理器，该分片管理器被配置为指引对数据的拆分，使得该第二LSM树中的每个LSM树都具有在预定范围内的层数。

方面12.根据方面9-11中任一项所述的系统，其中该排序引擎包括时间戳管理器，该时间戳管理器被配置为使得零级或一级应用针对相同键具有随时间严格增加的时间戳值。

方面13.根据方面1-12中任一项所述的系统，其中该键值系统还包括垃圾收集模块，该垃圾收集模块被配置为将LSM树的多层合并成LSM树的最后一层。

方面14.根据方面13所述的系统，其中该协作层被配置为协调跨该键值系统和该文件系统的垃圾收集操作。

方面15.根据方面14所述的系统，其中协调该垃圾收集操作包括该文件系统将区域使用信息暴露给该键值系统，以及该键值系统利用该区域使用信息来确定要被压缩或垃圾收集的文件。

方面16.根据方面14-15中任一项所述的系统，其中该垃圾收集模块被配置为基于与blob文件相关联的SST文件来确定blob文件内的垃圾数据的大小。

方面17.根据方面16所述的系统，其中该SST文件包含在SST文件的末尾处的冗余键。

方面18.根据权利要求1所述的系统，其中该文件系统包含超级块、日记、以及数据分量，该超级块组件包含通用文件系统元数据，并且该日记包含文件系统操作日志的检查点。

方面19.根据方面1-18中任一项所述的系统，其中该键值系统包括调度器，该调度器被配置为调度后台任务，使得由上层应用发出的每个输入/输出(I/O)请求具有一致的I/O放大。

方面20.根据方面1-19中任一项所述的系统，其中该系统被配置为处理即时文件和通用文件，其中该文件系统在预定义的范围中针对该通用文件分配存储空间。

本申请中公开的示例应在所有方面中被视为说明性的而非限制性的。本发明的范围由附加权利要求而不是前述描述表示；并且旨在将权利要求的含义和等效范围内的所有变化都包含在其中。

Claims (11)

1.一种存储系统，包括键值系统、文件系统和协作层，其中：

所述键值系统包括：

日志引擎，所述日志引擎被配置为执行多个日志文件的并行写入，

哈希引擎，所述哈希引擎被配置为通过将索引信息存储在紧凑索引中来处理点查询，以及

排序引擎，所述排序引擎被配置为通过使用分割的日志结构合并(LSM)树来处理范围扫描；

所述文件系统包括日志结构的仅附加写入模型；以及

所述协作层被配置为促进所述键值系统与所述文件系统之间的协作。

2.根据权利要求1所述的系统，其中所述文件系统被配置为基于所述键值系统更新数据但不更新与所述数据相关联的元数据。

3.根据权利要求1所述的系统，其中所述键值系统被配置为向所述文件系统提供数据以使所述数据在所述文件系统内持久。

4.根据权利要求1所述的系统，其中所述哈希引擎被配置为将所述紧凑索引保留在高速缓存存储器中。

5.根据权利要求4所述的系统，其中保留在所述高速缓存存储器中的所述索引信息是通过根据最近最少使用的策略省略所述索引信息中的一些索引信息而被选择的部分索引信息。

6.根据权利要求1所述的系统，其中所述日志引擎被配置为将多个用户操作合并成要与所述文件系统一起执行的单个I/O操作。

7.根据权利要求1所述的系统，其中所述排序引擎被配置为将来自第一LSM树的数据拆分成多个分片，所述多个分片中的每个分片包含具有比所述第一日志结构合并树更少层的第二LSM树。

8.根据权利要求7所述的系统，其中所述排序引擎包括作业调度器，所述作业调度器被配置为优先处理冲刷操作和零级到一级压缩操作。

9.根据权利要求8所述的系统，其中所述排序引擎包括分片管理器，所述分片管理器被配置为指引对数据的所述拆分，使得所述第二LSM树中的每个第二LSM树都具有在预定范围内的层数。

10.根据权利要求1所述的系统，其中所述键值系统还包括垃圾收集模块，所述垃圾收集模块被配置为将LSM树的多个层合并成所述LSM树的最后一层。

11.根据权利要求10所述的系统，其中所述垃圾收集模块被配置为基于与blob文件相关联的SST文件来确定所述blob文件内的垃圾数据的大小。