业务日志存储方法、系统、装置及设备
技术领域
本说明书实施例涉及信息技术领域,尤其涉及业务日志存储方法、系统、装置及设备。
背景技术
当前核心交易系统本身均包含相应的业务数据库。这些数据库作为基础服务提供方,已经可以满足正常的业务需求。
核心交易系统在对数据库基础服务方进行增删改查等操作时,同时会产生相应的业务日志,这些日志反应了交易系统的对业务数据的操作记录,由于这类业务日志时刻产生,数量较多,不出问题的时候不受关注。但是在数据库基础服务服务方发生故障时,又往往要依靠业务日志进行数据恢复,但此时业务日志是否被人篡改或者发生错误也难以知晓。
基于此,需要一种对于不可篡改且可验证的业务日志存储方案。
发明内容
针对现有数据库基础服务方中难以了解己方业务日志是否出现差错,以及无法验证的问题,在第一方面,本说明书实施例提供一种业务日志存储方法、装置及设备,所述方法应用于包括数据库基础服务方和通过多个数据块存储业务日志的中心化的数据库增强服务提供方的系统中,具体包括:
数据库基础服务方,发送待存储的业务日志至数据库增强服务提供方,所述业务日志用于记载数据库基础服务方对于业务数据的操作记录;
数据库增强服务提供方,接收待存储的业务日志,确定业务日志的哈希值;当达到预设的成块条件时,确定待写入数据块中的至少一个业务日志,生成包含数据块的哈希值和所述业务日志的第N个数据块,具体包括:
当N=1时,初始数据块的哈希值和块高基于预设方式给定;当N>1时,根据待写入数据块中的业务日志的内容和第N-1个数据块的哈希值确定第N个数据块的哈希值,生成包含第N个数据块的哈希值和所述业务日志的第N个数据块,其中,数据块的块高基于成块时间的先后顺序单调递增;
数据库增强服务提供方,返回哈希值至数据库基础服务方,其中,所述哈希值包括所述业务日志的哈希值和/或业务日志所处块高的哈希值;
数据库基础服务方,接收返回的业务日志的哈希值,并存储。
对应的,本说明书实施例还提供一种业务日志存储系统,包括数据库基础服务方和通过多个数据块存储业务日志的中心化的数据库增强服务提供方,在所述系统中,
数据库基础服务方,发送待存储的业务日志至数据库增强服务提供方,所述业务日志用于记载数据库基础服务方对于业务数据的操作记录;
数据库增强服务提供方,接收待存储的业务日志,确定业务日志的哈希值;当达到预设的成块条件时,确定待写入数据块中的至少一个业务日志,生成包含数据块的哈希值和所述业务日志的第N个数据块,具体包括:
当N=1时,初始数据块的哈希值和块高基于预设方式给定;当N>1时,根据待写入数据块中的业务日志的内容和第N-1个数据块的哈希值确定第N个数据块的哈希值,生成包含第N个数据块的哈希值和所述业务日志的第N个数据块,其中,数据块的块高基于成块时间的先后顺序单调递增;
数据库增强服务提供方,返回哈希值至数据库基础服务方,其中,所述哈希值包括所述业务日志的哈希值和/或业务日志所处块高的哈希值;
数据库基础服务方,接收返回的业务日志的哈希值,并存储。
在第二方面,本说明书实施例还提供另一种业务日志存储方法,应用通过多个数据块存储业务日志的中心化的数据库增强服务提供方,所述方法包括:
接收待存储的业务日志,确定业务日志的哈希值;
当达到预设的成块条件时,确定待写入数据块中的至少一个业务日志,生成包含数据块的哈希值和所述业务日志的第N个数据块,具体包括:
当N=1时,初始数据块的哈希值和块高基于预设方式给定;
当N>1时,根据待写入数据块中的业务日志的内容和第N-1个数据块的哈希值确定第N个数据块的哈希值,生成包含第N个数据块的哈希值和所述业务日志的第N个数据块,其中,数据块的块高基于成块时间的先后顺序单调递增。
对应的,本说明书实施例还提供一种业务日志存储装置,应用通过多个数据块存储业务日志的中心化的数据库增强服务提供方,所述装置包括:
接收模块,接收待存储的业务日志,确定业务日志的哈希值;
生成模块,当达到预设的成块条件时,确定待写入数据块中的至少一个业务日志,生成包含数据块的哈希值和所述业务日志的第N个数据块,具体包括:
当N=1时,初始数据块的哈希值和块高基于预设方式给定;
当N>1时,根据待写入数据块中的业务日志的内容和第N-1个数据块的哈希值确定第N个数据块的哈希值,生成包含第N个数据块的哈希值和所述业务日志的第N个数据块,其中,数据块的块高基于成块时间的先后顺序单调递增。
数据库基础服务方在对业务数据进行处理,随即生成相应的记载了具体操作方式的业务日志。通过将业务日志发送给数据库增强服务提供方,数据库增强服务提供方随即进行将业务日志写入块链式的账本进行存储,对数据库基础服务方,提供可隐匿但是不可篡改且密码学可以验证的业务日志存储服务。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本说明书实施例。
此外,本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书实施例中记载的一些实施例,对于本领域普通技术人员来讲,还可以根据这些附图获得其他的附图。
图1当前技术中所涉及的系统架构的示意图;
图2是本说明书实施例提供的一种业务日志存储方法的流程示意图;
图3为本说明书实施例所提供的一种示例性的部分清除的流程示意图;
图4是本说明书实施例提供的一种构造隐匿化业务日志的过程示意图;
图5为本说明书实施例中所提供的另一系统架构的示意图;
图6是本说明书实施例提供的一种业务日志存储装置的结构示意图;
图7示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图;
图8为本说明书实施例所提供的另一种业务日志存储方法的流程示意图。
具体实施方式
为了使本领域技术人员更好地理解本说明书实施例中的技术方案,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行详细地描述,显然,所描述的实施例仅仅是本说明书的一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于保护的范围。
首先需要说明的是,在当前的服务器架构中,数据库基础服务方可以是直接对接的客户端个人用户,也可以是由一些应用服务器对接客户端个人用户,而数据库基础服务则对接所述应用服务器。如图1所示,图1当前技术中所涉及的系统架构的示意图。应用服务器对于业务数据的基本操作(包括增删改查等等),在数据库基础服务方进行,产生的业务日志一般也存储于数据库基础服务提供方本地。在这种实施方式下,数据库系统需要分出一部分负荷去负责业务日志的存储和管理。
为了更好的解放出数据库基础服务方的负荷,提高交易系统的整体效率,以及,更好对业务日志进行存储和管理,本说明书实施例给出一种为数据库服务的数据库,即本说明书实施例中所涉及的数据库增强服务提供方,整体的架构如图5所示,图5为本说明书实施例中所提供的另一系统架构的示意图。其中的MySQL、PostgreSQL、MongoDB等等即为数据库基础服务提供方,这些数据库系统可以为常见的交易系统提供基础的增删改查等等操作的服务。同时,它们还会在各自本地存储有相应的对于这些操作的业务操作日志,其中的“binlog”、“xlog”以及“journallog”即为各种不同类型的数据库所产生的业务日志。业务操作日志中记载了数据库基础服务提供方对业务数据的操作记录。为这数据库基础服务提供方提供进一步服务的系统即为本说明书实施例所提供的数据库增强服务提供方,在该示意图中即为Ledger服务器。
以下结合附图,详细说明本说明书各实施例提供的技术方案。如图2所示,图2是本说明书实施例提供的一种业务日志存储方法的流程示意图,应用于包括数据库基础服务方和通过多个数据块存储业务日志的中心化的数据库增强服务提供方的系统中,该流程具体包括如下步骤:
S201,数据库基础服务方,发送待存储的业务日志至数据库增强服务提供方,所述业务日志用于记载数据库基础服务方对于业务数据的操作记录。
发送时,可以是同步发送,即每产生一个新的业务日志,即同时发送该业务日志至数据库增强服务提供方。也可以是异步发送的,例如,在每天的业务处理非高峰时期,发送业务日志。在异步发送时,每个业务日志中则应该包含有时间戳。业务日志中通常记载了对于数据库更新的操作方式,例如更改数据库表或者更改内容的SQL语句等等,可以反映出数据库基础服务方对于业务数据的操作记录。
S201,数据库增强服务提供方,接收待存储的业务日志,确定业务日志的哈希值;当达到预设的成块条件时,确定待写入数据块中的至少一个业务日志,生成包含数据块的哈希值和所述业务日志的第N个数据块。
所述预设的成块条件包括:待存储的业务日志数量达到数量阈值,例如,每接收到十个业务日志,生成一个新数据块,按各业务日志的时间戳的顺序将十个业务日志写入块中,该方式较为适合业务日志为异步发送;或者,距离上一次成块时刻的时间间隔达到时间阈值,例如,每隔5分钟,生成一个新数据块,将在这5分钟内接收到的业务日志,按照受理时间写入块中,这种方式较为适合业务日志为同步发送。显然,如果每隔一定时间,没有收到新的业务日志,则此时可以不必生成新的数据块。
此处的N指的是数据块的序号,换言之,在本说明书实施例中,数据块是以块链的形式,基于成块时间的顺序先后排列,具有很强的时序特征。其中,数据块的块高基于成块时间的先后顺序单调递增。块高可以是序号,此时第N个数据块的块高即为N;块高也可以其它方式生成,例如,将成块时间进行对称加密转换得到的大整型数据作为块高,大整型数据基于时间单调递增。
当N=1时,即此时的数据块为为初始数据块。初始数据块的哈希值和块高基于预设方式给定。例如,初始数据块中不包含业务日志,哈希值则为任一给定的哈希值,块高blknum=0;又例如,初始数据块的生成触发条件与其它数据块的触发条件一致,但是初始数据块的哈希值由对初始数据块中的所有业务日志的内容取哈希确定。
当N>1时,由于前一数据块的内容和哈希值已经确定,则此时,可以基于前一数据块(即第N-1个数据块)的哈希值生成当前数据块(第N个数据块)的哈希值,例如,一种可行的方式为,确定每一条将要写入第N个块中的业务日志的哈希值,按照在块中的排列顺序,生成一个默克尔树,将默克尔树的根哈希值和前一数据块的哈希值拼接在一起,再次采用哈希算法,生成当前块的哈希值。又例如,还可以按照块中业务日志的顺序进行拼接并取哈希得到整体业务日志的哈希值,拼接前一数据块的哈希值和整体业务日志的哈希值,并对拼接得到的字串进行哈希运算,生成第N个数据块的哈希值。
S205,数据库增强服务提供方,返回哈希值至数据库基础服务方,其中,所述哈希值包括所述业务日志的哈希值和/或业务日志所处块高的哈希值。
即,每写入一个业务日志入块,即返回一个业务日志对应的哈希值至数据库基础服务方,以及,还可以返回该业务日志所述的数据块的哈希值至数据库基础服务方。以便数据库基础服务方可以基于哈希值进行查询或者验证等等。
S207,数据库基础服务方,接收返回的业务日志的哈希值,并存储。
通过前述的数据块的生成方式,每一个数据块通过哈希值确定,数据块的哈希值由数据块中的业务日志的内容、顺序以及前一数据块的哈希值决定。用户可以随时基于数据块的哈希值对整条账本发起正确性验证,或者基于业务日志的哈希值进行存在性验证,或者对于任一数据块中任何内容(包括对于数据块中业务日志内容或者顺序的修改)的修改都会造成在验证时计算得到的数据块的哈希值和数据块生成时的哈希值不一致,而导致验证失败,从而实现了对于已经写入块中的业务日志的不可篡改。
通过生成包括一定数量的业务日志的数据块,并且记录下数据块生成时的哈希值,从而实现以数据块链的方式对业务日志进行中心化的存储。在这种存储方式下,每一数据块的哈希值依赖于前一数据块的哈希值以及自身所包含的业务日志的内容。数据库基础服务方可以基于上述存储形式随时查询自己的业务日志,以及可以依据业务数据的哈希值或者数据块的哈希值进行验证,保证了用户数据的完整性,提高用户体验。
在一种具体的实施方式下,数据库基础服务方可以基于预先建立的通信协议,发送待存储的业务日志至数据库增强服务提供方。即可以通过“明文”的方式发送业务操作日志至Ledger系统。此处的“明文”指的是Ledger系统可以理解或者部分理解各数据库所发送的业务操作日志。例如,某个数据库和Ledger系统通过预先制定通信协议,使得Ledger系统可以获知业务操作日志中的操作类型、操作业务对象等等,从而Ledger系统在成块时可以进一步的根据操作类型或者操作目标对象进行成块,以便各数据库系统进行更好的管理。在这种方式下,各数据库若需要进行对自身的查询或者统计(例如,统计对哪个业务对象的数据做了多少次清除操作),可以只需发送指令,具体的统计或者查询进程可以在Ledger系统端完成。
例如,任一数据库基础服务方发送的业务日志中携带ID,从而,数据库增强服务提供方可以为每一个数据库基础服务方生成一个专门的账本;又例如,任一数据库基础服务方发送的业务日志中携带业务ID,从而,数据库增强服务提供方可以为一个业务生成一个账本。
当然,各数据库基础服务提供方也可以通过“密文”的方式发送业务操作日志至Ledger系统。此处的“密文”指的是Ledger系统不能理解各数据库所发送的业务操作日志。进一步地,为了更好的保密,还可以对业务日志进行加密后进行发送,从而存储在数据库增强服务方的是加密业务日志。在这种方式下,各数据库则只能向Ledger系统进行已存储的业务操作日志的读取或者清除等等操作,具体的查询或者统计工作则需要在读取数据之后在数据库基础服务提供方本地执行。
由于上述业务日志被写入数据块中之后,即被不可篡改的存储在Ledger系统中,此时,若数据库基础服务方有需要,则可以发送获取业务日志的获取请求,所述获取请求中包含块高或者时间点,例如,发送请求指令GET(&v,timestmp),或者,GET(&v,blkheight),其中,timestmp即为数据库基础服务方指定的时间点,blkheight即为指定的块高。数据库增强服务提供方,则可以将块高或者时间点之前的生成数据块为目标数据块,返回所述目标数据块中所包含的业务日志。
如果数据库基础服务提供方和Ledger系统存在通信机制,例如,Ledger系统可以通过数据库基础服务提供方知道哪些业务日志是它的,那么此时,还可以仅仅返回目标数据块中该数据库基础服务提供方的业务日志,而不必返回目标数据块中全部的业务日志。
在对业务日志进行了存储之后,还可以再建立一些相关的索引信息,例如,由于在数据块中保存的是业务日志,而没有业务日志的哈希值。因此,为了可以方便的查找到任一业务日志,可以建立以业务日志的哈希值为键,以业务日志所处数据块的块高、业务日志在所处数据块中的偏移量为值的索引,进行存储。从而更可以方便的对业务日志进行查询。需要说明的是,上述索引信息的创建相对于成块可以是异步进行的,以及,上述索引信息可以发送备份给数据库基础服务方,从而数据库基础服务方也可以方便的根据索引对任一业务日志进行查询或者验证。
在查询过程中,可以基于数据库基础服务方输入的哈希值查询获取业务日志所处数据块的块高、业务日志在所处数据块中的偏移量或者业务日志全文,或者,查询获取数据块的哈希值对应的数据块的块高,并返回查询结果。
具体的查询方式可以通过查询指令来实现。查询指令中包含数据库基础服务方输入的待查询的哈希值即可。此处的哈希值可以是业务日志的哈希值或者数据块的哈希值,数据库服务提供方可以从数据块进行遍历查询,也可以从预先建立的索引中进行查询。
以下示例性列举几种本说明书实施例所提供的几种查询方式,数据库基础服务方输入查询指令,指令中可以有不同的参数由数据库基础服务方进行指定:
第一种,输入数据块的哈希值,数据库增强服务提供方进行查询,返回数据块中的所有数据明文;或者,输入业务日志的哈希值,数据库增强服务提供方返回业务日志明文,具体的,可以使用查询指令SELECT(khash,&v)实现,当数据库增强服务提供方接收到相应的查询指令时,即基于哈希值执行前述的查询逻辑以返回结果。
第二种,输入业务日志的哈希值,数据库增强服务提供方基于哈希值进行查询,返回业务日志所处的数据块的块高,以及,在该数据块中的偏移量,具体的,可以使用查询指令SELECT(khash,&v,FULL)实现;
第三种,输入数据块的哈希值,数据库增强服务提供方基于哈希值进行查询,返回块高。具体的,可以使用查询指令SELECT(khash,&v,BLK)来实现。
当然,也可能存在数据库基础服务方输入了一个哈希值,而数据库增强服务提供方,不能查询到相应的结果的情形。例如,数据库基础服务方输入了一个业务日志对应的哈希值,而服务方查询不到结果,那么此时,如果哈希值是正确无误的,数据库基础服务方可以合理的怀疑,该哈希所对应的业务日志已经发生了变动,有可能是被篡改,或者有可能发生了数据丢失。
进一步地,在存储过程中,数据库增强服务提供方还可以提供相应的服务平台的签名,具体包括如下方式:采用服务器私钥对所述哈希值进行加密,生成服务器对所述哈希值的私钥签名;返回所述私钥签名和哈希值至数据库基础服务方。从而数据库基础服务方,可以接收私钥签名和哈希值,采用对应的公钥解密所述哈希值的私钥签名,以进行验证,验证通过,则可以确认该哈希值是数据库增强服务提供方所承认的。具体的,数据库基础服务方,可以在添加指令中要求服务方提供该签名,以下为本说明书实施例所提供的示例性的返回签名的添加记录的指令:
APPEND(v,&khash,CERT):返回业务日志所对应的哈希值,以及,返回数据库增强服务提供方的签名证书。
当然,在本说明书实施例所提供的其它类型的数据库操作中,例如,在查询、清除、验证以及隐匿等等其它数据库操作中,也可以在返回结果中包括服务方签名证书。
在查询之外,数据库基础服务方还可以主动对数据库中已经存在的多个数据块发起验证,具体而言,可以由数据库基础服务方发起验证指令,验证指令中通过参数指定需要对哪些数据块发起验证,例如,可以通过哈希值或者块高指定一个数据块,对该数据块之前或者之后的多个数据块发起是否正确的验证;或者,通过哈希值指定一个业务日志,验证一个业务日志是否存在数据库中。验证得到的结果是一个“有”或者“无”,以及“正确”或者“不正确”这样的元数据。
对于数据块的验证方式可以是,从验证指令所指定的数据块开始,计算每一数据块的当前哈希值,并和数据块中已经包含的数据块的哈希值进行匹配,如果不完全相同,则验证失败。
以下示例性的给出了本说明书实施例所提供的几种验证指令方式:
第一种,输入哈希值,由哈希值确定数据块,对该数据块执行验证,得到验证结果,具体的,可以由验证指令VERIFY(‘khash’,&v)实现。
第二种,输入哈希值,由哈希值确定对应的数据块或者确定哈希值对应的业务日志所处的数据块,从确定的数据块开始往前验证直至初始数据块,具体的,可以通过验证指令VERIFY(‘khash’,&v,-1)实现,一般而言,初始块高为“0”或者“1”,因此,其中的-1也可以是其它小于初始块高的值。
第三种,输入哈希值,由哈希值确定对应的数据块,从确定的数据块开始往前验证指定个数的数据块,具体的,可以通过验证指令VERIFY(‘khash’,&v,blknum)实现。
第四种,输入块高和需要验证的数量,由块高对应的数据块开始往前验证指定数量的数据块,具体的,可以通过验证指令VERIFY(blkh,&v,blknum)实现。
验证时返回的结果是一个“是”或者“否”的元数据,如前所述,此时服务方还可以在这个过程中添加服务方的签名,签名的生成方式已在前文进行了描述。具体的,可以任意的验证指令末尾加入代表服务方签名的参数“CERT”,例如:VERIFY(‘khash’,&v,blknum,CERT),从而在返回结果中带有服务方签名。
在另一种实施方式下,如果数据块的内容中还包含有数据块的时间戳或者业务日志的时间戳,或者,数据库增强服务提供方还预先生成了有关数据参数和时间的索引时,例如,在成块时生成块高和成块时间戳的数据块时序索引、或者业务日志的哈希值和时间戳的业务日志时序索引、或者数据块的哈希值和成块时间的索引等等,那么此时,数据库增强服务提供方还可以提供相应的时间查询方式。进一步地,在生成的时序索引中,还可以按照时间戳顺序进行排列,从而可以方便的进行查询或者统计。
换言之,即可以从数据块中或者索引中,由时间值查询相应的块高或者哈希值,或者由哈希值或者块高查询相应的时间值,以下示例性的列举本说明书实施例所提供的几种基于时间的查询方式:
第一种,数据库基础服务方输入块高,数据库增强服务提供方查询块高对应的数据块的成块时间,具体的,可以由时间查询指令TIME(blknum,&v)实现。
第二种,数据库基础服务方输入哈希值,数据库增强服务提供方返回哈希值所对应的时间戳,这里的哈希值可以是数据块的哈希值,也可以是业务日志的哈希值,具体的,可以由时间查询指令TIME(‘khash’,&v)实现。
第三种,数据库基础服务方输入时间值,数据库增强服务提供方返回在该时间值之前最后一个数据块的块高,或者,返回在该时间值之前最后一条业务日志的哈希值以及所处的数据块的块高,具体的,可以由时间查询指令LTIME(‘timestamp’,&v)实现。
在本说明书实施例中,如果数据库基础服务方不再需要该业务日志的服务,则可以在结束服务前,进行业务日志的整体清除。数据库基础服务方输入自己的账本ID进行清除,例如,由清除指令PURGE(lgid)实现;或者,数据库基础服务方可以还输入一个时间长度,数据库增强服务提供方先将该账本归档,在到达该时间长度后,数据库增强服务提供方清除该账本,例如,由清除指令PURGE(lgid,day-archive)实现。
以及,由于数据库基础服务方的数据不断的增加,导致存储空间占用的越来越多,或者一些较长时间的历史数据,已经不再有价值此时,数据库服务方还可以基于用户的需求,对数据块进行相应的部分清除。部分清除时,可以基于块高或者时间点进行。
例如,数据库基础服务方指定账本ID以及块高,数据库增强服务提供方基于块高确定块高之前的数据块均为需要清除的数据块,然后清除这些确定需要清除的数据块,具体的,可以由清除指令PURGE(lgid,d-a,blkbound)实现。
又例如,据库基础服务方指定账本ID以及时间点,据库增强服务方基于时间点,确定在该时间点之前最后一个生成的数据块,将该数据块之前生成的数据块均确定为需要清除的数据块,然后清除这些确定需要清除的数据块,具体的,可以由清除指令PURGE(lgid,d-a,‘timestmp’)实现。
在执行部分清除之前,由于清除后的数据块链的第一个数据块的哈希值是基于前一数据块的哈希值生成的,此时,还需要生成一个伪初始数据块,伪初始数据块的哈希值等于被确定的需要清除的最后一个数据块的哈希值,这样,可以避免在以后进行验证时出现错误。最后一个数据块的哈希值可以从预先建立的索引中查询获取,也可以从初始数据块开始进行顺序计算得到该数据块的哈希值,或者从该数据块中查询获取。
新生成的伪初始数据块中的内容可以为空,也可以记载一些相应的备注,例如,生成的时间等等。但是,伪初始数据块的内容与伪初始数据块的哈希值无关。以及,数据库增强服务提供方还可以对该伪初始数据块进行签名。
此外,对于数据库基础服务方而言,还可以对部分清除的数据进行备份。基于此,在数据库基础服务方进行部分清除的过程中,还可以插入对于确认需要部分清除的数据进行验证。如图3所示,图3为本说明书实施例所提供的一种示例性的部分清除的流程示意图。在该示意图中,数据库基础服务方输入了时间点,具体可以首先查询得到在该时间点之前最近的数据块的生成时刻,然后得到该生成时刻对应的数据块的块高,生成伪初始数据块并签名,之后再执行了部分清除操作。
进一步地,数据库增强服务提供方还可以提供其它的一些数据库服务方式,例如:
在归档期间内,找回数据账本,通过找回指令RECALL(lgid)实现,此处的账本指的是包含了所有数据块的集合;
返回当前最后一个数据块的块高,通过指令GETHEIGHT(&v)实现;
返回用户账本ID,通过指令GETLEDGER(&v)实现等等。
此外,需要说明的是,在上述说明中提供了多种操作指令来实现本申请所提供的数据库服务方式。但是,操作指令的形式并不限于本说明书实施例所提出的形式,在实际中,对于数据的操作指令的形式可以是多种多样的,只需可以实现本申请所提出的服务方式即可。以及,查询指令本身只是提供了一个便于用户操作的外在形式,在数据库增强服务提供方接收指令并执行时仍依赖于各指令所对应的执行方式。
进一步地,在生成数据块后,数据库增强服务提供方还可以给出每个块相应的时间戳。例如,引入国家授时中心接口,在出块时采用可信的时间戳进行出块。从而,可以依赖该时间戳进行索引的建立。
在一种实施方式下,针对任一数据块而言,如果该块中的业务日志中有接收时间戳,那么可以根据接收时间戳对业务日志进行排序,分配给每个业务日志一个排序序号;或者可以按照接收到业务日志的顺序直接分配序号,并且在成块之后将序号重置,以便下一个数据块内部分配序号。
确定序号之后,即可以根据已经的确定每个业务日志的哈希值,拼接该序号和哈希值。具体而言,可以在哈希值的头部或者尾部加入指定长度的子串用来放置序号,生成业务日志的时序哈希字符串,然后,按照排序序号的顺序,建立包含数据块的成块时间戳和业务日志的时序哈希字符串对应关系的第一索引表。如表1所示,表1为本说明书实施例所提供的一种关于业务日志的第一索引表。在表1中,业务日志的哈希值的前6位插入了相应的序号字串,其中的“0x”用于标识接下来的是序号,其中的“0001”即为序号,“hash1”即为数据块中第一条数据的哈希值,左侧的时间为数据块的成块时间。在这种方式下,时间戳的有效位数完全保留。
表1
20xx-01-19 03:14:07.938576 |
0x0001Hash1 |
20xx-01-19 03:14:07.938576 |
0x0002Hash2 |
20xx-01-19 03:14:07.938576 |
0x0003Hash3 |
20xx-01-19 03:14:07.938576 |
…… |
在另一种实施方式下,同样的方式,针对任一数据块而言,如果该块中的业务日志中有接收时间戳,那么可以根据接收时间戳对业务日志进行排序,分配给每个业务日志一个排序序号;或者可以按照接收到业务日志的顺序直接分配序号,并且在成块之后将序号重置,以便下一个数据块内部分配序号。
此时,可以将成块时间戳中的最后指定位数进行消除,用于写入业务日志的序号。此外,还可以在索引中加入不会分配给业务日志的指定序号,用于存储成块时间戳与数据块的块高的对应关系,并写入索引。例如,业务日志的序号一般从1开始,则可以将序号“0”用于存储数据块的块高。如表2所示,表2为本说明书实施例所提供的一种关于业务日志的第二索引表。在表2中,左侧的成块时间的最后三位(假设一个块中存储的业务日志数量不超过1000)用于存储了业务日志的序号。
表2
20xx-01-19 03:14:07.938000 |
Blkheight |
20xx-01-19 03:14:07.938001 |
Hash1 |
20xx-01-19 03:14:07.938002 |
Hash2 |
20xx-01-19 03:14:07.938003 |
Hash3 |
20xx-01-19 03:14:07.938004 |
…… |
在这种实施方式下,虽然牺牲了几个时间有效位数,但是业务日志的哈希值可以直接读取,且可以通过指定的序号(即表2中的000)标识数据块的块高。
上述的索引创建时可以在出块的时间即刻创建,也可以是异步创建。索引本身可以用于一些查找或者统计操作,例如,统计某个时间段内的业务日志数量,避免从数据块内进行遍历计数,更为方便。
此外,在使用块链式的账本存储数据时,一个账本中通常包含有连续多个数据块。实际应用中,经常使用自然序号对数据块进行编号。例如,初始数据块的块高为1,后续每增加一个数据块,块高加1。基于此,本说明书实施例还提供一种块高创建方式,具体而言,确定数据块的成块时间,而后采用对称加密算法将所述成块时间其转换为整型数据,将所述整型数据作为所述数据块的块高,成块时间越早,整型数据越小。
具体而言,这里的整型可以是一个大整型数据,例如,一个13位的大整数。从而,由于大整型是基于时间对称加密得到的,从而在需要数据块的成块时间时,可以同样的对称解密获得成块时间。
例如,对于成块时间“20xx-01-19 03:14:07.938576”,在经过对称加密之后,可以转换为一个大整型“1547838847938”,由于整型数据随时间单调递增,因此,“1547838847938”。此时即可以做为该数据块的块高,用于标识该数据块。在本说明书,块高基于成块时间单调递增,这样即使采用了大整型数据,但是它们之间的仍然从小到大地,反映了各数据块之间的顺序。例如,若接下来一个数据块的成块时间为“20xx-01-19 03:16:07.235125”,则可以采用预设的对称加密算法将其转换为另一更大的大整型“1547838848125”。
基于此,还可以如前述方式中一样确定数据块中各业务日志的序号,并且拼接块高和序号,生成同时包含块高和序号的业务日志的时序信息,并建立业务日志的哈希值和时序信息的第三索引表。如表3所示,表3为本说明书实施例所提供的一种第三索引表。在该表中,左侧的大整型为包含块高和序号的时序信息,块高基于时间对称加密得到。在成块时间精确到毫秒级别的情形下,第三索引中在块高后引入3个十进制位来标识序号(即限定出块阈值为999),所以对于吞吐量的假定是百万级,已经能够满足任何实际交易场景。如果吞吐量更高,则只需在块高后引入更多的十进位制来标识序号即可。
表3
1547838847938000 |
1547838847938 |
1547838847938001 |
Hash1 |
1547838847938002 |
Hash2 |
1547838847938003 |
Hash3 |
1547838847938004 |
…… |
在实际应用中,出于商业机密等保密原因,有些业务日志中可能包含一些敏感信息,这些敏感信息如果被写入数据块中,则还需要对其进行隐匿。
由于在说明书实施例所提供的方案中,对于任一业务日志的修改或者清除同时会导致对其它数据块的验证出错,基于此,本说明书实施例还提供一种隐匿敏感数据的的方法,具体而言,核心技术手段是将数据块中需要被隐匿的信息所处的业务日志替换成该业务日志的哈希值。如此,既可以停止公开该敏感信息,又不会干扰到数据块系统的平稳运行。
具体而言,数据库基础服务方可以直接指定待隐匿信息的位置,或者,在实际应用中,数据库基础服务方也可以发出携带位置信息的隐匿信息指令。这里的位置信息包括数据块块高、业务日志在块高中的偏移量、待隐匿信息在业务日志中的偏移量、待隐匿信息的长度等等。
数据库增强服务提供方,接收隐匿信息指令,由所述位置信息确定待隐匿信息,确定所述待隐匿信息所处的业务日志的哈希值;将所述待隐匿信息进行替换或者清除,生成隐匿化业务日志,所述隐匿化业务日志中包括待隐匿信息所处的业务日志的哈希值。
例如,一种示例性的隐匿信息指令可以是DELETE(blkheight,txoff),在这条指令下,隐匿的是由指定块高blkheight和指定偏移量txoff所对应的一条业务日志;
又例如,另一种示例性的隐匿信息指令可以是DELETE(blkheight,txoff,offset,length),在这条指令下,由块高blkheight和偏移量txoff确定一条业务日志,隐匿该业务日志中指定的offset处开始长度为length所确定的信息。
数据库增强服务提供方,对隐匿信息进行替换或者清除后得到的信息,已经不再作为业务日志使用,可以称为备注信息。在隐匿信息的过程中,一种可行的方式为,确定待隐匿信息所处的业务日志的哈希值,将预设的前标记字符拼接到所述哈希值的首部,将预设的后标记字符拼接到所述哈希值的尾部,并且,将备注信息拼接到所述后标记字符的尾部,然后,将所述前标记字符、所述交易哈希、所述后标记字符以及所述备注信息拼接成的数据确定为所述隐匿化业务日志。如图4所示,图4是本说明书实施例提供的一种构造隐匿化业务日志的过程示意图。
需要说明的是,上述的前标记字符与后标记字符可以根据实际需要进行指定。例如,所述前标记字符可以为“0E”,所述后标记字符可以为“0F”。上述的前标记字符的作用是,当以后进行验证时需要读取该业务日志时,那么,此时前标记字符向节点透露出信息:“该存储位置所存储的不是业务日志的明文内容,而是业务日志的哈希值”。此时,则可以直接读取该哈希值进行验证。而需要读取相应的备注信息时,则可以从后标记字符“0F”开始进行读取,在隐匿了敏感信息后,备注信息中内容可以与隐匿前的业务日志内容基本相同,也可以是完全为空(即整条业务日志的内容完全隐匿)。
此外,需要说明的是,对于历史业务日志的隐匿是一项比较严格的操作。其往往象征某些触发法律法规或者违背道德的信息公开,也往往是在多方调节或者审判之后得出需要对信息进行强制处理的结论。因此,在执行上述清除操作时,一种可行的方式为:清除操作需要一定的签名权重。
例如,对于一项数据库基础服务方正常发出的操作指令,后台默认签名权重为30,而数据库增强服务提供方的签名权重则为60,法院等国家强行执行机构发出操作指令的签名权重为120,而一个清除操作所需的签名权重预设为100。一个操作的执行权重可以是参与方的签名权重之和,一般而言,可以设定参与方不超过2。在这种实施方式下,至少需要两个和业务日志有关的权威方(例如交易系统方和数据库服务方)的数字签名才能执行。即,需要交易系统方发起清除指令并签名,数据库服务方接收到清除指令并签名才可进行清除。而由数据库基础服务方发起的隐匿指令会因为签名权重不够而不会执行。
对应的,本说明书实施例还提供一种业务日志存储系统,包括数据库基础服务方和通过多个数据块存储业务日志的中心化的数据库增强服务提供方,在所述系统中,
数据库基础服务方,发送待存储的业务日志至数据库增强服务提供方,所述业务日志用于记载数据库基础服务方对于业务数据的操作记录;
数据库增强服务提供方,接收待存储的业务日志,确定业务日志的哈希值;当达到预设的成块条件时,确定待写入数据块中的至少一个业务日志,生成包含数据块的哈希值和所述业务日志的第N个数据块,具体包括:
当N=1时,初始数据块的哈希值和块高基于预设方式给定;当N>1时,根据待写入数据块中的业务日志的内容和第N-1个数据块的哈希值确定第N个数据块的哈希值,生成包含第N个数据块的哈希值和所述业务日志的第N个数据块,其中,数据块的块高基于成块时间的先后顺序单调递增;
数据库增强服务提供方,返回哈希值至数据库基础服务方,其中,所述哈希值包括所述业务日志的哈希值和/或业务日志所处块高的哈希值;
数据库基础服务方,接收返回的业务日志的哈希值,并存储。
第二方面,本说明书实施例还提供一种业务日志存储方法,应用通过多个数据块存储业务日志的中心化的数据库增强服务提供方,如图8所示,图8为本说明书实施例所提供的另一种业务日志存储方法的流程示意图,所述方法包括:
S801,接收待存储的业务日志,确定业务日志的哈希值;
S803,当达到预设的成块条件时,确定待写入数据块中的至少一个业务日志,生成包含数据块的哈希值和所述业务日志的第N个数据块,具体包括:
当N=1时,初始数据块的哈希值和块高基于预设方式给定;
当N>1时,根据待写入数据块中的业务日志的内容和第N-1个数据块的哈希值确定第N个数据块的哈希值,生成包含第N个数据块的哈希值和所述业务日志的第N个数据块,其中,数据块的块高基于成块时间的先后顺序单调递增。
与第二方面对应的,本说明书实施例还提供一种业务日志存储装置,应用于通过多个数据块存储数据的中心化的数据库服务提供方中,如图6所示,图6是本说明书实施例提供的一种业务日志存储装置的结构示意图,包括:
接收模块601,接收待存储的业务日志,确定各业务日志的哈希值;
生成模块603,当达到预设的成块条件时,确定待写入数据块中的各业务日志,生成包含数据块的哈希值和业务日志的第N个数据块,具体包括:
当N=1时,初始数据块的哈希值和块高基于预设方式给定;
当N>1时,根据待写入数据块中的各业务日志和第N-1个数据块的哈希值确定第N个数据块的哈希值,生成包含第N个数据块的哈希值和各业务日志的第N个数据块,其中,数据块的块高基于成块时间的先后顺序单调递增。
本说明书实施例还提供一种计算机设备,其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,处理器执行所述程序时实现图8所示的业务日志存储方法。
图7示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图,该设备可以包括:处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。
处理器1010可以采用通用的CPU(Central Processing Unit,中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本说明书实施例所提供的技术方案。
存储器1020可以采用ROM(Read Only Memory,只读存储器)、RAM(Random AccessMemory,随机存取存储器)、静态存储设备,动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序,在通过软件或者固件来实现本说明书实施例所提供的技术方案时,相关的程序代码保存在存储器1020中,并由处理器1010来调用执行。
输入/输出接口1030用于连接输入/输出模块,以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出),也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等,输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口1040用于连接通信模块(图中未示出),以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线1050包括一通路,在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。
需要说明的是,尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050,但是在具体实施过程中,该设备还可以包括实现正常运行所必需的其他组件。此外,本领域的技术人员可以理解的是,上述设备中也可以仅包含实现本说明书实施例方案所必需的组件,而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现图8所示的业务日志存储方法。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、方法、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于方法实施例而言,由于其基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。以上所描述的方法实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本说明书实施例原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本说明书实施例的保护范围。