链上链下协同的数据归档真的太难了!和解?

趣链科技

    前言
    区块链的全复制扩展性等问题,使得业务向链上迁移会考虑采用两层设计,有基于区块链的合约层和链下拓展层,链下层承担扩展链上能力。在两层系统中,业务的存证或者协调数据在链上,链下拓展层会保存完整数据内容,并参与业务计算。
    随着业务的持续,链下节点的数据会逐渐累积,越来越大,数据的增长速度甚至会超过存储介质容量增长的速度,而不得不为节点提供更大的高性能磁盘,当数据增长突破容量限定后会影响系统性能与业务持续性;链上合约层,当状态数据数据累积到一定数据量级会导致系统吞吐量下降、链上数据查询变慢,服务质量下降。
    另一方面,双层系统无法和一般的数据存储系统(MySQL存储系统)一样进行“select-insert-delete”式的归档。合约数据涉及多个业务参与方,链上数据和链下的锚定、关联关系不能被破坏等约束。
    为解决这些问题,我们对两层系统的数据归档进行了一定的实践,当合约层以及拓展层数据停止改变或不被频繁使用时,对其进行迁移减少合约状态数据让出拓展层节点主存储空间,提升系统的性能和服务质量。
    什么是数据归档?
    -----数据归档过程和目标
    为了详述数据归档来龙去脉,我们需要了解几个简单的概念,首先,需要了解备份和归档的区别
    
  • 备份(backup):存储在非易失性存储介质上的数据集合,在原始数据丢失、损坏或不可用时,可以从备份系统访问或从备份数据中恢复,也称为副本。备份同时保护了所有生产系统的活跃的和非活跃的数据。我们通常说的备份,类似“复制“操作
  • 归档(archive):将不再活跃但必须保留的数据移动到另一个存储系统,以便释放节点主存储,提高系统性能。

    归档的数据是生产数据的子集,一般,将归档数据转存到专用系统,归档类似”剪切“操作。在两层系统语境下,归档意味着将合约的状态数据以及数据锚定的链下系统数据作为一个整体进行归档。
    对数据归档,我们要达到如下目标:
    1)独立的数据归档支持合约,用于索引链上的数据,包括3方面内容:数据指纹、更新时间、关联方;
    2)一个归档模块以及独立归档服务:使用统一的架构,将数据迁移到一致的位置;
    3)归档后的数据需要进行统一管理和一致的访问;减少运维归档数据所需的成本,同时需要保护归档数据的安全性;
    4)归档后的数据具有索引和搜索功能,能更有效、快捷地对归档的数据访问并利用;
    5)相关归档的恢复:可以将某次归档恢复到生产环境。
    一般的数据归档的过程:select-insert-delete,创建一个新的数据库-归档库,然后在归档库创建与生产库相同的表;不断查询生产库数据记录,同步复制到归档库;生产库删除已经复制的数据记录。虽然数据归档过程非常简单,但是设计数据归档的方案,我们必须想清楚以下几个问题?
    
  • 归档前:那些数据可以归档?数据适合归档吗?归档库如何选型?
  • 归档执行阶段:数据归档过程需要不断的读写生产库,这个过程将会大量使用的网络、IO,那为了防止对线上业务造成压力,数据归档一般只在业务低峰期执行。
  • 归档后:数据幂等被破坏,数据归档导致生成数据缺失,会对业务造成影响。针对归档的过程和目标。

    综上,我们将提出设计和实现契合自身架构特点的归档方案。
    归档方案实践
    趣链科技自研的区块链隐私计算平台BitXMesh,将区块链与隐私计算技术深度融合,支持链上链下协同的数据共享和隐私计算。
    BitXMesh是一个两层架构系统。包括区块链合约层,链上部署有数据共享合约、联邦计算协调合约等,链下拓展层由BitXMesh节点组成并提供数据共享、联邦计算等能力。从数据的维度看,整个系统由合约数据及合约数据锚定、节点内的数据以及支撑节点能力、逐渐累积的业务功能数据组成。归档数据的时候需要考虑:链上数据和节点本地数据,数据之间的锚定关系,以及本地数据的关联关系。同时,数据类型也是需要考虑的,节点内有文件K/V类型的数据,这些数据归档需要存放在不同的归档库中。
    BitXMesh数据归档组件包含:内部的归档模块(Archiver module)、链上数据归档支持合约存储对接组件(对接BitXMesh K/V存储,链交互模块)、归档库(存储归档数据)。其中,链上数据归档支持合约是为了两层系统协同归档而构建的合约,合约主要功能是进行链上数据的索引以及按时间进行引用计算,便于定位链上数据。整个归档模块组件及其构成,如下图。
    
    针对K/V类型的数据,选择BadgerDB作为归档库,存放BitXMesh归档的K/V数据;对文件数据,使用IPFS作为归档存储,同时文件的元信息存储在Badger DB归档库;整个归档数据项的标识ID都会记录在归档摘要文件中,归档摘要文件记录了整个归档的元信息,该文件也可以提供给基于BitXMesh开发的业务系统使用,将业务系统的数据也进行归档。整个归档过程如下:
    1)首先,归档库初始化。指定归档库存储路径,会在该目录下创建K/VBadger DB库以及存储大文件的ipfs,这两个库的创建尤其关键,归档的数据存储于两个库中,后续可开发应用对归档的数据进行管理。
    2)其次,执行归档。目前,按“时间区间”进行归档,分为两个阶段:链上数据及与链上锚定的节点数据的归档、链下节点数据归档。
    
  • 链上数据及与链上锚定的节点数据的归档:该步骤需要归档支持合约的支持,归档支持合约主要存储链上数据的标识信息(数据ID)以及数据存储时间。当归档时,先查询该合约得到需要归档的数据列表,根据这个数据列表,去归档节点与其锚定的数据。整个过程包括查询-写入-删除,查询链上数据和链下数据,将查询得到的数据信息写入到归档库,一旦写入成功,将摘要写入到归档摘要文件,最后删除数据。
  • 链下节点数据归档:该步骤归档节点的业务数据,落到时间区间的数据即可执行查询-写入-删除操作。一旦碰到文件数据,需要查询元信息,写入K/V归档库,再取文件block写入到ipfs归档系统。

    3)最后,资源回收和落盘操作。上面两步已经将符合时间范围的数据进行归档,之后需要将归档模块访问节点数据的连接断开,归档库也需要关闭数据访问连接。归档摘要文件落到磁盘。
    在进行了一次归档操作后,归档库中的数据可以通过归档服务进行访问,类似业务系统的做法,将归档库作为backend数据存储,通过HTTP接口访问这些归档的数据。
    总结
    数据归档是针对大量数据累积的系统,对数据进行有计划的迁移,当数据停止改变或不被频繁使用时,通过数据归档把它们转存到别的地方,让出存储空间,提升系统的性能。本文以BitXMesh数据归档模块为例,对链上-链下两层架构系统的数据归档进行实践,将归档融入到系统功能,完成了归档使用统一的架构,将数据迁移到一致的位置,归档后的数据需要进行,统一管理和一致的访问目标。