CN111183420A - 日志结构存储系统 - Google Patents

Abstract

本文公开了用于数据处理和存储的方法、系统和装置，包括编码在计算机存储设备上的计算机程序。方法之一包括：存储系统接收针对中心化账本系统的数据的处理请求。所述中心化账本系统的多种数据类型包括区块数据、交易数据和索引数据。所述存储系统确定所述数据属于所述中心化账本系统的多种数据类型中的一种数据类型，以及应用被指定用于处理所述一种数据类型的处理引擎类型。

Description

日志结构存储系统

技术领域

本文涉及日志结构存储系统。

背景技术

分布式账本系统(DLS)，也可称为共识网络和/或区块链网络，使得参与的实体能够安全且不可篡改地存储数据。在不引用任何特定用例的情况下，DLS通常被称为区块链网络。区块链网络类型的示例可以包括公共区块链网络、私有区块链网络和联盟区块链网络。为选定的实体群组提供联盟区块链网络，所述实体控制共识处理，并且所述联盟区块链网络包括访问控制层。

通常，DLS的每个节点(例如，区块链网络节点)存储或具有区块链网络数据的完整备份，使得每个节点可以是独立的，并且每个节点处的本地数据可以被信任以提供服务。然而，这种存储方案提出了苛刻的存储要求，并增加了每个节点的存储成本，尤其是随着DLS达到规模。因此，期望用于提高效率并降低存储系统成本的解决方案。

发明内容

本文描述了用于将数据存储在例如分布式账本系统(例如，区块链网络)和/或基于区块链的中心化账本系统(例如，通用可审计账本服务系统)中的日志结构存储系统的技术，所述分布式账本系统和/或基于区块链的中心化账本系统采用区块链的数据结构以利用存储在区块链上的数据的不可变性、可靠性以及可信性。

本文还提供了耦接到一个或多个处理器并且其上存储有指令的一个或多个非暂态计算机可读存储介质，当所述指令由所述一个或多个处理器执行时，所述指令将促使所述一个或多个处理器按照本文提供的方法的实施例执行操作。

本文还提供了用于实施本文提供的所述方法的系统。日志结构存储系统包括一个或多个处理器以及耦接到所述一个或多个处理器并且其上存储有指令的计算机可读存储介质，当所述指令由所述一个或多个处理器执行时，所述指令将促使所述一个或多个处理器按照本文提供的方法的实施例执行操作。

应了解，依据本文的方法可以包括本文描述的方面和特征的任意组合。也就是说，根据本文的方法不限于本文具体描述的方面和特征的组合，还包括所提供的方面和特征的任意组合。

以下在附图和描述中阐述了本文的一个或多个实施方式的细节。根据说明书和附图以及权利要求，本文的其他特征和优点将显现。

附图说明

图1是示出可用于执行本文实施例的环境的示例的图。

图2是示出根据本文实施例的架构的示例的图。

图3是示出根据本文实施例的基于区块链的日志结构存储系统的示例的图。

图4是示出根据本文实施例的分层存储系统的示例的图。

图5是示出根据本文实施例的用于执行日志结构存储系统的写入操作的处理的示例的流程图。

图6是示出根据本文实施例的用于生成与日志结构存储系统的写入操作有关的索引的处理的示例的流程图。

图7是示出根据本文实施例的用于执行日志结构存储系统的读取操作的处理的示例的流程图。

图8是示出根据本文实施例的用于改善日志结构存储系统的读取操作的处理的示例的流程图。

图9是示出根据本文实施例的用于管理存储在日志结构存储系统中的数据日志文件的处理的示例的流程图。

图10是示出根据本文实施例的用于在日志结构存储系统中执行数据迁移的处理的示例的流程图。

图11是示出根据本文实施例的用于在日志结构存储系统中执行数据流控制的处理的示例的流程图。

图12是示出可根据本文实施例执行的处理的示例的流程图。

图13是示出可根据本文实施例执行的处理的示例的流程图。

图14是示出可根据本文实施例执行的处理的示例的流程图。

图15是示出根据本文实施例的装置的模块的示例的图。

在各个附图中，相同的附图标记和名称表示相同的元件。

具体实施方式

本文描述了用于将数据存储在例如分布式账本系统(例如，区块链网络)和/或基于区块链的中心化账本系统(例如，通用可审计账本服务系统)中的日志结构存储系统的技术，所述分布式账本系统和/或基于区块链的中心化账本系统采用区块链的数据结构以利用存储在区块链上的数据的不可变性、可靠性以及可信性。在一些实施例中，分布式账本系统和基于区块链的中心化账本系统可以统称为基于区块链的账本系统。

在一些实施例中，基于区块链的中心化账本系统可以是基于中心化的账本系统，其可以提供具有时间关键性审计(具有不可否认性和防篡改性)的、密码学可验证的与状态无关的数据账本存储。在一些实施例中，基于区块链的中心化账本系统可以基于云平台提供账本服务，该云平台的特征在于具有可信度和中立性的中心化背书。基于区块链的中心化账本系统可以提供高可靠性和高性能的可审计流水账本服务，其组合了区块链系统的高可信度以及中心化系统的高性能和低延迟，以处理具有审计要求、可追溯性和跟踪的各种数据和日志。

本文中描述的技术产生若干技术效果。在一些实施例中，所描述的技术可以被应用在各种应用和场景中，以提供有效的、可信的、可扩展的、成本有效的和高性能的数据存储和管理。所描述的技术可以为包括例如交易数据、区块数据、状态数据和索引数据的区块链数据提供简单且定义良好的应用编程接口(API)集。

所描述的技术提供了一种日志结构存储系统，该系统不仅提供I/O服务，还考虑了成本和个性化需求，以提供诸如分层、数据压缩、共享存储、纠错编码和状态快照的功能，尤其是在存储在区块链系统中的数据量达到规模之后。日志结构存储系统可以提供诸如日志结构数据存储以及异步和/或并发处理等特征，以实现性能优化、高效处理、可信环境、通用性(例如，分布式账本系统和基于区块链的中心化账本系统均可用)和改进的存储方案。所描述的技术可以提供用于提供这样的功能和特征的总体框架或架构。

通常，在分布式账本系统(例如，区块链网络)中生成和/或存储的数据可以被称为区块链数据。区块链数据可以包括或分类为交易数据、区块数据、状态数据和索引数据。在一些实施例中，在基于区块链的中心化账本系统(例如，通用可审计账本服务系统)中生成和/或存储的数据可以包括或分类为交易数据、区块数据和索引数据。

在一些实施例中，可以以表示为<hash(value),value>的键值对(KVP)的形式来接收各种区块链数据。该值可以是表示区块、交易或区块链网络状态中一个或多个的实际数据。键可以是该值的哈希值。

在一些实施例中，对于区块数据，每个区块可以包括区块头和区块体。区块头可以包括特定区块的身份信息，并且区块体可以包括用该区块确认的交易。在一些实施例中，区块数据是区块链系统中的数据结构，并且通常具有以下一个或多个特性。例如，(1)在区块链网络中达成共识后，存储在区块链网络中的每个节点中的区块数据的内容在理论上是一致的。(2)区块号密集地增加。(3)连续区块之间存在哈希纠缠(hash entanglement)。(4)区块数据是仅追加(append-only)的。也就是说，一旦达成共识，历史区块数据将不会被修改。(5)区块数据的访问频率通常较低。区块数据占用的存储空间通常很大。

在一些实施例中，状态数据可以被组装(assemble)为全局共享状态(也称为世界状态)。世界状态可以包括账户地址和账户状态之间的映射。世界状态可以存储在诸如默克尔帕特丽夏树(Merkle Patricia tree，MPT)的数据结构中。在一些实施例中，例如，在智能合约场景中，可以基于默克尔树的内容来设计状态数据。它是一个增量式的内容寻址数据集。状态数据占用的存储空间通常很大。

在一些实施例中，状态数据可以进一步分类为当前状态和历史状态。在一些实施例中，当前状态是与最新区块相对应的状态数据，并且是在区块链网络上执行最新交易时的数据源。在一些实施例中，历史状态是存储从创世区块到最新区块的所有状态数据的内容寻址数据集。在一些实施例中，历史状态数据被存储在历史状态树中。历史状态树可以将状态信息存储为内容可寻址的表示为<hash(node value),node value>的键值对(KVP)。值或节点值可以是与区块链节点关联的账户的账户状态，而键可以是相应账户状态的哈希值。在一些实施例中，当前状态数据被存储在当前状态树中。在一些实施例中，可以基于一个或多个位置相关标识(ID)来对当前状态树进行位置寻址。例如，当前状态树可以将状态信息存储为表示为<node ID,node value>的KVP，其中可以根据相应的节点ID来寻址节点值。

在一些实施例中，交易数据可以包括与一系列操作的输入和输出有关的数据。在一些实施例中，交易数据可以包括与有价物(例如，资产、产品、服务、货币)的交换有关的数据。

在一些实施例中，索引数据可以指示数据(例如，交易数据、区块数据和状态数据)与存储该数据以用于寻址或检索该数据的数据日志文件之间的映射对应关系。在一些实施例中，索引数据可以指示对应数据存储在存储系统中的物理位置。在一些实施例中，索引数据可以包括以下中的一个或多个：指示从区块哈希值到区块号的对应关系的索引、指示从区块哈希值到存储位置的对应关系的索引、指示从交易哈希值到交易的对应关系的索引、或指示从收据哈希值到收据的对应关系的索引。在一些实施例中，索引数据不包括区块链数据的内容。

当越来越多的交易输入到区块链中时，区块链数据(例如状态数据和区块数据)的大小会越来越大。在DLS中，DLS的每个节点存储区块链的整个副本，即使某些旧区块数据或状态数据不经常被访问，也可能占用大量存储空间。

在一些实施例中，区块链数据由日志结构系统存储在数据文件中，并且数据文件基于时间被连续地追加和划分。在一些实施例中，可以不根据键的分类来重新排列数据(例如，数据不是按键值或其他度量排列的，使得热数据和冷数据不被混合在多个数据日志文件中)，从而大大降低了分层实现的技术挑战。

在一些实施例中，日志结构存储系统使用两种仅追加数据文件来存储区块链数据以提供数据持久性：数据日志文件和索引日志文件。例如，区块数据、交易数据、状态数据和附加自描述数据可以被存储在数据日志文件中，而指示交易数据、区块数据和状态数据的存储位置的索引数据(例如，数据日志文件的标识和偏移量)可以存储在索引日志文件中。

在区块链数据中，交易数据和区块数据可以是日志结构友好的，可以包括仅追加数据，使得可以通过直接将这些数据添加或追加到相应的数据日志文件中来将其写入数据日志文件中。在一些实施例中，交易数据和区块数据的写入不需要大量压合(compaction)。例如，它可能需要相对少量的交易重现，并且可能不需要区块回滚(rollback)。在一些实施例中，状态数据可以是日志结构友好的数据，使得历史状态数据可以在不需要压合的情况下增加。

在一些实施例中，日志结构存储系统可以支持多级数据分层，并支持多种存储设备，例如云盘、网络连接系统(NAS)和对象存储服务(OSS)(低频，存档)。例如，日志文件可以存储在基于云的存储系统、NAS或OSS设备、或自建的分布式存储系统中。

在一些实施例中，不同类型的日志文件可以具有不同的存储策略。例如，可以将相对较长时间未被访问的数据日志文件存储在廉价且速度相对较低的例如NAS/OSS的存储设备中，并可以使用压缩和纠错编码进行处理以用于存储。作为另一示例，索引日志文件可以存储在诸如云盘的高速存储设备上。

在一些实施例中，日志结构存储系统可以通过使用最近最少使用的(LRU)存储器缓存和磁盘缓存来执行数据分层，以优化低速存储设备的读取性能。

在一些实施例中，日志结构存储系统可以提供管理多级的存储设备池的分层池管理器。在一些实施例中，每个池支持集群中的多个磁盘或存储设备。分层池管理器可以管理池的空间、压力和运行状况。在一些实施例中，日志结构存储系统可以提供迁移任务管理器，该迁移任务管理器管理不同级的存储设备之间的数据的双向迁移任务；管理结果回调、统计信息、迁移任务的生命周期等。在一些实施例中，日志结构存储系统可以提供支持可插拔策略的迁移调度器、管理数据迁移策略并提供数据创建/查询/更新/删除接口。

所公开的日志结构存储系统采用了合并树(LSM-Tree)架构的思想。在一些实施例中，日志结构存储系统可以包括多个日志结构存储实例(或流)，其中每个日志结构存储实例负责存储和管理分布式账本系统(例如，区块链系统)或基于区块链的中心化账本系统的数据。在一些实施例中，日志结构存储系统可以将随机写入操作转换为有序追加操作，以减轻由于大量随机写入操作引起的频繁的“脏”页刷新而导致的写入放大问题。在一些实施例中，日志结构存储系统可以延迟高性能场景中的写入刷新操作并减少同步操作的次数，以提高整个系统的效率和性能。

为了提供本文实施例的进一步的背景，并且如上所述，分布式账本系统(DLS)，也可以被称为共识网络(例如，由点对点节点组成)和区块链网络，使得参与实体能够安全地并且不可篡改地进行交易并存储数据。尽管术语区块链通常与特定网络和/或用例相关联，但是在不参考任何特定用例的情况下，本文中使用的区块链通常是指DLS。

区块链是以交易不可篡改的方式存储交易的数据结构。因此，区块链上记录的交易是可靠且可信的。区块链包括一个或多个区块。链中的每个区块通过包含链中其紧前的前一区块的加密哈希值(cryptographic hash)链接到该前一区块。每个区块还包括时间戳、自身的加密哈希值以及一个或多个交易。已经被区块链网络中的节点验证的交易经哈希处理并编入默克尔(Merkle)树中。Merkle树是一种数据结构，对树的叶节点处的数据进行哈希处理，并且在树的每个分支中的所有哈希值在该分支的根处级联。沿着树持续该处理一直到整个树的根，在整个树的根处存储了代表树中所有数据的哈希值。通过确定哈希值是否与该树的结构一致而可快速验证该哈希值是否为存储在该树中的交易的哈希值。

