一、 生产背景

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.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)。

数据增量包括应用数据的变更，以及操作类型、操作时间等元数据。

可以发现，QLDB 参考区块链，保证所记录的“账目”是不可修改的：

1.插入操作的日志，其 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 在处理历史数据时更加富有优势。