AWS re: Invent 2018 上，AWS CEO Andy Jassy 公布了 QLDB – Quantum Ledger Database(量子账本数据库)[1]。援用 Amazon 对于 QLDB 的 FAQ[2]，QLDB 是一款特型数据库，它可能提供利用数据全副的历史变迁。

QLDB 与咱们之前提出的 TDSQL 全时态数据库有些类似，本文剖析比拟 QLDB 和 TDSQL 全时态数据库的异同。

一、生产背景

1.1 QLDB 产生背景
Andy Jassy 提到，QLDB 其实曾经在 AWS 中稳固运行了几年，为 EC2、S3 等一批大规模服务提供反对，QLDB 将所有的数据变动记录下来，以简化操作、计费等。

据 Andy Jassy 说，通过与数百位区块链用户沟通，AWS 发现用户最迫切的需要有二：中心化可信账本 (ledgers with centralized trust) 和去中心化可信事务(transactions with de-centralized trust，本文不探讨)。

供应链跟踪、医保记录、机动车治理、集体履历等利用有追溯数据变动的需要，用于记录这些数据变动的称为账本(ledgers)，账本须要牢靠、通明、不可更改、加密认证，QLDB 即表演中心化可信账本的角色。

可见，此次 AWS 对外公布 QLDB，是要将其作为进军区块链的一大利器(另一为 Amazon Managed Blockchain[3]，本文不探讨)。

1.2 TDSQL 全时态数据库的产生背景
TDSQL 全时态数据库产生于腾讯计费业务。据统计，腾讯计费平台部每天须要对 363 亿独立账户准确无误地解决，在线交易要求极高的可靠性和准确性，因而，交易监控性能至关重要。

交易监控包含对账、审计、风控等伎俩，以对账为例，通过比对一段时间内的账户数据变动和流水数据来定位异样交易。

受限于传统关系型数据模型和现有数据库产品的实现，交易监控无奈做到实时和准确。再以对账为例，业界通用做法是：账户表按日分表，业务低谷时在当天账户表、前天账户表、流水表上做计算。此办法的问题在于只能在“天”的粒度上对账，定位具体的问题交易还要借助其余伎俩。要细化对账粒度，准确到异样交易，就须要记录每一笔交易导致的数据变动。

另外，银监会规定金融行业的重要数据须保留规定年限[4]，深圳市互联网金融协会要求账户信息、资金流水、交易数据等须保留超过 15 年[5]。

出于以上需要和规定，咱们设计了 TDSQL 全时态数据库，以治理历史 (后续在全时态模型下称为历史态数据) 数据，包含了历史数据的存储、计算。

1.3 小结
QLDB 和 TDSQL 全时态数据库都诞生于业务、服务于业务：QLDB 源于 AWS EC2，S3 等的外部反对，可作为区块链中心化账本。

TDSQL 全时态数据库源于互联网在线交易监控，初衷是提供更精密的监控粒度，但利用场景不限于金融、计费、交易，任何有追溯过往需要的场景均实用。

然而，二者共同之处，在于提供历史数据的生命周期的治理。这表明，腾讯和 Amazon 都意识到了历史数据的价值，并在生产实践中加以治理和应用。

2. 数据模型

2.1 QLDB 数据模型
2.1.1 QLDB 的“账本”

由 Current、History 和 Journal 组成：

1.Current：用户的以后数据，比方，以后银行账户的状态；

2.History：用户数据的历史版本，比方，历史上的银行账户的状态；

3.Journal：只可追加、无奈批改的日志，存储序列化的、可明码验证的数据变动，比方，银行账户的交易记录。

2.1.2 QLDB 文档数据模型
QLDB 以文档数据模型保护以后和历史的利用数据，图 2 -2(援用自 ref[6]) 是一例，能够看到，QLDB 反对嵌套的数据类型，与传统关系数据模型相比，可能集中欠缺地存储、体现数据。

Journal 中日志由两局部组成：本次数据增量，SHA-256 哈希值 H(T)。

以图 2 -3(援用自 ref[6])为例，能够看到，数据增量包含利用数据的变更，以及操作类型、操作工夫等元数据。

能够发现，QLDB 参考区块链，保障所记录的“账目”是不可批改的：