在一些实施例中，例如，在作为计算节点网络的区块链网络中，可以以分布式或去中心化或至少部分去中心化的方式来实现区块链以用于存储交易。每个计算节点(又称为区块链网络节点)可以通过广播交易、验证交易和确认交易有效性等来管理、更新和维护一个或多个区块链。如上所述，区块链网络可作为公有区块链网络、私有区块链网络或联盟区块链网络被提供。在本文中参考联盟区块链网络进一步详细描述本文实施例。然而，可以预期，本文实施例可以在任何适当类型的区块链网络中实现。

通常，联盟区块链网络在参与的实体中是私有的。在联盟区块链网络中，共识处理由授权的节点集控制，该节点集可以被称为共识节点，一个或多个共识节点由相应实体(例如，金融机构、保险公司)操作。例如，由10个实体(例如，金融机构、保险公司)组成的联盟可以操作联盟区块链网络，每个实体操作联盟区块链网络中的至少一个节点。

在一些示例中，在联盟区块链网络内，提供全局区块链作为跨所有节点复制的区块链。也就是说，对于全局区块链，所有的共识节点处于完全共识状态。为了达成共识(例如，同意将区块添加到区块链)，在联盟区块链网络内实施共识协议。例如，联盟区块链网络可以实施实用拜占庭容错(PBFT)共识，下面将进一步详细描述。

在一些实施例中，中心化账本系统还可以采用区块链的数据结构，以利用存储在区块链上的数据的不可变性、可靠性和可信性。在一些实施例中，例如中心化账本系统可以被称为基于区块链的中心化账本系统或通用可审计账本服务系统。在一些实施例中，基于区块链的中心化账本系统可以包括中央可信机构，该中央可信机构提供存储在区块链数据结构的区块中的透明、不可变且可密码验证的数据。所存储的数据可以是日志格式，例如不仅包括交易日志，还包括其他交易数据和区块数据。由于中央信任机构的存在，基于区块链的中心化账本系统无需执行共识处理即可建立信任。在一些实施例中，与典型基于区块链的分布式或去中心化账本系统相比，基于区块链的中心化账本系统可以更高效。在一些实施例中，基于区块链的中心化账本系统可以提供具有增强的信任、效率和存储性能的基于云的存储服务。

图1是示出了可用于执行本文实施例的环境100的示例的图。在一些示例中，环境100使得实体能够参与联盟区块链网络102。环境100包括计算设备106、108和网络110。在一些示例中，网络110包括局域网(LAN)、广域网(WAN)、因特网或其组合，并且连接网站、用户设备(例如，计算设备)和后端系统。在一些示例中，可以通过有线和/或无线通信链路来访问网络110。在一些示例中，网络110使得能够与联盟区块链网络102通信或在联盟区块链网络102内部通信成为可能。通常，网络110表示一个或多个通信网络。在一些情况下，计算设备106、108可以是云计算系统(未示出)的节点，或者每个计算设备106、108可以是单独的云计算系统，其包括通过网络互连并且用作分布式处理系统的多个计算机。

在所描绘的示例中，计算设备106、108可以各自包括能够作为节点参与至联盟区块链网络102中的任何适当的计算系统。计算设备的示例包括(但不限于)服务器、台式计算机、笔记本电脑、平板电脑和智能手机。在一些示例中，计算设备106、108承载用于与联盟区块链网络102交互的一个或多个由计算机实施的服务。例如，计算设备106可以承载第一实体(例如，用户A)的由计算机实施的、例如交易管理系统的服务，例如，第一实体使用该交易管理系统管理其与一个或多个其他实体(例如，其他用户)的交易。计算设备108可以承载第二实体(例如，用户B)的由计算机实施的、例如交易管理系统的服务，例如，第二实体使用该交易管理系统管理其与一个或多个其他实体(例如，其他用户)的交易。在图1的示例中，联盟区块链网络102被表示为节点的点对点网络(Peer-to-Peer network)，并且计算设备106、108分别提供参与联盟区块链网络102的第一实体和第二实体的节点。

图2是示出根据本文实施例的架构200的图。示例性概念架构200包括分别对应于参与者A、参与者B和参与者C的参与者系统202、204、206。每个参与者(例如，用户、企业)参与到作为点对点网络提供的区块链网络212中，该点对点网络包括多个节点214，至少一些节点将信息不可篡改地记录在区块链216中。如图中进一步详述，尽管在区块链网络212中示意性地描述了单个区块链216，但是在区块链网络212上提供并维护了区块链216的多个副本。

在所描绘的示例中，每个参与者系统202、204、206分别由参与者A、参与者B和参与者C提供或代表参与者A、参与者B和参与者C，并且在区块链网络中作为各自的节点214发挥作用。如这里所使用的，节点通常是指连接到区块链网络212且使相应的参与者能够参与到区块链网络中的个体系统(例如，计算机、服务器)。在图2的示例中，参与者对应于每个节点214。然而，可以预期，一个参与者可以操作区块链网络212内的多个节点214，和/或多个参与者可以共享一个节点214。在一些示例中，参与者系统202、204、206使用协议(例如，超文本传输协议安全(HTTPS))和/或使用远程过程调用(RPC)与区块链网络212通信或通过区块链网络212进行通信。

节点214可以在区块链网络212内具有不同的参与程度。例如，一些节点214可以参与共识处理(例如，作为将区块添加到区块链216的监视节点)，而其他节点214不参与此共识处理。作为另一示例，一些节点214存储区块链216的完整的副本，而其他节点214仅存储区块链216的一部分的副本。例如，数据访问特权可以限制相应的参与者在其相应系统内存储的区块链数据。在图2的示例中，参与者系统202、204和206存储区块链216的相应的完整副本216'、216”和216”'。

区块链(例如，图2的区块链216)由一系列区块组成，每个区块存储数据。数据的示例包括表示两个或更多参与者之间的交易的交易数据。尽管本文通过非限制性示例使用了“交易”，但是可以预期，任何适当的数据可以存储在区块链中(例如，文档、图像、视频、音频)。交易的示例可以包括(但不限于)有价物(例如，资产、产品、服务、货币)的交换。交易数据不可篡改地存储在区块链中。也就是说，交易数据不能改变。

在将交易数据存储在区块中之前，对交易数据进行哈希处理。哈希处理是将交易数据(作为字符串数据提供)转换为固定长度哈希值(也作为字符串数据提供)的过程。不可能对哈希值进行去哈希处理(un-hash)以获取交易数据。哈希处理可确保即使交易数据轻微改变也会导致完全不同的哈希值。此外，如上所述，哈希值具有固定长度。也就是说，无论交易数据的大小如何，哈希值的长度都是固定的。哈希处理包括通过哈希函数处理交易数据以生成哈希值。哈希函数的示例包括(但不限于)输出256位哈希值的安全哈希算法(SHA)-256。

多个交易的交易数据被哈希处理并存储在区块中。例如，提供两个交易的哈希值，并对它们本身进行哈希处理以提供另一个哈希值。重复此过程，直到针对所有要存储在区块中的交易提供单个哈希值为止。该哈希值被称为Merkle根哈希值，并存储在区块的头中。任何交易中的更改都会导致其哈希值发生变化，并最终导致Merkle根哈希值发生变化。

通过共识协议将区块添加到区块链。区块链网络中的多个节点参与共识协议，并竞相将区块添加到区块链中。这种节点称为共识节点。上面介绍的PBFT用作共识协议的非限制性示例。共识节点执行共识协议以将交易添加到区块链，并更新区块链网络的整体状态。

更详细地，共识节点生成区块头，对区块中的所有交易进行哈希处理，并将所得的哈希值成对地组合以生成进一步的哈希值，直到为区块中的所有交易提供单个哈希值(Merkle根哈希值)。将此哈希值添加到区块头中。共识节点还确定区块链中最新区块(即，添加到区块链中的最后一个区块)的哈希值。共识节点还向区块头添加随机数(nonce)和时间戳。

通常，PBFT提供容忍拜占庭故障(例如，故障节点、恶意节点)的实用拜占庭状态机复制。这通过在PBFT中假设将发生故障(例如，假设存在独立节点故障和/或由共识节点发送的操纵消息)而实现。在PBFT中，以包括主共识节点和备共识节点的顺序提供共识节点。主共识节点被周期性地改变。通过由区块链网络内的所有共识节点对区块链网络的全局状态达成一致，将交易添加到区块链中。在该处理中，消息在共识节点之间传输，并且每个共识节点证明消息是从指定的对等节点(peer node)接收的，并验证在传输期间消息未被篡改。

在PBFT中，共识协议是在所有共识节点以相同的状态开始的情况下分多个阶段提供的。首先，客户端向主共识节点发送调用服务操作(例如，在区块链网络内执行交易)的请求。响应于接收到请求，主共识节点将请求组播到备共识节点。备共识节点执行请求，并且各自向客户端发送回复。客户端等待直到接收到阈值数量的回复。在一些示例中，客户端等待直到接收到f+1个回复，其中f是区块链网络内可以容忍的错误共识节点的最大数量。最终结果是，足够数量的共识节点就将记录添加到区块链的顺序达成一致，并且该记录或被接受或被拒绝。

在一些区块链网络中，用密码学来维护交易的隐私。例如，如果两个节点想要保持交易隐私，以使得区块链网络中的其他节点不能看出交易的细节，则这两个节点可以对交易数据进行加密处理。加密处理的示例包括但不限于对称加密和非对称加密。对称加密是指使用单个密钥既进行加密(从明文生成密文)又进行解密(从密文生成明文)的加密过程。在对称加密中，同一密钥可用于多个节点，因此每个节点都可以对交易数据进行加密/解密。

非对称加密使用密钥对，每个密钥对包括私钥和公钥，私钥仅对于相应节点是已知的，而公钥对于区块链网络中的任何或所有其他节点是已知的。节点可以使用另一个节点的公钥来加密数据，并且该加密的数据可以使用其他节点的私钥被解密。例如，再次参考图2，参与者A可以使用参与者B的公钥来加密数据，并将加密数据发送给参与者B。参与者B可以使用其私钥来解密该加密数据(密文)并提取原始数据(明文)。使用节点的公钥加密的消息只能使用该节点的私钥解密。

非对称加密用于提供数字签名，这使得交易中的参与者能够确认交易中的其他参与者以及交易的有效性。例如，节点可以对消息进行数字签名，而另一个节点可以根据参与者A的该数字签名来确认该消息是由该节点发送的。数字签名也可以用于确保消息在传输过程中不被篡改。例如，再次参考图2，参与者A将向参与者B发送消息。参与者A生成该消息的哈希值，然后使用其私钥加密该哈希值以提供作为加密哈希值的数字签名。参与者A将该数字签名附加到该消息上，并将该具有数字签名的消息发送给参与者B。参与者B使用参与者A的公钥解密该数字签名，并提取哈希值。参与者B对该消息进行哈希处理并比较哈希值。如果哈希值相同，参与者B可以确认该消息确实来自参与者A，且未被篡改。

图3是示出根据本文实施例的日志结构存储系统的示例的图。日志结构存储系统300可以存储将数据存储在一个或多个区块链上的分布式账本系统(例如，区块链网络)和/或基于区块链的中心化账本系统(例如，通用可审计账本服务系统)(统称为基于区块链的账本系统)的数据。

在一些实施例中，日志结构存储系统300可以由区块链网络的每个共识节点或基于区块链的中心化账本系统的中央节点来实现。在一些实施例中，日志结构存储系统300可以连接到由基于区块链的账本系统的客户端节点构建的分布式存储系统340。如图所示，日志结构存储系统300包括前端输入/输出(I/O)子系统310、多层存储子系统320和后端数据管理子系统330。在一些实施例中，前端I/O子系统310可以执行写入操作以将数据写入到存储在多层存储子系统320中的数据文件(例如，数据日志文件和索引日志文件)中，并执行读取操作，以访问来自存储在多层存储子系统320中的数据文件的数据。在一些实施例中，后端数据管理子系统330可以根据不同的需求对数据文件中的数据进行处理、重组和管理，以提高整个系统的效率和性能。

前端I/O子系统310可以包括任何合适的计算元件(例如，处理器、存储器315等中的一个或多个)以执行本文所述的方法。在一些实施例中，前端I/O子系统310可以对多种数据元素执行包括各种读写操作(例如，插入、更新、删除、查询等)的前端I/O操作。

在一些实施例中，前端I/O子系统310处理的所有数据元素(例如，交易数据、区块数据和状态数据)可以以日志文件格式被存储，无论该日志文件是根据写入操作生成的还是根据后端数据管理子系统330的例如存储分层、压合、数据压缩、纠删编码等的操作生成的文件。

在一些实施例中，前端I/O子系统310处理的数据可以被存储在以下两种日志文件中：(1)存储诸如区块链数据(例如，交易数据、区块数据、状态数据)和自描述元数据的数据日志文件(例如，数据日志文件390、362、364、366、372、374和376)；以及(2)存储指示数据的物理位置的索引信息(例如，数据日志文件的标识符和偏移量)的索引日志文件(例如，索引日志文件380)。在一些实施例中，数据日志文件不存储索引信息，而索引信息由单独的索引日志文件维护。

在一些实施例中，前端I/O子系统310可以被配置为执行写入操作以将区块链数据写入到数据日志文件390中。在一些实施例中，区块链数据可以包括由区块链网络或分布式账本系统生成的区块数据、交易数据或状态数据。在一些实施例中，区块链数据可以包括由基于区块链的中心化账本系统生成的区块数据和交易数据。在一些实施例中，写入数据日志文件390的数据可以包括描述数据区块的元数据，诸如交易哈希值和序列值、区块哈希值和区块号、快照版本号、循环冗余校验(CRC)码、加密信息等。在一些实施例中，数据日志文件390可以是仅追加文件。

