关于账本数据库:你想知道的这里都有

简介: 关于账本数据库:你想知道的这里都有
💕前言:十二月份出个openGuass集合专栏,带领大家浅浅的认识一下国产数据库吧💕

1. 什么是账本数据库


区块链大家想必都耳熟能详,比特币、以太坊甚至狗狗币等代币,作为区块链的代名词,不仅牵动着某些人的账户盈亏,甚至影响着市面的显卡、硬盘价格。但是作为数据库相关的技术人员或者爱好者,对这一新技术,我们更多的是关系其核心技术点。


区块链作为一种分布式账本技术,克服了传统集中式账本的存储效率低、可信度低、易受单点攻击的劣势,从技术上保证了其具有分布式共享、多方共识、不可篡改和可追溯的特点。


那么区块链这么好,我们能用它来替代数据库吗?答案当然是NO!因为区块链往往有着交易性能低下,查询不便等诸多弊端。比特币系统仅支持每秒处理7笔交易,如果用它来承担主要的金融交易,效率自然是十分低下的。业界往往采用数据库来提高区块链的数据存储、检索能力。我们不妨换个角度,利用openGauss数据库天然具有的高性能、高可靠、高安全等优势,从openGauss出发,融入一些区块链的密码学防篡改、多方共识等技术,来提高数据库自身的防篡改、可追溯能力。防篡改账本数据库的idea应运而生。


区块链从基础架构模型上讲,通常被分为七层:


应用层


查询层


合约层


激励层


共识层


网络层


数据层


每一层的详细的技术点如下图所示:

1.png

图 1 区块链基础架构模型


数据库吸纳区块链防篡改的能力,首先想到的就是从区块链技术的最底层:数据层出发,让数据库提供数据的校验信息记录以及数据的篡改校验的能力,保证数据库在处理敏感信息时能够忠实的记录每一笔交易造成的数据更改,形成一个忠实、完整的数据变更“账本”。我们本次要介绍的openGauss账本数据库,即是在openGauss内核中植入了在数据修改时,对数据的变更操作进行记录这一功能,保证整个数据链路可查询、可溯源;同时提供高效的篡改校验接口,提供给上层的应用系统或者多个参与方之间互相校验数据的一致性。之后,我们将详细介绍账本数据库的实现原理以及其对openGauss的改造。


2. openGauss账本数据库原理剖析

1.png

图 2 账本数据库新增模块


客户端发送SQL对数据库中数据进行修改时,要经过通信模块的接收,解析模块的处理,转成解析树,然后经过优化生成执行计划。执行模块拿到执行计划,会调用存储层接口对数据进行修改。如上图所示,我们在数据的修改过程中,增加了篡改校验信息的记录;同时,提供了篡改校验模块,供用户调用接口执行校验。篡改信息记录和篡改校验的基础是我们针对数据库增、删、改操作设计的篡改校验信息。下面我们针对新增的篡改校验信息进行介绍。


2.1 防篡改用户表

1.png

图 3 防篡改用户表结构


在账本数据库特性中,我们使用schema级别进行防篡改表和普通表的隔离。在防篡改schema中的表,具有校验信息,且每次涉及到增、删、改的操作均会记录相应的数据变化以及操作的语句,我们称这些表为防篡改表。而普通的schema中的表,我们称其为普通表。


防篡改表有如图 3所示的结构。在创建防篡改表时,系统会增加一行hash列,该列在发生数据插入或者数据修改时,都会实时计算数据的摘要。数据与摘要存在一个tuple中,密不可分。由hash函数的单向性,我们将每一行的摘要,作为该行数据在摘要空间的逻辑表示。


2.2 用户历史表

1.png

图 4 用户历史表结构


用户历史表结构见上图,主要包含四列:xid、hash_ins、hash_del、pre_hash。用户历史表的每一行对应着用户表的每一次行级数据更改,其中xid记录数据更改时的xid号,代表着操作进行的逻辑时间顺序。hash_ins记录INSERT或者UPDATE操作插入的数据行的hash值,hash_del记录着DELETE或者UPDATE删除数据行的hash值。同时,hash_ins和hash_del是否为空,代表着INSERT、DELETE、UPDATE三种不同的操作类型,其对应关系如下表。

hash_ins

hash_del

Insert

√(插入数据hash)

--

Delete

--

√(删除数据hash)

Update

√(新数据hash)

√(删除前数据hash)

pre_hash将历史表的当前行数据和上一行的pre_hash数据进行拼接,生成当前用户历史表的数据整体摘要,计算公式如下:


1.png


这里i代表用户历史表的第i行,rowdatai为第i行xid||hash_ins||hash_del拼接的数据。


在校验用户历史表的完整性时,通过使用rowdata数据从前往后依次计算pre_hash值,并与表中的pre_hash进行比对,如果数据不一致,则说明用户历史表的完整性被破坏。


2.3 全局区块表结构

1.png

