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的“账本”

图2-1(引用自ref[6])展示了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架构，在需要追溯历史的数据库实例上增加一备，作为历史数据的存储即可，避免了额外的系统设计和部署，而且数据安全得到进一步保障，快速恢复触手可及。另外，节点间传输原生数据格式，具有对业务系统影响低、历史数据落地快、实时性高的优势。

4.功能

4.1 QLDB：How it works

根据ref[2] FAQ，QLDB支持事务并满足ACID，并且提供SQL-like的接口。以机动车管理系统为例，图4-1(引用自ref[6])为QLDB的插入操作，用户使用SQL-like风格的语句，插入过程如下：

1)首先写Journal，其数据为文档数据格式，并计算其SHA-256哈希值也存放在日志中；

2)写Journal完成，更新Current和History。(图中以二维表的方式展现数据，但QLDB采用文档数据模型)

图4-2(引用自ref[6])和图4-3(引用自ref[6])分别为QLDB更新和删除操作，类似的，用户使用SQL-like语句，更新和删除过程先追加写Journal，随后更新Current和History。本质上，这种操作方式，就是“流水日志”，所以历史数据被“Append”到历史库中。而TDSQL天然利用了MVCC中多版本技术，历史数据自然以原生格式沉淀在数据库系统中，没有封装为流水记录、没有重新插入到历史表中的过程，非常自然和流畅地解决了历史数据存储的问题。

更多语义、操作、使用方法等，待Amazon开放更多资料。

4.2 TDSQL全时态数据库功能

我们将TDSQL全时态数据库的操作称为全时态操作，全时态操作是传统关系操作的超集。除传统关系操作外，全时态操作还提供时态操作和全态操作。

4.2.1 时态操作

TDSQL提供有效时间和事务时间两种时态语义和操作。

有效时间操作：

1.有效时间点查询、有效时间段查询；

2.有效时间区间更新、有效时间区间删除。

事务时间操作：

1.获取某时间点可见的数据；

2.获取某时间段可见的数据集合；

3.获取某事务操作的数据版本；

4.获取事务状态。

ref[10]详细介绍了时态操作的语法语义、内部机制。

4.2.2 全态操作

根据作用域不同，全态操作划分为：

1.当前态数据读取，作用域为当前态数据，即传统关系型数据库操作的作用域；

2.历史态数据读取，作用域为历史态数据，只获取历史数据；

3.全态数据读取，作用域为任意状态数据。

在全态操作中，我们模糊过渡态这一概念。

在以MVCC作为并发控制机制的数据库系统中，传统数据读取操作的作用域为当前态和过渡态。读取到最新的数据版本即当前态，或如图4-4 a例，读已提交(或更高)隔离级别下，事务T1 read获取数据为T2 write之前的值，即过渡态。

历史态数据读取中，获取过去某时段的数据，很可能取到过渡态数据，如图4-4 b。

因此，过渡态数据的读取融于当前态数据读取和历史态数据读取中，根据不同查询要求和数据的可见性决定过渡态数据查出与否。

4.3 小结

Amazon目前开放的资料显示，QLDB支持ACID事务，提供SQL-like接口。

TDSQL全时态数据库的功能是完全适用关系型数据库的SQL操作，没有自定义一套新接口，方便了用户的使用。

TDSQL还在时态维度上提供有效时间和事务时间操作，在状态维度上提供全态数据获取。

5.应用场景

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

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

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

6.总结

QLDB和TDSQL表现出Amazon和腾讯认识到了历史数据的价值，引用TDSQL全时态数据库的核心价值观--历史数据富有价值，核心理念--为数据赋能[11]。

下面以表格形式简要总结QLDB和TDSQL全时态数据库的异同。TDSQL和其他类似产品的对比，请参考ref[9]。

	Quantum Ledger Database	TDSQL全时态数据库
产生背景	业务出发
产生背景	1. AWS内部服务2. 区块链中心化可信账本	1. 在线交易监控2. 金融数据留存
数据模型	1.数据分为当前和历史2.保留数据的全部历史	1.数据分为当前态、过渡态、历史态2.双时态支持
数据模型	文档数据模型： 1.数据类型多，灵活性高2.关系型/非关系型均可迁移	全时态数据模型：1.维护数据血统和完全的生命周期2.丰富的计算功能3.关系型应用轻松迁移4.非关系型应用迁移相对复杂
架构	Amazon数据库生态的“账本”： 1.业务系统使用，需迁移到Amazon数据库服务2.业务系统使用，需接入新系统QLDB，并了解操作	HTAC主备架构：1.现有数据库服务的主备架构增加一备即可，无新系统接入，迁移方便2.当前数据和历史数据物理隔离，提高数据安全，用于快速回复3.TP/AP服务隔离，针对优化4.传输原生数据格式，业务影响低，历史数据落地快，实时性强
功能	1.SQL-like接口2.事务ACID	1.遵循SQL标准2.事务ACID、日志等传统关系型数据库功能3.时态操作4.全态操作
应用场景	1.发力点在区块链应用2.只在Amazon数据库生态服务	1.任何有全态数据管理需求的应用2.关系型数据库应用轻松迁移