在一些实施例中，前端I/O子系统310可以被配置为生成指示相应数据存储在日志结构存储系统300中(例如，多层存储子系统320中的数据日志文件中)的物理位置的索引。在一些实施例中，索引可以被存储在索引日志文件380中。在一些实施例中，数据日志文件和索引日志文件可以被存储在多层存储子系统320中。在一些实施例中，索引可以被存储在索引日志文件380中，该索引日志文件380被存储在多层存储子系统320的存储设备中访问速度最高的一个存储设备中。

在一些实施例中，可以基于数据写入或追加操作来持续更新数据日志文件。在一些实施例中，数据日志文件可具有可配置的最大长度，例如在512MB和2GB之间。在一些实施例中，如果确定数据日志文件已经达到最大长度或大小，则可以将数据日志文件密封或设置为只读，并且可以为新写入操作分配新数据日志文件。

在一些实施例中，前端I/O子系统310可执行写入操作，包括对存储在日志结构存储系统300中的数据的修改。在一些实施例中，前端I/O子系统310通过以日志格式将数据添加或追加到数据日志文件中，来处理对数据的修改，从而不覆盖原始数据。在一些实施例中，数据日志文件可以形成可用于崩溃恢复的预写日志(WAL)层。

在一些实施例中，前端I/O子系统310将索引信息存储在存储器315中，该索引信息指示数据(例如，交易数据、区块数据和状态数据)与存储该数据的数据日志文件之间的映射对应关系，以寻址或检索数据。在一些实施例中，可以使用日志结构合并(LSM)方法来组织存储器中的索引数据。在一些实施例中，新写入的数据的索引可以被存储在存储器315中，并在存储器使用率(memory usage)超过预定阈值时被刷新(flush)到索引日志文件380中。这样，旧数据的索引可以被存储在磁盘存储设备或硬盘驱动器存储设备中的索引日志文件380中，从而释放出空间以在存储器315中缓存新的热点数据的索引。

在一些实施例中，索引数据可以包括以下中的一个或多个：指示从区块哈希值到区块号的对应关系的索引、指示从区块哈希值到存储位置的对应关系的索引、指示从交易哈希值到交易的对应关系的索引、或指示从收据哈希值到收据的对应关系的索引。在一些实施例中，用于基于区块链的中心化账本系统的索引数据可以包括指示从序列到交易存储位置的对应关系的索引和/或指示从时序到交易哈希值的对应关系的索引。

在一些实施例中，前端I/O子系统310可以包括存储在存储器315中的多个内存索引映射。在一些实施例中，内存索引映射可以被认为是用于维护前端I/O子系统310的存储器中的索引数据的任何合适的组件、单元、模块或数据结构(例如，表或结构)。内存索引映射可以是前端I/O子系统310的关键组件，其确定前端I/O子系统310和整个日志结构存储系统300的可扩展性和性能。在一些实施例中，因为区块链数据的时间敏感性较强，并且最近写入的交易数据和区块数据被再次访问的机会相对较高，所以日志结构存储系统300可以将热数据的索引存储在存储器315中的索引映射中，以改善整个日志结构存储系统300的性能。

在一些实施例中，内存索引映射可以维护指示从交易哈希值到序列值的映射的索引和/或指示从区块哈希值和区块号到数据的物理位置的映射的索引。在一些实施例中，前端I/O子系统310将存储器315中的索引映射的检查点定期持久化到索引日志文件中。例如，前端I/O子系统310可以周期性地或在某个时间点捕获存储器315中的索引数据的快照，并将快照存储在多层存储子系统320中的索引日志文件380中。这可以创建一个时间点，在日志结构存储系统300意外关闭或崩溃之后的恢复过程中，日志结构存储系统300可以在该时间点应用包含在索引日志文件380中的更改。在一些实施例中，前端I/O子系统310可以通过查询内存索引映射并确定所请求数据的当前位置来读取数据(例如，交易数据、区块数据和状态数据)。

在一些实施例中，可以在创建索引日志文件时将内存索引映射的完整检查点写入索引日志文件。在一些实施例中，可以通过批量处理写入操作的索引来更新索引日志文件。在一些实施例中，批大小可以是动态可配置的，例如数千个交易写入操作或几兆字节(MB)的写入操作。在一些实施例中，当已经针对特定批次数的写入操作更新了索引日志文件时，可以将索引日志文件密封或设置为只读，并且可以创建新索引日志文件以写入新数据。

在一些实施例中，为了从异常崩溃中恢复，前端I/O子系统310可以将索引日志文件(例如，索引日志文件380)加载到存储器315中，并且扫描数据日志文件390的页底部以确保数据日志文件390和索引日志文件380的一致性。在一些实施例中，索引日志文件可能落后于数据日志文件几个批次，因此恢复时间可能占用有限的I/O资源和时间。

在一些实施例中，可以将新写入的交易数据和区块数据的索引添加到索引映射和索引日志文件中，但是除了在重放攻击和区块回滚场景中之外，可以不修改现有交易数据和区块数据的索引。在一些实施例中，为了实现读写操作的高并发性，可以将内存索引映射分为只读基本索引映射316和读写增量索引映射312。在一些实施例中，基本索引映射316可以存储冷数据的索引，而增量索引映射312可以存储新写入的数据的索引。在一些实施例中，哈希值索引可以存储在哈希值表中，而序列索引可以存储在B树(B-tree)中。

在一些实施例中，在前端I/O子系统310的写入操作期间，可以首先将数据的索引信息更新到增量索引映射312。在读取操作期间，前端I/O子系统310可以首先在增量索引映射312中搜索所请求的数据。如果在增量索引映射312中未找到所请求的数据，则前端I/O子系统310可以随后搜索基本索引映射316。

在一些实施例中，前端I/O子系统310可以定期将索引数据从存储器315刷到索引日志文件380。在一些实施例中，索引刷新的基本过程可以包括以下操作：(1)组合增量索引映射312和基本索引映射316；(2)对基本索引映射316进行持久化处理(例如，将基本索引映射存储到索引日志文件中)；(3)从存储器315释放基本索引映射316的部分或全部；(4)通过读取请求的索引数据将索引数据交换到存储器315。

在一些实施例中，前端I/O子系统310可以将存储器315中的增量索引映射312转换为不可变索引映射314，然后将它们刷到索引日志文件380，并创建新增量索引映射以接收根据新请求生成的索引。这样，可以减少增量索引映射的存储占用，以改善日志结构存储系统300的性能。

在一些实施例中，为了减少对前端I/O的影响，存储器中的索引映射可以在后端异步地合并。在一些实施例中，可以通过以下两个条件中的至少一个来触发合并处理：(1)增量索引映射的大小超过预定阈值；(2)新快照被创建。在一些实施例中，前端I/O子系统310可以生成合并索引映射以包括要被刷到索引日志文件380中的不可变索引映射314。在一些实施例中，前端I/O子系统310可以将合并索引映射与当前基本索引映射316组合以生成新基本索引映射。

在一些实施例中，在操作期间，前端I/O子系统310可以与多个基本索引映射和索引日志文件一起运行。在一些实施例中，当在某些情况下需要压合时，可以通过将所有基本索引映射和增量索引映射组合成一个基本索引映射来定期执行次要压合(minorcompaction)和主要压合(major compaction)。主要压合主要合并和管理索引，这可用于例如快照、垃圾回收加载和索引文件管理的场景。

在一些实施例中，可以通过合并基本索引映射和增量索引映射并生成新基本索引映射，并且将其存储到新索引日志文件中来执行主要压合。在一些实施例中，可以通过组合若干索引日志文件并生成新索引日志文件来执行次要压合，这可以减少索引日志文件的数量。在一些实施例中，如果当前索引日志文件的大小达到预定阈值，则可以将当前索引日志文件设置为密封或不可变状态并关闭，并且可以为新索引数据创建新索引日志文件。

在一些实施例中，在读取操作期间，如果在内存索引映射中的搜索失败，则可能需要两个或多个I/O操作，这可能给日志结构存储系统300带来负担。在一些实施例中，前端I/O子系统310可以提供具有存储器缓存313和区块缓存317的多级缓存机制(例如，使用闪存介质(例如，SSD云盘))。

在一些情况下，日志结构存储系统300可以接收较大的读取请求，使得日志结构存储系统300需要访问多个数据日志文件从而为客户端获取完整的请求数据。然而，访问多个数据日志文件可能会导致不小的开销。在一些实施例中，后端数据管理子系统330可以执行压合操作以级联逻辑上相邻的数据区块从而减少碎片。在一些实施例中，压合操作可能具有开销，并且可以在数据碎片严重时执行。

在一些实施例中，多层存储子系统320可以包括多层存储设备。存储设备可以包括存储介质以及相应的软件和/或硬件接口。在一些实施例中，多层存储设备可以包括具有不同性能特性(例如访问速度)的多个存储设备。例如，多层存储设备可以包括云盘、网络附加存储(NAS)设备和对象存储服务(OSS)设备。在一些实施例中，多层存储设备是按根据一个或多个性能特性的分层结构分层的。在一些实施例中，一个或多个性能特性可以包括访问速度、访问带宽或访问延迟。例如，多层存储设备可以包括具有第一性能特性(例如，访问速度)的第一层存储设备和具有低于第一性能特性的第二性能特性(例如，相对于第一层存储设备而言相对较低的访问速度)的第二层存储设备等。如图3所示，多层存储子系统320的示例可以包括第一层存储设备350、第二层存储设备360和第三层存储设备370，该第一层存储设备350包括云盘或基于云的存储设备(例如，固态驱动器(SSD)云盘、嵌入式SSD(ESSD)云盘)，该第二层存储设备360包括NAS设备，该第三层存储设备370包括OSS设备。

在一些实施例中，多层存储设备可以存储不同类型的数据。在一些实施例中，可以基于例如数据被生成或接收的时间或数据被访问的频率将数据分类为热数据355、暖数据365和冷数据375。例如，最新交易的数据可以是热数据；昨天的交易数据可以是暖数据，而一周前进行的历史交易数据可以是冷数据。又例如，区块链中最近生成的10个区块中的数据可以是热数据；最近生成的

个区块中的数据可以是暖数据，其他较早的区块中的数据可以是冷数据。然而，在一些实施例中，区块链的创世区块可以被视为热数据，因为其频繁被访问。

在一些实施例中，多层存储子系统320可以将热数据355、暖数据365和冷数据375分别存储到多层存储设备中。例如，第一层存储设备350可以存储热数据355；第二层存储设备360可以存储暖数据365；第三层存储设备370可以存储冷数据375。在一些实施例中，一层存储设备可以例如基于存储空间和成本来存储一种或多种数据。例如，第一层存储设备350可以存储热数据355和一些暖数据365，而第二层存储设备360可以存储其余的暖数据365和一些冷数据375。

在一些实施例中，存储设备的每一层可以存储数据日志文件，该数据日志文件包括由基于区块链的账本系统(例如，分布式账本系统和/或基于区块链的中心化账本系统)生成的区块链数据。例如，第一层存储设备350可以存储包括由基于区块链的账本网络生成的第一区块链数据的第一数据日志文件390，并且第二层存储设备360可以存储包括由基于区块链的账本系统生成的第二区块链数据的第二数据日志文件362，等等。

在一些实施例中，相比于存储在存储设备的相对较高层中的数据日志文件中的区块链数据，存储在存储设备的相对较低层中的数据日志文件中的区块链数据可以更早地被写入。例如，相比于存储在第一层存储设备350上的第一数据日志文件390中的第一区块链数据，存储在第二层存储设备360上的第二数据日志文件362中的第二区块链数据可以更早地被写入。

在一些实施例中，第一层存储设备350可以进一步存储一个或多个索引日志文件380，该索引日志文件380包括索引数据，该索引数据用于指示多层存储设备350、360和370存储的数据日志文件390、362、364、366、372、374和376中数据的物理存储位置。例如，如图3所示，第一层存储设备350可以存储索引日志文件380，该索引日志文件380包括的索引数据指示第一层存储设备350存储的数据日志文件390中区块链数据的物理存储位置、第二层存储设备360存储的数据日志文件362、364和366中区块链数据的物理存储位置、以及第三层存储设备370存储的数据日志文件372、374和376中区块链数据的物理存储位置。

在一些实施例中，一个或多个索引日志文件可以被存储在第二层存储设备360和/或第三层存储设备370。

在一些实施例中，存储在多层存储子系统320上的索引日志文件和数据日志文件是仅追加日志文件。在一些实施例中，存储在数据日志文件中的区块链数据可以包括区块数据、交易数据和历史状态数据。

在一些实施例中，较高层的存储设备可以存储包括从较低层的存储设备迁移来的区块链数据的数据日志文件。例如，第一层存储设备可以存储包括这样的区块链数据的数据日志文件：该区块链数据比第二层存储设备的数据日志文件中的区块链数据和从第二层存储设备迁移来的区块链数据更频繁地被访问。

在一些实施例中，存储系统300可以进一步包括分布式存储系统340，该分布式存储系统340包括诸如非易失性存储器快速(non-volatile memory express，NVME)、SSD、硬盘驱动器(HDD)和叠片式磁记录(SMR)的存储介质。在一些实施例中，分布式存储系统340可以由基于区块链的账本系统的客户端节点生成或扩展，以具有更好的可用性、分区容忍度、灵活性和成本。例如，分布式存储系统340可以通过添加更多服务器或存储节点并由此线性地增加容量和性能来允许扩展。它可以使用价格便宜的标准服务器、驱动器和网络。在一些实施例中，分布式存储系统340可以提高标准服务器的利用率，因此导致更少的功耗、更好的冷却效率、更好的空间利用率、更少的维护成本等。

前端I/O子系统310可以对区块链数据执行写入操作并生成索引日志文件380以及存储在多层存储子系统320上的数据日志文件390、362、364、366、372、374和376。随着时间的流逝，存储在多层存储子系统320上的数据可能会累积和聚集，并且可能会降低日志结构存储系统300的性能。后端数据管理子系统330可以根据不同的需求来处理和重组数据，例如，从而提高日志结构存储系统300的性能并降低其成本。在一些实施例中，后端数据管理子系统330可以独立于前端I/O子系统310来管理数据。例如，后端数据管理子系统330可以在后端对密封索引日志文件或只读索引日志文件以及数据日志文件执行诸如分层、压缩、纠删编码、状态快照、压合和验证的数据管理操作。在一些实施例中，后端数据管理子系统330可以实施流控制以最小化对前端I/O子系统310的前端I/O处理的影响。