图 5 全局区块表结构


全局区块表结构见上图,表中每一行对应一次防篡改表修改行为,作为一个区块保存。全局区块表主要包括三部分内容:区块信息主要保存了区块相关的标记信息,包括区块号、时间戳。操作信息包括了用户对防篡改数据表的操作信息,包括数据库名、用户名、表名等标识信息,以及对应的SQL语句。校验信息保存用于一致性或完整性校验的hash信息,包括表级hash(rel_hash)、全局hash(global_hash)。


2.4 篡改校验算法

1.png

图6.验信息生成

用户在调用篡改校验接口时,系统可以并行的使用防篡改用户表生成表级的总校验信息;使用用户表对应的历史表中的记录,生成变更记录整体的校验信息。然后通过比较生成的两个校验信息是否一致,来判断数据与操作是否一致。如果不一致,则说明发生了绕过系统记录的修改数据行为,即篡改行为。


通过防篡改用户表中的行级校验信息生成表级校验的过程如图 6 所示。在校验时,会扫描表中的数据,获取每一行中的校验信息,并使用行校验信息对行数据进行校验。在扫描完整体的行校信息的过程中,可以通过内置的可交换校验信息聚合算法,不断生成当前已经扫描的数据的整体校验信息。由于信息聚合算法的可交换性,这一过程可以完全并行执行。


通过用户历史表生成变更记录总体的校验信息如图 7 所示。通过我们设计的用户历史表的结构,其hash_ins列中的非空元素代表了所有操作导致的数据校验信息的增加,hash_del列中的非空元素则代表了校验数据减少。我们通过对两列元素做差集,得到剩余的校验信息的集合。然后利用可交换校验信息聚合算法得到用户历史表中记录操作造成的变更记录整体的校验信息。这一过程,由于聚合算法的可交换性,可以对每行先进行hash_ins – hash_del,然后在扫描的时候不断叠加生成。这里,变更记录整体校验信息的生成也是完全可以并行的。

1.png

图 7 用户历史表校验信息生成


3. openGauss账本数据库发展展望


账本数据库作为openGauss防篡改数据的基础,目前支持了数据库内校验信息的记录以及提供高性能校验接口。提供了区块链技术层次中存储层的部分功能。为了实现防篡改, 我们还需要增加多个数据库间的高性能远程执行能力,以及提供可插拔的高性能多方共识协议,这样才能形成完整的openGauss多方可信防篡改能力。在数据库融合区块链的领域,openGauss会不断进化,为大家带来更加易用、更加高效的防篡改数据库。

相关文章
|
7月前
|
存储 监控 安全
数据库数据的保密性
【4月更文挑战第9天】数据库保密性关键在于限制未授权访问和保护数据不泄露。措施包括访问控制、加密、数据脱敏、备份恢复、审计监控及安全配置等,确保数据安全和用户隐私。
146 2
|
7月前
|
大数据 数据库
数据库之分布式事务
数据库之分布式事务
49 0
|
7月前
|
SQL NoSQL 关系型数据库
数据库解决方案
【5月更文挑战第12天】数据库解决方案。
100 4
|
存储 安全 数据库
商品存入数据库怎么保证数据库的数据安全
商品存入数据库怎么保证数据库的数据安全
100 0
|
7月前
|
存储 NoSQL 关系型数据库
现代数据库技术及其应用
本文介绍了现代数据库技术的发展与应用。从关系型数据库到NoSQL数据库,再到分布式数据库,不同的技术在满足不同需求的同时也带来了新的挑战和机遇。我们将探讨这些数据库技术的特点、优势和适用场景,并提供一些实际应用案例。
|
存储 安全 区块链
区块链101:区块链和数据库的区别是什么?
区块链101:区块链和数据库的区别是什么?
|
安全 Java 关系型数据库
集中式整合之使用数据库数据实现认证|学习笔记
快速学习集中式整合之使用数据库数据实现认证
集中式整合之使用数据库数据实现认证|学习笔记
|
SQL 存储 关系型数据库
17账本数据库
17账本数据库
168 0
|
存储 SQL NoSQL
分布式系统 in 2010s :存储之数据库篇
回看这几年,分布式系统领域出现了很多新东西,特别是云和 AI 的崛起,让这个过去其实不太 sexy 的领域一下到了风口浪尖,在这期间诞生了很多新技术、新思想,让这个古老的领域重新焕发生机。站在 2010s 的尾巴上,我想跟大家一起聊聊分布式系统令人振奋的进化路程,以及谈一些对 2020s 的大胆猜想。 无论哪个时代,存储都是一个重要的话题,今天先聊聊数据库。在过去的几年,数据库技术上出现了几个很明显的趋势。 存储和计算进一步分离 我印象中最早的存储-计算分离的尝试是 Snowflake,Snowflake 团队在 2016 年发表的论文《The Snowflake Elastic Data
182 0
|
存储 算法 分布式数据库