1. 图 2 - 3 所示，插入操作的日志，其 HASH 值为数据增量的 SHA-256 的值；

2. 更新或删除操作的日志，如图 2 - 4 所示，其 HASH 值由两局部组成，一是本条日志的数据增量，二是上一条日志的 HASH 值，如此形成一 HASH 链。

此 HASH 链维系了一个数据项的历史操作和数据增量。一旦 HASH 链中某一条日志的数据被批改，那么该日志的 HASH 值会发生变化，之后的日志就无奈连贯到这条日志，这种机制保障了数据一旦写入就无奈篡改，做到了历史产生不可批改。

于是 QLDB 的“账目”是不可批改、加密认证的。

此处，咱们简略比照 QLDB 和腾讯区块链 TBaaS[7]采纳的 Hyperledger[8]。与 QLDB 不同，Hyperledger 是去中心化的区块链账本，每个参与者保留一个区块链账本的正本，所有参与者通过合作独特保护着账本。

4.1 QLDB：How it works 节介绍 QLDB 文档数据模型如何工作。

2.2 TDSQL 全时态数据模型
TDSQL 全时态数据是具备全态个性和时态属性的数据的统称。

2.2.1 TDSQL 数据全态
数据在其变迁过程中，处于不同状态，TDSQL 提出将数据状态划分为 3 个阶段：

1. 以后态(Current State)：数据项的最新版本，是处于以后阶段的数据。封闭和 MVCC 机制下，能被读取到的最新版本的数据为以后态数据。
2. 历史态(Historical State)：数据在历史上的一个状态，其值是旧值，而非以后值。一个数据项能够有多个历史态，反映数据状态的变迁过程。处于历史态的数据，只能被读取而不能再被批改或删除。

封闭机制下，更新操作产生后，原更新前的数据版本处于历史态。MVCC 机制下，以后沉闷事务列表中最小的事务之前的事务产生的版本处于历史态。

3. 过渡态(Transitional State)：既非数据项最新版本，亦非历史态版本，处于从以后态向历史态转变的中间状态。基于封闭实现并发管制的零碎中不存在过渡态。

MVCC 机制下，被读取的版本上有最新的相干事务应用，因最新的事务批改了数据项的值，其最新值处于以后态，那么被读取到的版本绝对于最新值成为历史。

而读取此版本的事务还是沉闷的，此版本还不处于历史态。

这样一种，从以后态向历史态过渡的数据，称为过渡态数据。

数据的以后态、历史态、过渡态，合称为数据的全态。

能够看到，QLDB 有历史数据，但没有把数据的生命周期加以对立模型化治理。

2.2.2 TDSQL 数据时态
时态，即时态数据库概念中的时态。

根据时态数据库实践，参考 SQL:2011 时态相干准则，TDSQL 提供无效工夫和事务工夫的反对。

无效工夫用来示意，数据所表白的事实在事实世界真实有效的这段时间。比方，小明在 2000-9- 1 到 2003-7-30 上中学，那么“小明上中学”这个事实的无效工夫为 2000-9- 1 到 2003-7-30。无效工夫可用于保险在保、食品保质期等事实。

事务工夫用来示意，数据在数据库系统中发生变化的工夫。比方，“小明在 2000-9- 1 到 2003-7-30 上中学”这条数据在 2003-9- 1 写入学籍管理系统，2003-9- 1 是此数据入库工夫。事务工夫维系了数据生命周期的工夫线。

相比下，QLDB 并没有提供时态反对。

可参考 ref[9]理解更多 TDSQL 时态内容。

2.2.3 TDSQL 全时态
数据全态和数据时态合称为 TDSQL 全时态，全时态刻画了数据齐全的生命周期。TDSQL 在全时态概念的根底上，进一步提出了全时态数据模型的概念，有根底的全时态 (全态 + 双时态) 数据结构，更有基于全时态的丰盛的语义操作。在这一点上，还没有看到 QLDB 有更多的信息展现。

另外，数据在变迁过程中所经验的操作、操作者、操作产生工夫等元信息都被维系下来，咱们将此称为数据血统。在 TDSQL 中，数据每一个版本、每一次操作都由血统保护起来，如此造成更残缺的生命周期，此生命周期能够如此表述，即 TDSQL 可能帮忙用户理解到：什么人在什么工夫做了什么事件，数据项数据变迁的事件是什么。