在一些实施例中，后端数据管理子系统330的任务可以包括对存储的数据进行重写和与该重写的数据相对应的索引的替换。在一些实施例中，后端数据管理子系统330可以在后端上自动确定是否需要重写数据日志文件。在一些实施例中，后端数据管理子系统330可以基于诸如分层、压缩和纠删编码的配置来确定重写的放置。在一些实施例中，后端数据管理子系统330可以从一个或多个源数据日志文件读取数据，并将数据重写到目标数据日志文件。在一些实施例中，当重写完成时，后端数据管理子系统330可以将目标数据日志文件设置为密封或不可变状态，并生成对应的目标索引日志文件。在一些实施例中，目标索引日志文件可以包括可被安全删除的数据日志文件的列表，以及目标索引日志文件所引用的数据日志文件。在一些实施例中，后端数据管理子系统330不回收仍然可以由前端I/O子系统310的实时实例使用的旧数据日志文件。

在一些实施例中，后端数据管理子系统330可以处理根据前端I/O子系统310的I/O操作生成的只读索引日志文件和对应的只读数据日志文件。在一些实施例中，后端数据管理子系统330可以分析索引日志文件并确定例如数据的热、暖或冷的水平、数据量、垃圾率和/或碎片量。在一些实施例中，基于垃圾率、磁盘使用率和/或系统请求，后端数据管理子系统330可以执行以下一项或多项任务：

(1)数据分层。例如，当存储介质使用率接近安全上限时，可能需要将数据迁移到下一层或更低层存储设备的存储介质中。

(2)数据压缩。例如，当存储介质使用率接近安全上限时，可能需要压缩数据文件。

(3)纠删编码(EC)。例如，当存储介质使用率接近安全上限时，可能需要通过纠删编码来释放存储空间。

(4)状态快照。例如，当存在状态修改(例如，在数据删除后回收存储空间)时，可以对区块链状态执行快照。

(5)数据压合。例如，如果数据日志文件中的垃圾或碎片增长到一定大小从而明显影响日志结构存储系统300的性能，则可能需要清理垃圾或碎片。

(6)验证。例如，可以定期或按需在存储介质上对数据执行循环冗余校验(CRC)。

数据分层：

在一些实施例中，对于需要相对较高性能的写入请求，可以将写入请求写入到多个不同存储设备中的更快的存储设备(例如，SSD云盘、ESSD云盘、NVME等)。对于需要较低性能以换取较低开销的写入请求，可以将写入请求写入存储设备介质(例如，NAS等)。在一些实施例中，后端数据管理子系统330可以使用一组混合的慢速和快速存储设备来进行数据分层和数据迁移。例如，区块链网络生成的新区块数据的访问频率可能比旧区块数据相对更高，并且新区块数据可以存储在更快的存储设备中。在一些实施例中，可以将访问频率最高的新区块数据的一部分存储在存储器缓存(例如，存储器缓存313)和/或高速的磁盘缓存(例如，区块缓存317)中。

在一些实施例中，分布式账本系统和基于区块链的中心化账本系统均具有强的冷热特性，这使其适于分层存储。例如，诸如多层存储子系统320的分层存储系统可用于包括以下一项或多项特征：(1)具有较小存储空间的快速存储介质和具有较大存储空间的慢速存储介质的组合提高了空间使用率而不牺牲性能；(2)支持冷迁移(例如，冷数据自动从快速介质迁移到慢速介质)和预热(例如，数据从慢速介质迁移到快速介质)；(3)可扩展性，以在规模增加时减少维护成本；(4)支持基于用户需求的灵活配置；(5)支持多媒体存储池；或(6)快速迁移到新存储介质。

图4是示出根据本文实施例的分层存储系统400的示例的图。在一些实施例中，分层存储系统可以例如基于存储设备的访问速度来包括多个级或多个层的存储设备。例如，参考图4，用于分层的多个存储设备可以分为四个层或级，包括热、暖、冷和用于基于日志文件的热和冷特性来存储日志文件的存档。例如，分层存储系统400的存储设备可以分为用于分别存储热日志文件410、暖日志文件412、冷日志文件414和存档文件416的四个层或级。

在一些实施例中，存储设备的每个层或级可以被视为虚拟池，并且每个池可以支持多个物理或虚拟文件系统(也称为存储设备)。例如，分层存储系统400可以包括第一级池402、第二级池404、第三级池406以及第四级池408。在一些实施例中，池中支持的文件系统可以包括以下短期文件系统中的一个或多个：云盘(例如，安装在ext4/xfs文件系统上的虚拟机(VM)的区块设备)；NAS(例如，具有posix接口的nfs文件系统)；OSS低频(适用于虚拟文件系统、软件开发工具包(SDK)系统、代表性状态传输(REST)接口等格式)；和OSS存档(适用于虚拟文件系统、SDK系统、REST接口等格式)。

例如，如图4所示，第一级池402可以包括云存储系统(例如，多层存储子系统320)中存储热日志文件410的ESSD和SSD设备。第二级池404可以包括云存储系统中存储暖日志文件412的NAS设备和云盘。第三级池406可包括云存储系统中存储冷日志文件414的OSS低频设备。第四级池408可以包括云存储系统中存储存档文件416的OSS存档设备。

在一些实施例中，文件系统还可以包括长期文件系统，诸如自建分布式系统(例如，由基于区块链的账本系统的客户端节点构建的分布式存储系统340)。例如，第一级池402还可以包括由区块链网络的客户端节点生成的分布式存储系统的存储热日志文件410的NVME设备(例如，作为分布式存储系统340的一部分)。第二级池404还可包括分布式存储系统的存储热日志文件412的SSD设备。第三级池406还可包括分布式存储系统的存储冷日志文件414的HDD设备。第四级池408还可以包括分布式存储系统的存储存档文件416的SMR设备。在一些实施例中，可以为所有文件系统提供与整个日志结构存储系统300的统一接口。

在一些实施例中，分层存储系统400可以包括一个或多个子系统或组件，诸如(1)分层池管理器418、(2)迁移任务管理器420、(3)用于管理数据分层的迁移调度器422、或(4)服务质量(QoS)管理器423。在一些实施例中，每个管理器可以包括任何合适的计算元件(例如，处理器、存储器等中的一个或多个)以执行本文所述的功能。例如，这些管理器可以管理不同性能和成本的多个存储设备之间的数据流，例如，通过利用不同存储设备之间的性能和成本差异来提高整个日志结构存储系统的性能和效率。

在一些实施例中，分层池管理器418可以被配置为管理存储设备的每个层。在一些实施例中，分层池管理器418可以执行以下功能中的一项或多项：管理多层存储设备的存储空间和压力；提供指定层的文件创建、删除和统计分析功能(例如，根据系统请求选择存储设备以创建数据日志文件)；维护层文件映射表，该表指示数据文件的对应关系，它们在存储设备的相应层中的存储位置以及数据文件的热度或冷度等。

在一些实施例中，迁移任务管理器420可以管理不同存储设备之间的双向数据迁移任务、管理任务生命周期、回调结果、执行统计分析、执行迁移任务等等。

在一些实施例中，迁移调度器422可以支持可插拔迁移策略、管理数据迁移策略并提供数据创建/查询/更新/删除接口。在一些实施例中，迁移调度器422可以对迁移任务执行调度管理，以实现对迁移任务的有效流控制。在一些实施例中，迁移调度器422可以在后端对数据日志文件进行打分或以其他方式分配相应得分，并且根据得分排名和迁移策略来生成数据日志文件的迁移任务。在一些实施例中，可以根据评分公式对数据日志文件进行打分，该评分公式考虑了存储设备的层、访问频率、原始数据创建时间、迁移成本和/或其他因素。在一些实施例中，迁移调度器422可以与分层存储系统400的其他子系统或组件一起工作以快速验证不同的迁移策略。

在一些实施例中，可以根据预定的数据迁移策略自动执行数据迁移。例如，可以根据预定的评分方案对高速存储设备中的不同数据进行打分，并基于不同数据的相应得分在后端将其迁移到低速设备中，以释放缓存空间。在一些实施例中，在某些应用中，低速设备中的一些数据可以被确定为热数据。可以将热数据首先保存在磁盘缓存中，如果数据日志文件的得分满足要求，则可以将其迁移到高速设备。在一些实施例中，在数据文件从源存储设备迁移到目标存储设备之后，原始数据可以在源存储设备中被删除或可以不被删除。例如，如果目标存储设备是顶层存储设备，则不需要删除磁盘缓存中的数据日志文件，而是可以自动将其替换为其他数据。

在一些实施例中，QoS管理器423可以被配置为管理分层存储系统400的数据流或其他性能指标以改善QoS。例如，在一些情况下，对高速存储设备突发的I/O写入可能导致较高层中的高速存储设备被大量占用或使用。在一些实施例中，QoS管理器423可以以高使用率(例如85％或另一阈值)来控制进入存储池的数据流，以避免存储池被过快填满。流控制可以防止分层存储系统400的性能下降，并可以释放存储空间以进行数据迁移。为了提高数据迁移的效率，同时减少对前端I/O操作(例如，通过前端I/O子系统310)的影响，可以在后端(例如，通过后端数据管理子系统330)执行流控制数据迁移。在一些实施例中，迁移速度可以与存储设备的使用率正相关。例如，如果存储设备的使用率较低，则可以减少流控制，以避免对前端I/O产生过多影响。如果存储设备的使用率较高，则可以取消流控制以加速数据迁移。

在一些情况下，高速存储设备的使用率可能已满，并且前端I/O操作可能受到严重限制。在一些实施例中，可以将数据直接写入较低层存储设备，而无需将数据从较高层存储设备迁移到较低层存储设备。例如，如果图3中的第一层存储设备350已满或达到使用率阈值，则可以将数据直接写入第二层存储设备360。在一些实施例中，像区块链区块数据这样的大(例如，具有大于阈值的大小)的数据可以被直接写入低层存储设备中的数据日志文件中，以节省由于数据迁移引起的成本。

在一些实施例中，为了进一步减少由于数据迁移引起的网络资源、硬盘吞吐量、存储空间和其他资源的消耗，并且为了减小对前端I/O操作的影响，当数据被迁移到低层存储设备时可以通过默认设置执行压缩和纠删编码。

与高速存储设备相比，低速或存档存储设备的性能相对较差。通常，大部分数据最终会写入存储设备的低速层。根据数据的热特性和冷特性在高速存储设备上缓存热数据并将其迁移到高速存储设备有助于提高读取性能。在一些实施例中，可以实现以下两种或更多种缓存以提高读取性能：(1)存储器缓存(例如，最近最少使用(LRU)缓存424)；(2)快速磁盘缓存(例如，高速存储设备上的最不常用(LFU)磁盘缓存426)。在一些实施例中，可以例如以数百MB到几GB来动态地配置存储器缓存424的总大小。类似地，可以例如以1GB到数十GB动态地配置快速磁盘缓存的总大小。

在一些实施例中，可以将已经频繁被访问的一些历史数据，例如区块链的创世区块，放置在快速存储设备的LFU缓存中。

数据压缩：

对于分布式账本系统和基于区块链的中心化账本系统，对数据区块的压缩可以有效降低成本并提高日志结构存储系统的性能。日志结构由于其固有的特性和特征，可以便于日志结构存储系统中的压缩。

在一些实施例中，写入前端上的数据可以不被压缩，并且可以例如通过将数据追加在数据日志文件中而直接写入到高速存储设备(例如，SSD云盘)。在一些实施例中，当数据日志文件达到一定大小时，可以将其设置为不可变的。在一些实施例中，后端数据管理子系统330可以在后端上压缩原始数据日志文件，并将原始数据日志文件替换为压缩后的数据文件。这样，由于压缩操作是在后端执行的，因此可以减少或最小化压缩操作对前端I/O操作的影响。

通常，在确定数据日志文件的压缩大小或容量时，可能需要考虑压缩和读取放大的有效性并达到平衡。例如，在一些情况下，如果数据日志文件的压缩大小或容量太小(例如，小于4KB)，则由于压缩而节省的空间可能会受到限制，并且压缩性能可能不是最佳的。另一方面，如果数据日志文件的压缩大小或容量太大，则读取放大也可能变得更大(例如，要读取交易条目，则包括交易条目的整个压缩数据日志文件需要首先解压缩)。在一些实施例中，数据日志文件的压缩大小可以被设置为16KB-128KB。

在一些实施例中，压缩数据日志文件可以包括多个记录，其中每个记录可以包括压缩头和压缩数据体。在一些实施例中，压缩数据的元数据可以包括版本信息、压缩算法、长度和CRC等。

对于加密的数据，加密本身的随机性会使数据压缩的性能不理想。因此，在一些实施例中，对于需要加密的数据(例如在可信执行环境(TEE)中)，可以在加密之前或解密之后对数据进行压缩。

在一些实施例中，对于压缩日志文件，基本索引映射可以对压缩日志文件的物理数据大小进行编码、修改并记录相应的索引，并且记录日志文件的文件ID、日志文件的偏移量和日志文件的压缩数据大小。

纠删编码

在一些实施例中，后端数据管理子系统330可以对数据日志文件中的数据执行纠删编码。例如，后端数据管理子系统330可以在后端使用纠删编码将进入的数据写入数据日志文件。

对于分布式账本系统，为了在区块链网络的共识节点之间实现拜占庭容错日志文件层，可以执行纠删编码以减少存储在分布式账本系统的每个共识节点上的冷数据量。例如，对于4个共识节点，可以在执行纠删编码之前写入4个数据副本。在执行纠删编码(例如，8+3纠删编码方案)之后，这4个节点可以存储少于2个数据副本(例如，1.375个数据副本)。

对于基于区块链的中心化账本系统，中心化结构不需要由于多个节点的备份而导致的数据冗余。在一些实施例中，可以在基于区块链的中心化账本系统中的分层存储系统中执行纠删编码，以减少数据冗余，例如，在顶层存储设备或分布式存储系统中的数据备份中。

