​​​​​​​沒有物理時鐘的WAN全域性高一致性資料庫：FaunaDB

背景
FaunaDB更具體地說是一個Relational NoSQL資料庫平臺。術語“NoSQL”僅指介面; FaunaDB目前支援執行透明的過程介面，而不是宣告性SQL。

術語“關係”指的是資料模型，但FaunaDB除支援關係外還支援圖形和文件模型。它還呼叫了RDBMS的慣例保證：

具有可序列化隔離的ACID事務
跨副本的可線性化，一致的操作
與傳統的RDBMS不同，FaunaDB即使在地理上分佈也能保持這些保證。

可序列化隔離
可序列化隔離意味著系統可以並行處理許多事務，但最終結果相當於一個接一個地處理它們。對於大多數資料庫系統，訂單不是事先確定的。相反，事務是並行執行的，並且一些鎖定變體用於確保最終結果等同於某些序列順序。

FaunaDB中的預處理
FaunaDB的協議受到Calvin的啟發，在執行對資料庫的任何寫入之前決定此序列順序。對於每批並行事務，它們被插入到分散式預寫事務日誌中，並且FaunaDB執行引擎確保處理此批事務的順序等同於它們出現在這個預先生成的日誌中順序。

日誌中的每個事務都與實際時間相關聯。但是，與其他分散式資料庫不同，物理實時不是FaunaDB協議的核心元件，FaunaDB不依賴於跨伺服器的時鐘全域性同步。“FaunaDB時間”與實時之間的粗略對應僅僅是開發人員的事情，但不是自身操作約束。相反，“之前”和“之後”的概念完全取決於事務在分散式日誌中出現的順序。

FaunaDB可以從分散式日誌中的任何一點獲取“快照”，其中包括在該點之前出現在日誌中的所有事務的寫入，並且在此之後則不會寫入。例如，T4處的快照將包含事務T0-T4，但不包括之後的。

為了在日誌中的任意點快速生成快照，FaunaDB會保留每個記錄的多個版本。每個版本都使用timestamp進行註釋 - 時間戳。

客戶端可以將事務傳送到任何複製節點 - 包括只讀事務和更新資料庫中資料的事務。但是，整個FaunaDB部署只有一個事務日誌(banq注：類似區塊鏈哦)。複製節點必須就如何將新事務插入日誌達成共識，FaunaDB使用最佳化的Raft實現來達成共識。