2.3 小结
QLDB 和 TDSQL 全时态数据库的共同点是，二者都对数据状态做出辨别，QLDB 把数据分为以后和历史两个状态，TDSQL 提出全态的概念。

QLDB 采纳文档数据模型，相比于传统的关系数据模型，具备反对数据类型更多、灵活性高的特点，关系型数据库利用和非关系型数据库利用都可与之对接，代价是模型不同的数据库系统间数据迁徙的复杂性。

TDSQL 全时态数据模型是基于关系数据模型的，并蕴含数据状态和时态两个概念，具备更丰盛的计算能力。作为全时态数据模型的子集，大量现行的关系型数据库利用能够轻松迁徙。齐备的全时态数据模型使得 TDSQL 在解决历史数据时更加富裕劣势。

3. 架构

3.1 QLDB 之于 Amazon 数据库生态
Andy Jassy 展现了 Amazon 的 database freedom，如图 3 -1(援用自 ref[1])，Amazon 提供诸多数据解决方案，涵盖关系型、K-V、内存等存储，并蕴含图、时序、账本等特型数据库，QLDB 即特型数据库之一。

QLDB 作为 Amazon 整个数据库服务生态的一个成员，与 RDS、DynamoDB、ElasticCache 等产品彼此独立但严密单干，相互补充独特形成 database freedom。

QLDB 如何与其余产品合作，还需等 Amazon 凋谢更多材料。

3.2 TDSQL 全时态数据库的 HTAC 架构
图 3 - 2 展现了 TDSQL 全时态数据库的 HTAC 架构，HTAC 基于 master-slave 架构，此架构下全态数据管理形式为：

● 主节点 Current 寄存以后数据，从节点 History 寄存历史数据；

● 主节点的更新操作引发：

■ 以后数据的版本推动；

■ 数据的旧版本同步至从节点，追加旧版本到历史库；

● Proxy 路由 TP 申请到主节点，操作以后数据；路由 AP 申请到从节点，执行全态查问。

Master-Slave 是目前宽泛采纳的高可用计划之一，HTAC 架构基于此，适用性宽泛。并且，在现有的数据库服务中减少一备即可承载历史，防止了从新设计部署数据库服务。

主、备在物理上别离寄存以后、历史数据，保障数据安全。主节点数据呈现问题时，能够应用该从节点的数据疾速复原。另外，以后和历史数据物理上的隔离，导致 TP 和 AP 服务切割，因而能够针对 AP 业务针对优化此从节点。

在主备间传输的历史数据，是原生数据，而非日志。其劣势在于，防止本地封装数据，节约计算开销，尽可能升高对业务零碎的影响；防止异地解析日志，同样节约计算开销，使得历史数据疾速落地存储，实时性高。

3.3 小结
QLDB 是 Amazon 数据库生态中的一环，作为 RDS 等“账本”的存在，事务在 RDS 上执行，在 QLDB 上“入账”。

TDSQL 全时态数据库采纳基于 Master-Slave 的 HTAC 架构，在须要追溯历史的数据库实例上减少一备，作为历史数据的存储即可，防止了额定的零碎设计和部署，而且数据安全失去进一步保障，疾速复原触手可及。另外，节点间传输原生数据格式，具备对业务零碎影响低、历史数据落地快、实时性高的劣势。

利用场景

QLDB 和 TDSQL 全时态数据库都诞生于外部计费、交易系统，都维系了数据的全生命周期，这样看来，QLDB 和 TDSQL 实用的场景应该是类似的。

QLDB 定位是区块链中心化可信账本，可见其发力点次要在区块链利用上，比方 ref[6]提到的机动车治理、商品生产供应线、职业生涯等。当然，QLDB 须要在 Amazon 的数据库生态当中发挥作用。

TDSQL 全时态数据库并非针对某一利用方向所设计，所以有全时态数据管理需要的利用都能够应用，比方个人账户零碎、服务器治理、职业生涯等。因为 TDSQL 全时态数据库基于关系数据模型设计，现有关系型数据库利用都能够方便使用。