数据压合

在一些实施例中，交易数据、区块数据和历史状态数据是仅追加的，并且不能被删除或覆盖，因此不对这些数据执行压合。在一些实施例中，可以使用数据压合来处理当前状态数据。数据压合通常包括垃圾收集和数据碎片整理。

在一些实施例中，后端数据管理子系统330可以根据数据日志文件各自的垃圾率对它们进行排序，并且以从高垃圾率到低垃圾率的降序排列它们。在一些实施例中，后端数据管理子系统330可以重写具有相对较高的垃圾率的数据日志文件。例如，后端数据管理子系统330可以重写垃圾率超过预定阈值的数据日志文件。在一些实施例中，数据日志文件创建得越早，数据日志文件中的数据就越有可能被覆盖，这意味着较早的数据日志文件的垃圾率可能高于新数据日志文件的垃圾率。

在一些实施例中，后端数据管理子系统330可以实现垃圾回收机制，该垃圾回收机制可以为每次重写设置最大数据量。在一些实施例中，例如可以由前端I/O子系统310的多个实时实例流并行地执行多个回收程序，以提高垃圾收集的整体效率。

在一些实施例中，前端I/O子系统310的实时实例流可以获得垃圾率，并将获得的垃圾率报告给后端数据管理子系统330，后端数据管理子系统330可以确定适当或最佳的流来重写数据。

碎片整理通常是以下处理：定位存储在存储设备上的不连续数据碎片，然后重新排列这些碎片并将其还原为更少的碎片或整个文件。碎片整理可以减少数据访问时间，并可以更有效地使用存储。在一些实施例中，后端数据管理子系统330可以周期性地、不时地或根据请求执行碎片整理。

在一些实施例中，对于某些类型的数据，例如世界状态数据或状态对象数据，这些数据的键具有一定水平的哈希特性。如果键具有前缀(例如，不同的状态对象具有不同的前缀)，则通过将数据放入同一文件或相邻文件中来对此类数据执行压合可以提高读取性能。

状态快照

状态快照可以捕获系统(例如，分布式账本系统)在特定时间点的状态。在一些实施例中，后端数据管理子系统330可以执行状态快照操作以生成和存储日志结构存储系统300的状态数据。在一些实施例中，状态数据可以包括历史状态数据和当前状态数据。历史状态数据可以包括分布式账本系统的历史状态以用于回溯，而当前状态数据可以包括分布式账本系统的最新状态数据。随着时间的流逝，历史状态数据的大小可能会变大，并占用大量存储空间。在一些实施例中，为了改善历史数据回溯和存储空间使用率，后端数据管理子系统330可以对当前状态数据执行快照操作。

日志结构存储系统300的日志结构设计可以有助于快照操作并提高日志结构存储系统300的性能和效率。在一些实施例中，可以基于写时重定向(ROW)方法来执行快照操作，该方法为与快照相对应的数据集提供了高效索引。

在一些实施例中，日志结构存储系统300的快照功能可以支持闪存创建(例如，秒级)和回滚，这可能对前端I/O操作仅具有有限或最小的影响。在一些实施例中，后端数据管理子系统330可以创建数据日志文件和索引日志文件的硬链接以避免数据复制。

在一些实施例中，当来自写入请求的数据被存储到数据日志文件时，可以生成记录以包括指示快照版本的快照标识(ID)。在一些实施例中，后端数据管理子系统330可以响应于接收到状态快照请求而执行以下操作中的一个或多个：

(1)写入与快照创建相对应的操作日志(op log)；

(2)将快照版本增加1；

(3)将所有新快照写入请求写入新内存增量索引映射中(重定向)；

(4)与旧快照关联的所有写入请求完成后，将索引刷到当前索引日志文件，对所有索引文件执行压合，将索引文件合并为单个索引日志文件，并将合并的单个索引日志文件设置为密封状态(数据日志文件在压合处理期间也被密封)；

(5)基于新快照版本创建新索引文件；以及

(6)创建与快照相对应的目录，并为与快照相关联的数据日志文件和索引日志文件创建到该目录的硬链接。

在一些实施例中，后端数据管理子系统330可以在后端上执行压合以恢复被删除的快照。

在一些实施例中，如果需要快照上传，则可以维护快照的数据结构(例如具有1位的位图表示数据范围)。例如，在创建快照时创建的索引日志文件中，可以将与快照相对应的位图设置为全0。在接收到写入请求后，位图可以更新为1，指示该快照版本中的数据被修改。

在一些实施例中，快照版本号可以对应于索引日志文件，该快照版本号指示与索引日志文件中的所有索引相对应的写入请求。

验证

在一些实施例中，后端数据管理子系统330可以对记录在日志文件中的数据执行CRC校验。在一些实施例中，后端数据管理子系统330可以周期性地、不时地或根据请求执行CRC校验。

在一些实施例中，当将由后端数据管理子系统330生成的索引文件导入到前端I/O子系统310的实时实例流中时，实时实例流的内存索引映射可以比后端数据管理子系统330生成的索引文件更新，并且可以包括新数据区块和旧数据区块的位置信息。在一些实施例中，实时实例流可以遍历内存基本映射，替换相应的索引条目，然后生成没有引用旧数据日志文件的新索引日志文件。然后，实时实例流可以安全地删除旧数据日志文件和索引日志文件。

在一些实施例中，在日志结构存储框架(例如，日志结构存储系统300)中，流可以被用于作为处理I/O请求的处理引擎、组件、单元或模块来操作。每个流可以通过不同的配置适应不同的业务场景。在一些实施例中，流可以由与软件耦接的一个或多个处理器来实现以执行诸如管理数据日志文件、索引日志文件、清单文件、请求队列等的操作。在一些实施例中，实时流可以指代处理前端I/O子系统310的前端I/O操作的实时实例。在一些实施例中，可以存在由后端数据管理子系统330在后端管理由实时流写入的数据的对应dredger流。

在一些实施例中，流可以包括管理接口，该管理接口允许针对不同类型的数据的例如快照、统计和故障恢复的不同操作的不同配置。例如，用于处理区块数据、状态数据和交易数据的流可以根据区块数据、状态数据和交易数据的各自的特性采用不同的配置。例如，可以将与区块相对应的流配置为具有分层和/或压缩功能，但不具有压合、快照或表格功能。

在一些实施例中，可以通过对应自定义的或以其他方式配置的流来处理不同类型的数据。例如，可以通过与区块相对应的流来处理写入区块的请求。

在一些实施例中，可以将多个流组合成束(bundle)以提供适合于分布式账本系统和/或基于区块链的中心化账本系统的特定应用的灵活的实施方式。所描述的技术可以支持分布式账本系统(例如，区块链网络)和/或基于区块链的中心化账本系统中的服务。在一些实施例中，两种系统可以具有根据两种日志结构存储系统300的需要自定义的或以其他方式配置的不同的流。例如，分布式账本系统可以具有四种数据：交易共识日志、区块、状态和索引。因此，可以将四种流配置为分别处理四种数据。基于区块链的中心化账本系统可以具有三种数据：交易、区块和索引，而没有状态(或复杂合约状态)。因此，可以将三种流配置为分别处理三种数据。

在一些实施例中，每种流可以被分别配置为处理不同类型的数据。例如，区块、交易共识日志、索引不需要快照。因此，用于处理区块、交易共识日志和索引的流不需要配置快照功能。另一方面，状态数据流可以配置有快照功能。作为另一示例，索引数据相对较小，但是它需要良好的性能，并且不需要分层分级存储。长期操作和大量区块数据可能需要分层分级存储、共享存储和纠删编码。

在一些实施例中，分布式账本系统和基于区块链的中心化账本系统可以对流具有不同的要求，以执行诸如分层、压缩、纠删编码、状态快照、压合和数据验证等操作。

表1提供了不同场景下的配置示例。如图所示，“两者”表示可以针对分布式账本系统和基于区块链的中心化账本系统都执行对特定类型数据的操作。“DLS”表示可以只针对分布式账本系统执行对特定类型数据的操作。“都不”表示可以针对分布式账本系统和基于区块链的中心化账本系统都不执行对特定类型数据的操作。

表格1

例如，如表1所示，可以针对分布式账本系统和基于区块链的中心化账本系统执行对交易数据和/或区块数据的分层操作。可以只针对分布式账本系统执行对当前状态数据和/或历史状态的分层操作。可以针对分布式账本系统和基于区块链的中心化账本系统都不执行对交易数据的快照操作。

在一些实施例中，日志结构存储系统采用基于每个线程一个循环一个队列和并发的多线程全异步机制，从而提供了高效的异步模式和便捷的并发同步编程模式。在一些实施例中，不同的流可以并行处理不同类型的数据。例如，为区块数据配置的流可以将区块数据写入被分配以存储区块数据的数据日志文件中，而为交易数据配置的流可以从包括交易数据的数据日志文件中读取特定请求交易数据。

图5是示出根据本文实施例的用于执行日志结构存储系统的写入操作的处理500的流程图。在一些实施例中，处理500的一些或全部操作可以是由前端I/O子系统(例如，图3的前端I/O子系统310)执行的写入程序的示例。为了方便，处理500将被描述为由图3的前端I/O子系统310系统执行。然而，处理500可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统(例如，图3的日志结构存储系统300)可以执行处理500。

在502，在数据存储系统(例如，日志结构存储系统300)中维护数据日志文件(例如，数据日志文件390、362、364、366、372、374或376)。在一些实施例中，数据日志文件可以存储包括交易数据、区块数据、状态数据和自描述元数据的数据。例如，数据日志文件可以存储由区块链网络生成的区块链数据，包括区块数据、交易数据和/或状态数据。在一些实施例中，数据日志文件中的元数据可以包括描述数据区块的元数据，诸如交易哈希值和序列值、区块哈希值和区块号、快照版本号、循环冗余校验(CRC)码、加密信息等。在一些实施例中，一个数据日志文件存储单一类型的区块链数据，因此多种区块链数据不混合在单个数据文件中。例如，数据存储系统可以维护用于交易数据的数据日志文件、用于区块数据的数据日志文件和用于状态数据的数据日志文件中的一个或多个。在一些实施例中，数据日志文件可以是仅追加文件。在一些实施例中，数据日志文件不存储索引信息。在一些实施例中，数据日志文件可以被存储在多层存储子系统(例如，多层存储子系统320)中。

在504，数据存储系统的前端I/O子系统(例如，前端I/O子系统310)接收用于将数据写入数据存储系统的写入请求。在一些实施例中，前端I/O子系统310可以处理写入操作，包括对存储在日志结构存储系统300上的数据的修改。在一些实施例中，对数据的修改由前端I/O子系统310处理，从而不覆盖原始数据。取而代之的，可以通过以日志形式向数据日志文件添加或追加数据来处理修改。

在506，前端I/O子系统310将数据追加到数据日志文件。在一些实施例中，可以基于数据写入或追加操作来持续更新数据日志文件。在一些实施例中，数据日志文件可以具有在512MB和2GB之间的可配置的最大长度，或者取决于存储系统的需求或应用的其他大小。

在508，前端I/O子系统310确定是否满足用于生成新数据日志文件的条件。在一些实施例中，前端I/O子系统310可以确定数据日志文件是否已经达到预定的最大长度或大小。如果确定数据日志文件已经达到预定的最大长度或大小，则前端I/O子系统310可以确定满足了用于生成新数据日志文件的条件。如果确定满足了用于生成新数据日志文件的条件，则处理进行到步骤510。如果确定没有满足用于生成新数据日志文件的条件，则处理返回到步骤504。

在510，如果确定满足了用于生成新数据日志文件的条件，则前端I/O子系统310密封数据日志文件。在一些实施例中，如果确定满足了用于生成新数据日志文件的条件(例如，数据日志文件已达到最大长度或大小)，则前端I/O子系统310可以将数据日志文件设置为密封的、不可变的或只读状态。

在512，前端I/O子系统310生成新数据日志文件。在一些实施例中，新数据日志文件也可以是仅追加的，并存储在多层存储子系统320中。

在一些实施例中，前端I/O子系统310可以确定在写入请求中被请求写入的数据的类型(例如，交易数据、区块数据、状态数据)。响应于该确定，前端I/O子系统310将数据追加到与数据的类型相对应的数据日志文件中。在一些实施例中，前端I/O子系统310可以使用与数据类型相对应的相应处理引擎来执行处理500中的一些或全部。

例如，响应于确定数据是交易数据，前端I/O子系统310使用针对处理交易数据指定的处理引擎，以将该数据追加到用于交易数据的数据日志文件中。在一些实施例中，响应于确定数据是区块数据，前端I/O子系统310使用针对处理区块数据指定的处理引擎，以将该数据追加到用于区块数据的数据日志文件中。在一些实施例中，响应于确定数据是状态数据，前端I/O子系统310使用针对处理状态数据指定的处理引擎，以将该数据追加到用于状态数据的数据日志文件中。

图6是示出根据本文实施例的用于生成与日志结构存储系统的写入操作有关的索引的处理600的流程图。在一些实施例中，处理600的一些或全部操作可以是由前端I/O子系统(例如，图3的前端I/O子系统310)执行的写入程序的示例。为了方便，处理600将被描述为由图3的前端I/O子系统310执行。然而，处理600可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统(例如，图3的日志结构存储系统300)可以执行处理600。

在602，成功将数据写入存储系统(例如，日志结构存储系统300)。在一些实施例中，数据存储系统的前端I/O子系统(例如，前端I/O子系统310)可以将数据区块写入存储在数据存储系统的多层存储子系统(例如，多层存储子系统320)的数据日志文件中。

在604，前端I/O子系统310生成指示数据在日志结构存储系统300中的物理存储位置的索引。在一些实施例中，索引数据可以包括：指示从区块哈希值到区块号的对应关系的索引、指示从区块哈希值到存储位置的对应关系的索引、指示从交易哈希值到交易的对应关系的索引、和指示从收据哈希值到收据的对应关系的索引。在一些实施例中，用于基于区块链的中心化账本系统的索引数据可以包括指示从序列到交易存储位置的对应关系的索引或指示从时序到交易哈希值的对应关系的索引。

