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.關系型資料庫應用輕松遷移 |
7.TDSQL關于曆史資料的思考
金融計費領域中，出于資料安全、交易可靠、計費精準等原因，追溯曆史是必要的。在騰訊公司的計費業務中，随着業務不斷增長，帶有時态屬性的資料被管理的需求日益旺盛。這正是TDSQL全時态資料庫的萌芽，全面、友善地管理金融曆史資料，以便基于曆史資料做大量的計算驗證，進而保證金融資料安全、交易可靠、計費精準。
曆史資料的意義不僅限于金融領域，在地籍管理、電子政務等應用都可大顯身手。事實上，在資料量急速膨脹的今天，任何業務都存在曆史資料管理的需求，然而，現代的資料庫系統隻保留資料的目前值，因存儲成本等原因，曆史資料被丢棄。
資料作為重要的資産，不論是目前資料，還是曆史上曾存在過的資料，都具有重要價值。曆史資料的存儲、被分析、被挖掘、被反複使用，是目前網際網路企業的需求，是金融行業的需求，也是資料管理未來的方向。
在曆史資料管理需求日益增長的趨勢下，TDSQL資料工作者提出核心價值觀：曆史資料富有價值，一切過往(資料的曆史和狀态)兼可追溯，并以“為資料賦能”作為核心理念，為使用者提供更可靠、更完善、更精準的資料服務。
References
1. AWS re:Invent 2018 Keynote - Andy Jassy
https://youtu.be/ZOIkOnW640A
2. Amazon Quantum Ledger Database (QLDB)
https://aws.amazon.com/cn/qldb/
3. Amazon Managed Blockchain
https://aws.amazon.com/managed-blockchain/
4. 銀行業金融機構資訊系統風險管理指引
http://www.cbrc.gov.cn/upload/zwgk/ml3/2/5-2-32.doc
5. 深圳市互金協會對銀監會存管指引的全面解讀
http://www.szifa.org.cn/enrollment_view.aspx?TypeId=121&Id=605
6. Introduction to Amazon Quantum Ledger Database (QLDB)
https://youtu.be/7G9epn3BfqE
7. 騰訊區塊鍊服務TBaaS
https://cloud.tencent.com/product/tbaas
8. Hyperledger
https://www.hyperledger.org/
9. TDSQL時态資料庫-理論與主流實作
http://blog.itpub.net/31544289/viewspace-2157766/
10. TDSQL時态資料庫-功能實作
http://blog.itpub.net/31544289/viewspace-2157282/
11. TDSQL時态資料庫-理念與願景
http://blog.itpub.net/31540857/viewspace-2155687/