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/

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559354/viewspace-2285644/，如需轉載，請註明出處，否則將追究法律責任。