在606，前端I/O子系统将索引保存到前端I/O子系统310的存储器(例如，存储器315)中的增量索引映射(例如，增量索引映射312)中。在一些实施例中，前端I/O子系统310可以包括存储在存储器315中的多个内存索引映射。在一些实施例中，内存索引映射可以分为只读基本索引映射316和读写增量索引映射312。在一些实施例中，基本索引映射316可以存储冷数据(例如，旧数据和/或较不频繁被访问的数据)的索引，而增量索引映射312可以存储新写入的数据的索引。

在608，前端I/O子系统310确定是否发生触发事件。触发事件可以包括导致密封当前增量索引映射并生成新增量索引映射的一个或多个事件。触发事件可包括，例如，当前增量索引映射的大小达到阈值、存储器315的存储使用率达到阈值、或指定的时间到来(例如，日志结构存储系统300可以定期密封增量索引映射)。如果确定触发事件发生，则处理进行到步骤610。如果确定触发事件未发生，则处理返回到步骤602。

在610，如果确定触发事件发生，则前端I/O子系统310将增量索引映射312设置为不可变的。在一些实施例中，前端I/O子系统可以将存储器315中的增量索引映射312设置为不可变索引映射314，将它们刷到索引日志文件(例如，索引日志文件380)，并创建新增量索引映射312以接收根据新写入请求生成的索引。

在612，在存储系统300中维护索引日志文件380。在一些实施例中，可以将新写入的交易数据和区块数据的索引添加到索引映射312和316以及索引日志文件390，但是可以不修改现有交易数据和区块数据的索引。在一些实施例中，索引日志文件390可以与数据日志文件一起存储在多层存储子系统320中。

在614，前端I/O子系统310例如将增量索引映射312刷到索引日志文件380中，以释放增量索引映射312所使用的内存。在一些实施例中，前端I/O子系统310可以创建新增量索引映射312以接收根据新请求生成的索引。在一些实施例中，前端I/O子系统310可以组合增量索引映射312和基本索引映射316，并生成新基本索引映射316，并将生成的基本索引映射316刷到索引日志文件380。

在一些实施例中，在616，前端I/O子系统310将热数据的索引保存在存储器缓存(例如，存储器缓存313)中。例如，如果将特定数据确定为具有频繁被访问可能性的热数据，则可以将数据的索引保存到存储器缓存中以提高读取速度。

在618，前端I/O子系统310确定是否满足用于生成新的索引日志文件380的条件。在一些实施例中，用于生成新索引日志文件的条件可以包括索引日志文件380的最大长度或大小。在一些实施例中，用于生成新索引日志文件380的条件可以包括由前端I/O子系统执行的写入操作的批次数。例如，在一些实施例中，可以通过批量处理写入操作的索引来更新索引日志文件380。在一些实施例中，当已经针对特定批次数的写入操作更新了索引日志文件380时，可以将索引日志文件380密封或设置为只读，并且可以创建新的索引日志文件380以写入新数据。如果确定满足了用于生成新的索引日志文件380的条件，则处理进行到步骤620。

在620，如果确定满足了用于生成新的索引日志文件380的条件，则前端I/O子系统310密封索引日志文件。例如，当索引日志文件380已经达到最大长度或大小，或者已经针对特定批次数的写入操作进行了更新时，可以将索引日志文件380密封或设置为只读。

在622，前端I/O子系统310在密封旧索引日志文件380之后，生成新的索引日志文件380，以存储后续的索引数据。

图7是示出了根据本文实施例的用于执行日志结构存储系统的读取操作的处理700的流程图。在一些实施例中，处理700的一些或全部操作可以是由前端I/O子系统(例如，图3的前端I/O子系统310)执行的读取程序的示例。为了方便，处理700将被描述为由前端I/O子系统310执行。然而，处理700可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统(例如，图3的日志结构存储系统300)可以执行处理700。

在702处，存储系统(例如，日志结构存储系统300)的前端I/O子系统(例如，前端I/O子系统310)接收用于从存储系统读取数据的读取请求。

在704，前端I/O子系统310在前端I/O子系统310的存储器(例如，存储器315)中的增量索引映射(例如，增量索引映射312)中搜索与数据相对应的索引。在一些实施例中，与数据相对应的索引可以包括数据的物理位置信息。在一些实施例中，前端I/O子系统310的存储器315可以存储包括只读基本索引映射316和读写增量索引映射312的多个内存索引映射。

在706，前端I/O子系统310确定是否在增量索引映射312中找到了与数据相对应的索引。如果在增量索引映射312中找到了与数据相对应的索引，则处理进行到步骤708，其中，前端I/O子系统310可以基于由索引指示的物理位置来定位数据。如果在增量索引映射312中未找到与数据相对应的索引，则处理进行到步骤710。

在710，如果确定在增量索引映射312中未找到与数据相对应的索引，则前端I/O子系统310在存储器315中的基本索引映射316中搜索与数据相对应的索引。

在712，前端I/O子系统310确定是否在基本索引映射316中找到了与数据相对应的索引。如果确定在基本索引映射316中找到了与数据相对应的索引，则处理进行到步骤714，其中，前端I/O子系统310可以基于由索引指示的物理位置信息来定位数据。如果在基本索引映射316中未找到与数据相对应的索引，则处理进行到步骤716。

在716，如果确定在基本索引映射316中未找到与数据相对应的索引，则前端I/O子系统310在磁盘存储设备中的索引日志文件(例如，索引日志文件380)中搜索与数据相对应的索引。例如，前端I/O子系统310可以在存储在存储系统300的多层存储子系统(例如，多层存储子系统320)中的索引日志文件380中搜索与数据相对应的索引。

在一些实施例中，前端I/O子系统310可以确定在读取请求中被请求读取的数据的类型(例如，交易数据、区块数据、状态数据)。响应于该确定，前端I/O子系统310可以使用与数据类型相对应的相应处理引擎来执行处理700中的一些或全部。

图8是示出根据本文实施例的用于改善日志结构存储系统的读取操作的处理800的流程图。在一些实施例中，处理800的一些或全部操作可以是由日志结构存储系统(例如，图3的日志结构存储系统300)执行的I/O操作的示例。为了方便，处理800将被描述为由日志结构存储系统300执行。然而，处理800可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统可以执行处理800。

在802，存储系统(例如，日志结构存储系统300或分层存储系统400)维护多层存储设备(例如，多层存储子系统320的存储设备350、360和370)和一层或多层缓存(例如，存储器缓存313和区块缓存317)。在一些实施例中，多层存储设备是按基于一个或多个性能特性(例如，访问速度、访问带宽或访问延迟)的分层结构分层的。例如，多层存储设备可以包括具有不同访问速度并存储具有不同特性的数据的多个存储设备。例如，第一层存储设备可以存储比第二层存储设备中存储的区块链数据更频繁被访问的区块链数据。

在804，例如前端I/O子系统(例如，前端I/O子系统310)或后端数据管理系统(例如，存储系统300的后端数据管理子系统330)确定存储在较低层存储设备(例如，存储设备350、360和370)中的数据日志文件(例如，数据日志文件362、364、366、372、374、376、390)中的数据对象是活跃数据对象。在一些实施例中，数据对象可以包括交易数据、区块数据和状态数据。在一些实施例中，例如，如果数据对象最近已经被访问一定次数(例如，在预定时间窗内被访问一定次数)或者如果数据对象已经被识别为具有特定优先级，则可以基于一个或多个活跃性或热度策略将数据对象确定为活跃数据对象。

在806，将数据对象写入缓存(例如，存储器缓存313和区块缓存317)。例如，前端I/O子系统310可以将数据对象写入高速存储介质的存储器缓存313或磁盘区块缓存317中。

在808，生成指示数据对象在缓存中的物理存储位置的索引。在一些实施例中，可以使用LSM方法来组织存储器315中的索引数据。

在810，可以将索引保存到存储器315中的增量索引映射(例如，增量索引映射312)。在一些实施例中，存储器315可以维护多个内存索引映射，包括只读基本索引映射316和读写增量索引映射312。在一些实施例中，增量索引映射312可以被配置为存储比存储在基本索引映射316中的索引更频繁被访问和/或更新的数据的索引。

在812，前端I/O子系统310接收针对数据对象的读取请求。

在814，前端I/O子系统310在存储器315中的增量索引映射312中搜索与数据对象相对应的索引。在一些实施例中，前端I/O子系统310可以首先搜索增量索引映射312。如果在增量索引映射312中未找到索引，则前端I/O子系统310可以随后在基本索引映射316中搜索与数据相对应的索引。

在816，前端I/O子系统310从缓存返回数据对象，与需要从下一缓存级、主存储器或多层存储子系统320的存储设备的较低层获取所请求的数据对象的情况相比，这可以提供对所请求的数据对象的更快访问。例如，如果前端I/O子系统310成功地识别出与增量索引映射312或基本索引映射316中的数据相对应的索引，则前端I/O子系统310可以使用该索引来识别数据在缓存中的物理位置，并从缓存中检索数据。

在一些实施例中，前端I/O子系统310可以确定在读取请求中被请求读取的数据的类型(例如，交易数据、区块数据、状态数据)。响应于该确定，前端I/O子系统310可以使用与数据类型相对应的相应处理引擎来执行处理800中的一些或全部。

图9是示出根据本文实施例的用于管理存储在日志结构存储系统中的数据日志文件的处理900的流程图。在一些实施例中，处理900的一些或全部操作可以是由日志结构存储系统的后端数据管理系统(例如，图3的日志结构存储系统300的后端数据管理子系统330)执行的重写放置程序的示例。为了方便，处理900将被描述为由后端数据管理子系统330执行。然而，处理900可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统(例如，图3的日志结构存储系统300)可以执行处理900。

在902，后端数据管理系统(例如，后端数据管理子系统330)根据索引日志文件(例如，索引日志文件380)确定存储在存储设备(例如，存储设备350、360和370)中的数据日志文件(例如，数据日志文件390、362、364、366、372、374和376)的信息。在一些实施例中，存储设备中的数据日志文件的信息可以包括数据日志文件的活跃性(例如，访问频率)、大小、垃圾率或碎片水平中的一个或多个。

在904，后端数据管理系统330确定存储设备的信息。在一些实施例中，存储设备的信息可以包括存储设备的使用率、垃圾率、碎片水平或输入/输出(I/O)请求中的一个或多个。

在906，后端数据管理系统330确定数据日志文件是否需要重写放置。在一些实施例中，后端数据管理子系统330可以基于存储在存储设备中的数据日志文件的信息和/或存储设备的信息来确定重写放置。在一些实施例中，重写放置可以包括分层、压缩、纠删编码、状态快照、压合或验证中的至少一个。如果确定数据日志文件需要重写放置，则处理进行到步骤908。如果确定数据日志文件不需要重写放置，则处理返回到步骤902。

在908，后端数据管理系统330从源位置读取数据日志文件，并且如果确定数据日志文件需要重写放置，则将数据日志文件重写到目标位置。

在910，后端数据管理系统330将数据日志文件密封在目标位置中。例如，后端数据管理系统330可以在重写放置完成之后将数据日志文件设置为密封状态或只读。

在912，后端数据管理系统330生成与目标位置中的数据日志文件相对应的目标索引日志文件。在一些实施例中，目标索引日志文件可以包括可被安全删除的数据日志文件的列表，和/或目标索引日志文件所引用的数据日志文件的列表。

在914，后端数据管理系统330密封目标索引日志文件。例如，后端数据管理系统330可以将目标索引日志文件设置为不可变的或只读的。

在916，将目标索引日志文件导入到存储器中的可读索引映射中。例如，可以将目标索引日志文件导入到增量索引映射或基本索引映射，使得可以寻址或读取目标位置中的数据日志文件。

图10是示出根据本文实施例的用于在日志结构存储系统中执行数据迁移的处理1000的流程图。在一些实施例中，处理1000的一些或全部操作可以是由日志结构存储系统的后端数据管理系统(例如，图3的日志结构存储系统300的后端数据管理子系统330)执行的分层/迁移程序的示例。为了方便，处理1000将被描述为由后端数据管理子系统330执行。然而，处理1000可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统(例如，图3的日志结构存储系统300)可以执行处理1000。

在1002，后端数据管理系统(例如，后端数据管理子系统330)识别数据日志文件(例如，数据日志文件390、362、364、366、372、374和376)的一个或多个特性和存储设备(例如，存储设备350、360和370)的一个或多个特性。在一些实施例中，数据日志文件的一个或多个特性可以包括数据日志文件的数据类型(例如，区块数据、状态数据和交易数据)、创建时间、数据大小、活跃性、垃圾率或碎片水平等。在一些实施例中，存储设备的一个或多个特性可以包括存储设备的访问速度、访问带宽、访问延迟、使用率、垃圾率、碎片水平或输入/输出(I/O)请求。

在1004，后端数据管理系统330基于所述特性确定数据日志文件的迁移度量。在一些实施例中，后端数据管理系统330可以将得分分配给数据日志文件，并根据得分排名和预定的迁移策略来生成迁移任务。在一些实施例中，可以根据评分公式对数据日志文件进行打分或分配得分，该评分公式考虑了媒介水平、访问频率、原始数据创建时间和迁移成本等。

在1006，后端数据管理系统330确定是否迁移数据日志文件。例如，可以根据预定的评分方案对数据日志文件进行评分。如果数据日志文件的得分超过预定阈值，则后端数据管理系统330可以确定需要迁移数据日志文件。如果确定需要迁移数据日志文件，则处理进行到步骤1008。如果确定不需要迁移数据日志文件，则处理返回到步骤1002。

在1008，如果确定需要迁移数据日志文件，则后端数据管理系统330将数据日志文件从源位置迁移到目标存储设备。在一些实施例中，可以根据预定的评分方案对高速存储设备中的数据日志文件进行打分，并基于得分将其迁移到低速存储设备(例如，在对数据日志文件的得分进行排序或排名之后)，以释放存储空间。在一些实施例中，低速存储设备中存储的数据日志文件中的热数据可以首先保存在磁盘缓存中，如果数据日志文件的得分达到预定阈值，则可以将其迁移到高速存储设备中。

图11是示出根据本文实施例的用于在日志结构存储系统中执行数据流控制的处理1100的流程图。在一些实施例中，处理1100的一些或全部操作可以是由日志结构存储系统(例如，图3的日志结构存储系统300)执行的流控制/优化程序的示例。为了方便，处理1100将被描述为由日志结构存储系统执行。然而，处理1100可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统可以执行处理1100。

在1102，存储系统(例如，日志结构存储系统300)维护多层存储设备(例如，存储设备350、360和370)。在一些实施例中，多层存储设备是按基于一个或多个性能特性(例如，访问速度、访问带宽或访问延迟)的分层结构来分层的。例如，多层存储设备可以包括具有不同访问速度的多个存储设备，并且可以存储具有对应特性的数据(例如，第一层存储设备可以存储比存储在第二层存储设备中的区块链数据更频繁被访问的区块链数据)。

在一些实施例中，日志结构存储系统300可以将流控制策略分配给多层存储设备。例如，日志结构存储系统300可以基于第一层存储设备和第二层存储设备的一个或多个特性(例如，访问速度、访问带宽、访问延迟、使用率、垃圾率、碎片水平)，将第一流控制策略分配给第一层存储设备，将第二流控制策略分配给第二层存储设备。在一些实施例中，第一流控制策略可以包括以下一项或多项：将数据写入第一层存储设备的第一速度，或用于调整将数据写入第一层存储设备的第一速度的一个或多个第一阈值，并且第二流控制策略可以包括以下一项或多项：将数据写入第一层存储设备的第二速度，或用于调整将数据写入第二层存储设备的第二速度的一个或多个第二阈值。

在1104，日志结构存储系统300接收针对账本数据的写入请求。在一些实施例中，账本数据可以包括例如交易数据、区块数据和状态数据等的区块链数据。

在1106，日志结构存储系统300识别账本数据的类型。例如，后端数据管理子系统330可以确定账本数据是交易数据、区块数据还是状态数据。在1108，日志结构存储系统300确定账本数据是否是区块数据。在一些实施例中，区块数据具有比其他类型的区块链数据(例如，交易数据、状态数据或索引数据)更大的大小，并且可能对日志结构存储系统300的I/O操作的吞吐量具有更大的影响。如果确定账本数据是区块数据，则处理进行到步骤1110，其中后端数据管理子系统330将数据直接写入第二层存储设备(例如，存储设备360)，并跳过第一层存储设备，例如，以节省之后执行迁移的成本。在一些实施例中，第二层存储设备位于比第一层存储设备低的层。例如，第二层存储设备的访问速度可以比第一层存储设备的访问速度更低。在一些实施例中，第二层存储设备的成本可以比第一层存储设备的成本更低。在一些实施例中，第二层存储设备的存储空间可以比第一层存储设备的存储空间更大。如果确定账本数据不是区块数据，则处理进行到步骤1112。

在1112，如果确定账本数据不是区块数据，则日志结构存储系统300确定第一层存储设备的使用率。

在1114，日志结构存储系统300确定使用率是否达到或超过预定阈值。在一些实施例中，预定阈值用于确定第一层存储设备是否基本上已满。例如，如果确定使用率达到或超过阈值(例如，85％)，则日志结构存储系统300可以确定第一层存储设备基本上已满。如果确定使用率达到或超过预定阈值，则处理进行到步骤1116，在步骤1116，将数据写入第二层存储设备。如果确定使用率低于预定阈值，则处理进行到步骤1118。

在1118，日志结构存储系统300在确定使用率低于预定阈值的情况下，将数据写入第一层存储设备。

在一些实施例中，日志结构存储系统300可以基于第一层存储设备的使用率来调整将数据写入第一层存储设备的速度。例如，如果确定第一层存储设备的使用率达到或超过第一预定阈值(例如65％)，则日志结构存储系统300可以降低将数据写入第一层存储设备的速度。在一些实施例中，日志结构存储系统300可以基于第一层存储设备的使用率来降低将数据写入第一层存储设备的速度。在一些实施例中，日志结构存储系统300可以随着第一层存储设备的使用率的增加来持续降低将数据写入第一层存储设备的速度。例如，当第一层存储设备的使用率是第一值(例如，70％)时，日志结构存储系统300可以将数据写入第一层存储设备中的速度降低到第一速率(例如，500MB/s)，以及当第一层存储设备的使用率为比第一值大的第二值(例如，75％)时，将数据写入第一层存储设备的速度降低到低于第一速率的第二速率(例如400MB/s)。

在一些实施例中，如果确定第一层存储设备的使用率低于第二预定阈值(例如，35％)，则日志结构存储系统300可以提高将数据写入第一层存储设备的速度。在一些实施例中，日志结构存储系统300可以基于第一层存储设备的使用率来提高将数据写入第一层存储设备的速度。在一些实施例中，日志结构存储系统300可以随着第一层存储设备的使用率的降低来持续提高将数据写入第一层存储设备的速度。例如，当第一层存储设备的使用率是第三值(例如，30％)时，日志结构存储系统300可以将数据写入第一层存储设备中的速度提高到第三速率(例如，550MB/s)，以及当第一层存储设备的使用率为比第三值小的第四值(例如，20％)时，将数据写入第一层存储设备的速度提高到高于第三速率的第四速率(例如600MB/s)。

图12是示出可根据本文实施例执行的处理1200的流程图。为了方便，处理1200将被描述为由图3的日志结构存储系统300执行。然而，处理1200可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统可以执行处理1200。

在1202，存储系统(例如，日志结构存储系统300)接收多个处理引擎的配置。在一些实施例中，所述配置可以根据例如表1的分布式账本系统的多种数据类型中的每种数据类型的特性，配置用于处理这种数据类型的相应的处理引擎类型。在一些实施例中，存储系统300可以包括被指定用于处理区块数据的处理引擎类型；被指定用于处理交易数据的处理引擎类型；被指定用于处理状态数据的处理引擎类型；被指定用于处理索引数据的处理引擎类型。

在一些实施例中，状态数据可以包括当前状态数据和历史状态数据，并且存储系统300可以包括被指定用于处理当前状态数据的处理引擎类型和被指定用于处理历史状态数据的处理引擎类型。

在1204，存储系统300接收针对分布式账本系统的数据的处理请求。在一些实施例中，分布式账本系统的数据类型可以包括区块数据、交易数据、状态数据和索引数据。

在一些实施例中，存储系统300可以接收针对分布式账本系统的数据的I/O请求。在一些实施例中，被指定用于处理分布式账本系统的一种数据类型的相应的处理引擎类型可以包括被指定用于对分布式账本系统的一种数据类型执行读取或写入操作的相应的I/O处理引擎类型。

在一些实施例中，存储系统300可以接收针对分布式账本系统的数据的数据管理请求。在一些实施例中，被指定用于处理一种数据类型的相应的处理引擎类型可以包括被指定用于对存储系统中的一种数据类型执行数据管理操作的相应的数据管理处理引擎类型。在一些实施例中，管理操作包括分层、压合、压缩、纠删编码或快照中的一个或多个。

在1206，存储系统300确定数据属于分布式账本系统的多种数据类型中的一种数据类型。在一些实施例中，所述一种数据类型可以是区块数据或交易数据。在一些实施例中，所述一种数据类型可以是状态数据。

在1208，存储系统300应用被指定用于处理所述一种数据类型的处理引擎类型。在一些实施例中，被指定用于处理所述一种数据类型的所述处理引擎类型可以被配置为具有包括对存储系统300中的区块数据或交易数据进行分层、纠删编码和压缩的功能。在一些实施例中，被指定用于处理所述一种数据类型的处理引擎类型可以被配置为具有包括对存储系统300中的状态数据进行快照和压缩的功能。

图13是示出可根据本文实施例执行的处理1300的流程图。为了方便，处理1300将被描述为由图3的日志结构存储系统300执行。然而，处理1300可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统可以执行处理1300。

在1302，存储系统(例如，日志结构存储系统300)接收多个处理引擎的配置。在一些实施例中，所述配置可以根据例如表1的基于区块链的中心化账本系统的多种数据类型中的每种数据类型的特性，配置用于处理这种数据类型的相应的处理引擎类型。

在一些实施例中，存储系统300可以包括被指定用于处理区块数据的处理引擎类型；被指定用于处理交易数据的处理引擎类型；被指定用于处理索引数据的处理引擎类型。

在1304，存储系统300接收针对基于区块链的中心化账本系统的数据的处理请求。在一些实施例中，基于区块链的中心化账本系统的数据类型可以包括区块数据、交易数据和索引数据。

在一些实施例中，存储系统300可以接收针对基于区块链的中心化账本系统的数据的I/O请求。在一些实施例中，被指定用于处理基于区块链的中心化账本系统的一种数据类型的相应的处理引擎类型可以包括被指定用于对基于区块链的中心化账本系统的所述一种数据类型执行读取或写入操作的相应的I/O处理引擎类型。例如，根据处理500、600、700、1100和1400的部分或全部操作，对基于区块链的中心化账本系统的数据进行分析。

在一些实施例中，存储系统300可以接收针对基于区块链的中心化账本系统的数据的数据管理请求。在一些实施例中，被指定用于处理所述一种数据类型的相应的处理引擎类型可以包括被指定用于对存储系统中的所述一种数据类型执行数据管理操作的相应的数据管理处理引擎类型。在一些实施例中，管理操作可以包括分层、压合、压缩、纠删编码或快照中的一个或多个。

在1306，存储系统300确定所述数据属于基于区块链的中心化账本系统的数据类型中的一种数据类型。在一些实施例中，所述一种数据类型可以是区块数据或交易数据。

在1308，存储系统300根据一种数据类型的特性应用被指定用于处理所述一种数据类型的处理引擎类型。在一些实施例中，被指定用于处理所述一种数据类型的处理引擎类型可以被配置为具有包括对存储系统中的区块数据或交易数据进行分层、纠删编码和压缩的功能。在一些实施例中，存储系统300根据处理800、900、1000和1400的一些或全部操作来应用被指定用于处理所述一种数据类型的处理引擎类型。

图14是示出可根据本文实施例执行的处理1400的流程图。为了方便，处理1400将被描述为由图3的日志结构存储系统300执行。然而，处理1400可以由位于一个或多个位置的一个或多个计算机的系统执行，并且根据本文被适当地编程。例如，适当编程的数据处理和存储系统可以执行处理1400。

在1402，存储系统(例如，日志结构存储系统300)接收用于在存储系统中存储相应的多个区块链数据的多个写入请求。在一些实施例中，多个区块链数据中的每个可以包括区块、交易或区块链网络的状态中的一个或多个的值以及与该值相对应的键。在一些实施例中，键可以包括与该值相对应的哈希值。

在1404，存储系统300根据多个区块链数据的时间顺序将多个区块链数据追加到数据日志文件(例如，数据日志文件390、362、364、366、372、374和376)。例如，之后接收到的区块链数据将被追加到已存储在数据日志文件中的先前接收到的数据中。在一些实施例中，数据日志文件可以是仅追加文件。在一些实施例中，数据日志文件可以存储在日志结构存储系统300的包括多层存储设备的多层存储子系统(例如，多层存储子系统320)中的第一层存储设备(例如，存储设备350)中，并且第一层存储设备的访问速度在多层存储设备中最高。

在1406，日志结构存储系统300被限制根据任何其他度量，例如根据多个区块链数据中的值的对应键(例如，在KVP中)对数据日志文件中的多个区块链数据进行排序。在一些实施例中，不同于现有存储系统将根据多个区块链数据中的值的对应键对数据日志文件中的多个区块链数据进行重新排列，日志结构存储系统300的数据日志文件中的多个区块链数据是根据日志结构存储系统300生成或接收到所述多个区块链数据的时间来排列的。在1408，日志结构存储系统300例如根据处理600的相应操作生成指示数据日志文件中的多个区块链数据的对应物理存储位置的索引。

在1410，日志结构存储系统300例如根据处理600的相应操作将索引写入第一层存储设备中。

在1412，日志结构存储系统300例如根据处理1000的相应操作，确定多个区块链数据的对应迁移优先级、得分或度量。在一些实施例中，日志结构存储系统300根据多个区块链数据的时间顺序确定对应的迁移优先级。在一些实施例中，较旧的区块链数据的迁移优先级可以高于较新区块链数据的迁移优先级。

在1414，日志结构存储系统300根据对应的迁移优先级将存储在第一层存储设备中的多个区块链数据迁移到第二层存储设备(例如，存储设备360)中。在一些实施例中，第二层存储设备的访问速度可以比第一层存储设备的访问速度更低。

图15描绘了根据本文的实施例的装置1500的模块的示例。装置1500可以是存储系统(例如，图3的日志结构存储系统300)的实施例的示例。装置1500可以对应于上述实施例，装置1500包括：接收模块1502，用于接收针对中心化账本系统的数据的处理请求，其中，中心化账本系统的多种数据类型包括：区块数据、交易数据和索引数据；确定模块1504，用于确定所述数据属于中心化账本系统的多种数据类型中的一种数据类型；应用模块1506，用于根据该一种数据类型的特性来应用被指定用于处理所述一种数据类型的处理引擎类型。

在可选实施例中，装置1500还包括接收子模块，用于接收多个处理引擎的配置，其中，该配置根据中心化账本系统的每种数据类型的特性对用于处理这种数据类型的对应的处理引擎类型进行配置。

在可选实施例中，装置1500可以包括：被指定用于处理区块数据的处理引擎类型；被指定用于处理交易数据的处理引擎类型；被指定用于处理索引数据的处理引擎类型。

在可选实施例中，装置1500还包括接收子模块，用于接收针对中心化账本系统的数据的输入/输出(I/O)请求。被指定用于处理中心化账本系统的所述一种数据类型的相应的处理引擎类型可以包括被指定用于对中心化账本系统的所述一种数据类型执行读取或写入操作的相应的I/O处理引擎类型。

在可选实施例中，装置1500还包括：接收子模块，用于接收针对中心化账本系统的数据的数据管理请求。被指定用于处理所述一种数据类型的相应的处理引擎类型可以包括被指定用于对存储系统中的所述一种数据类型执行数据管理操作的相应的数据管理处理引擎类型。管理操作包括分层、压合、压缩、纠删编码或快照中的一个或多个。

在可选实施例中，所述一种数据类型是区块数据或交易数据，并且被指定用于处理所述一种数据类型的处理引擎类型配置有包括对存储系统中的区块数据或交易数据进行分层、纠删编码和压缩的功能。

在先前实施中示出的系统、装置、模块或单元可以通过使用计算机芯片或实体来实现，或者可以通过使用具有特定功能的产品来实现。典型的实施设备是计算机，计算机可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件接收和发送设备、游戏控制台、平板电脑、可穿戴设备或这些设备的任意组合。

对于装置中各个单元的功能和角色的实施过程，可以参考前一方法中相应步骤的实施过程。为简单起见，这里省略了细节。

由于装置实施例基本上与方法实施例相对应，因此对于相关部分，可以参考方法实施例中的相关描述。前述装置实施例仅仅是示例。被描述为单独部分的模块可以或可以不是物理上分离的，并且显示为模块的部分可以是或可以不是物理模块，可以位于一个位置，或者可以分布在多个网络模块上。可以基于实际需求来选择一些或所有模块，以实现本文方案的目标。本领域普通技术人员无需付出创造性努力就能理解和实现本申请的实施例。

再次参见图15，它可以被解释为示出了数据处理和存储装置的内部功能模块和结构。数据处理和存储装置可以是日志结构存储系统(例如，图3的日志结构存储系统300)的示例。本质上，执行主体实质上可以是电子设备，该电子设备包括以下：一个或多个处理器；一个或多个计算机可读存储器，其被配置为存储一个或多个处理器的可执行指令。在一些实施例中，一个或多个计算机可读存储器耦接到一个或多个处理器并且具有存储在其上的程序指令，所述指令可由一个或多个处理器执行以执行本文描述的算法、方法、功能、处理、流程和程序。

所描述的主题的实施例可单独地或组合地包括一个或多个特征。例如，在第一实施例中，一种方法包括：存储系统接收针对中心化账本系统的数据的处理请求，其中，所述中心化账本系统的多种数据类型包括区块数据、交易数据和索引数据；所述存储系统确定所述数据属于所述中心化账本系统的多种数据类型中的一种数据类型。所述存储系统根据一种数据类型的特性来应用被指定用于处理所述一种数据类型的处理引擎类型。

前述和其它描述的实施例可以各自可选地包括一个或多个以下特征：

第一特征，可与以下任意特征组合，指定所述方法还包括：所述存储系统接收多个处理引擎的配置，其中，所述配置根据所述中心化账本系统的每种数据类型的特性对用于处理这种数据类型的对应的处理引擎类型进行配置。

第二特征，可与任意先前或以下特征组合，指定所述存储系统还包括：被指定用于处理区块数据的处理引擎类型；被指定用于处理交易数据的处理引擎类型；以及被指定用于处理索引数据的处理引擎类型。

第三特征，可与任意先前或以下特征组合，指定所述存储系统接收针对所述中心化账本系统的数据的处理请求包括：所述存储系统接收针对所述中心化账本系统的数据的输入/输出(I/O)请求；以及被指定用于处理所述中心化账本系统的所述一种数据类型的相应的处理引擎类型可以包括被指定用于对所述中心化账本系统的所述一种数据类型执行读取或写入操作的相应的输入/输出(I/O)处理引擎类型。

第四特征，可与任意先前或以下特征组合，指定所述存储系统接收针对所述中心化账本系统的数据的处理请求包括所述存储系统接收针对所述中心化账本系统的数据的数据管理请求；被指定用于处理所述一种数据类型的相应的处理引擎类型包括被指定用于对所述存储系统中的所述一种数据类型执行数据管理操作的相应的数据管理处理引擎类型。所述管理操作包括分层、压合、压缩、纠删编码或快照中的一个或多个。

第五特征，可与任意先前特征组合，指定所述一种数据类型是区块数据或交易数据，并且被指定用于处理所述一种数据类型的处理引擎类型配置有包括对所述存储系统中的所述区块数据或交易数据进行分层、纠删编码和压缩的功能。

本文中描述的主题、动作和操作的实施例可以在数字电子电路中、有形体现的计算机软件或固件中、包括本文中公开的结构及其结构等同物的计算机硬件中，或者它们中的一个或多个的组合中实现。本文中描述的主题的实施例可以实现为一个或多个计算机程序，例如，一个或多个计算机程序指令模块，编码在计算机程序载体上，用于由数据处理装置执行或控制数据处理的操作。例如，计算机程序载体可以包括具有一个或多个计算机可读存储介质，其上编码或存储有指令。载体可以是有形的非暂态计算机可读介质，例如磁盘、磁光盘或光盘、固态驱动器、随机存取存储器(RAM)、只读存储器(ROM)或其他媒体类型。可选地或附加地，载体可以是人工生成的传播信号，例如，机器生成的电、光或电磁信号，其被生成以编码用于传输到合适的接收器装置以供数据处理装置执行的信息。计算机存储介质可以是或可以部分是机器可读存储设备、机器可读存储基板、随机或串行访问存储器设备或它们中的一个或多个的组合。计算机存储介质不是传播信号。

计算机程序也可以被称为或描述为程序、软件、软件应用、app、模块、软件模块、引擎、脚本或代码，可以以任何形式的编程语言编写，包括编译或演绎性语言、说明或程序性语言；它可以配置为任何形式，包括作为独立程序，或者作为模块、组件、引擎、子程序或适合在计算环境中执行的其他单元，该环境可包括由数据通信网络互连的在一个或多个位置一台或多台计算机。

计算机程序可以但非必须对应于文件系统中的文件。计算机程序可以存储在：保存其他程序或数据的文件的一部分中，例如，存储在标记语言文档中的一个或多个脚本；专用于所讨论的程序的单个文件；或者多个协调文件，例如，存储一个或多个模块、子程序或代码部分的多个文件。

举例来说，用于执行计算机程序的处理器包括通用和专用微处理器，以及任何类型的数字计算机的任何一个或多个处理器。通常，处理器将接收用于执行的计算机程序的指令、以及接收来自耦接到处理器的非暂态计算机可读介质的数据。

术语“数据处理装置”包括用于处理数据的所有类型的装置、设备和机器，包括例如可编程处理器、计算机或多个处理器或计算机。数据处理设备可以包括例如FPGA(现场可编程门阵列)，ASIC(专用集成电路)或GPU(图形处理单元)的专用逻辑电路。除了硬件，该装置还可以包括为计算机程序创建执行环境的代码，例如，构成处理器固件、协议栈、数据库管理系统、操作系统、或者它们一个或多个的组合的代码。

本文中描述的处理和逻辑流程可以由一台或多台计算机或处理器执行一个或多个计算机程序进行，以通过对输入数据进行运算并生成输出来执行操作。过程和逻辑流程也可以由例如FPGA、ASIC或GPU等的专用逻辑电路或专用逻辑电路与一个或多个编程计算机的组合来执行。

适合于执行计算机程序的计算机可以基于通用和/或专用微处理器，或任何其他种类的中央处理单元。通常，中央处理单元将从只读存储器和/或随机存取存储器接收指令和数据。计算机的元件可包括用于执行指令的中央处理单元和用于存储指令和数据的一个或多个存储设备。中央处理单元和存储器可以补充有专用逻辑电路或集成在专用逻辑电路中。

通常，计算机还将包括或可操作地耦接至一个或多个大容量存储设备，以从一个或多个存储设备接收数据或将数据传输到一个或多个大容量存储设备。存储设备可以是例如磁盘、磁光盘或光盘、固态驱动器或任何其他类型的非暂态计算机可读介质。然而，计算机不需要具有这样的设备。因此，计算机可以耦接到本地和/或远程的例如一个或多个存储器的一个或多个存储设备。例如，计算机可以包括作为计算机的集成组件的一个或多个本地存储器，或者计算机可以耦接到云网络中的一个或多个远程存储器。此外，计算机可以嵌入在另一个设备中，例如移动电话，个人数字助理(PDA)，移动音频或视频播放器，游戏控制台，全球定位系统(GPS)接收器或例如通用串行总线(USB)闪存驱动器的便携式存储设备，仅举几例。

组件可以通过诸如直接地连接、或通过一个或多个中间组件彼此电学连接或光学连接可通信地连接而彼此“耦接”。如果其中一个组件被集成到另一个组件中，组件也可以彼此“耦接”。例如，集成到处理器(例如，L2缓存组件)中的存储组件“耦接到”处理器。

为了提供与用户的交互，本文中所描述的主题的实施例可以在计算机上实现或配置为与该计算机通信，该计算机具有：显示设备，例如，LCD(液晶显示器)监视器，用于向用户显示信息；以及输入设备，用户可以通过该输入设备向该计算机提供输入，例如键盘和例如鼠标、轨迹球或触摸板等的指针设备。其他类型的设备也可用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的感觉反馈，例如视觉反馈、听觉反馈或触觉反馈；并且可以接收来自用户的任何形式的输入，包括声音、语音或触觉输入。此外，计算机可以通过向用户使用的设备发送文档和从用户使用的设备接收文档来与用户交互；例如，通过向用户设备上的web浏览器发送web页面以响应从web浏览器收到的请求，或者通过与例如智能电话或电子平板电脑等的用户设备上运行的应用(app)进行交互。此外，计算机可以通过向个人设备(例如，运行消息应用的智能手机)轮流发送文本消息或其他形式的消息来并接收来自用户的响应消息来与用户交互。

本文使用与系统，装置和计算机程序组件有关的术语“配置为”。对于被配置为执行特定操作或动作的一个或多个计算机的系统，意味着系统已经在其上安装了在运行中促使该系统执行所述操作或动作的软件、固件、硬件或它们的组合。对于被配置为执行特定操作或动作的一个或多个计算机程序，意味着一个或多个程序包括当被数据处理装置执行时促使该装置执行所述操作或动作的指令。对于被配置为执行特定操作或动作的专用逻辑电路，意味着该电路具有执行所述操作或动作的电子逻辑。

尽管本文包含许多具体实施细节，但这些不应被解释为由权利要求本身限定的对要求保护的范围的限制，而是作为对特定实施例的具体特征的描述。在本文单独实施例的上下文中描述的某些特征也可以在单个实施例中组合实现。相反，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合在多个实施例中实现。此外，尽管上面的特征可以描述为以某些组合起作用并且甚至最初如此要求保护，但是在一些情况下，可以从要求保护的组合中删除来自该组合的一个或多个特征，并且要求保护可以指向子组合或子组合的变体。

类似地，虽然以特定顺序在附图中描绘了操作并且在权利要求中叙述了操作，但是这不应该被理解为：为了达到期望的结果，要求以所示的特定顺序或依次执行这些操作，或者要求执行所有示出的操作。在某些情况下，多任务和并行处理可能是有利的。此外，上述实施例中的各种系统模块和组件的划分不应被理解为所有实施例中都要求如此划分，而应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中或打包成多个软件产品。

已经描述了主题的特定实施例。其他实施例在以下权利要求的范围内。例如，权利要求中记载的动作可以以不同的顺序执行并且仍然实现期望的结果。作为一个示例，附图中描绘的过程无需要求所示的特定顺序或次序来实现期望的结果。在一些情况下，多任务和并行处理可能是有利的。

Claims (8)

1.一种计算机实现的方法，包括：

存储系统接收针对中心化账本系统的数据的处理请求，其中，所述中心化账本系统的多种数据类型包括区块数据、交易数据和索引数据；

所述存储系统确定所述数据属于所述中心化账本系统的所述多种数据类型中的一种数据类型；

所述存储系统根据所述一种数据类型的特性来应用被指定用于处理所述一种数据类型的处理引擎类型。

2.如权利要求1所述的计算机实现的方法，还包括：

所述存储系统接收多个处理引擎的配置，

其中，所述配置根据所述中心化账本系统的每种数据类型的特性对用于处理这种数据类型的对应的处理引擎类型进行配置。

3.如权利要求1所述的计算机实现的方法，其中，所述存储系统包括：

被指定用于处理区块数据的处理引擎类型；

被指定用于处理交易数据的处理引擎类型；以及

被指定用于处理索引数据的处理引擎类型。

4.如权利要求1所述的计算机实现的方法，其中，

所述存储系统接收针对所述中心化账本系统的所述数据的处理请求包括：所述存储系统接收针对所述中心化账本系统的所述数据的输入/输出I/O请求；以及

被指定用于处理所述中心化账本系统的所述一种数据类型的相应的处理引擎类型包括：被指定用于对所述中心化账本系统的所述一种数据类型执行读取或写入操作的相应的输入/输出I/O处理引擎类型。

5.如权利要求1所述的计算机实现的方法，其中：

所述存储系统接收针对所述中心化账本系统的所述数据的处理请求包括：所述存储系统接收针对所述中心化账本系统的所述数据的数据管理请求；

被指定用于处理所述一种数据类型的相应的处理引擎类型包括：被指定用于对所述存储系统中的所述一种数据类型执行数据管理操作的相应的数据管理处理引擎类型，以及

所述管理操作包括分层、压合、压缩、纠删编码或快照中的一个或多个。

6.如权利要求1所述的计算机实现的方法，其中，

所述一种数据类型是区块数据或交易数据，并且

被指定用于处理所述一种数据类型的处理引擎类型配置有包括对所述存储系统中的所述区块数据或交易数据进行分层、纠删编码和压缩的功能。

7.一种用于数据处理和存储的装置，所述装置包括用于执行如权利要求1至6中任一项所述的方法的多个模块。

8.一种用于数据处理和存储的系统，包括：

一个或多个处理器；以及

耦接至所述一个或多个处理器且其上存储有指令的一个或多个计算机可读存储器，所述指令能由所述一个或多个处理器执行以执行如权利要求1至6中任一项所述的计算机实现的方法。

Images