Google的Spanner DB是否實現了Epochal Time的概念？

Question

我正在閱讀Google's Spanner DB的論文。這似乎解決了Rich Hickey's Datomic的一些類似問題。

谷歌的Spanner DB是否實現了Epochal Time的概念？

Answer 1

摘要：我這麼認爲，但我不確定「時代週期」概念實際上是什麼。

---

我看到的問題（幸運的是，這是一個有趣的視頻）引用的整段視頻而沒有看到「時代性時間」（或「時代」可能是什麼）比其他的概念的定義Hickey將未來視爲過去的純函數（至少在數據庫方面）[1]，或者更準確地說，是將一系列交易功能組合起來。

在各行之間的閱讀中，我認爲核心思想是時間可以分爲量子，每個量子代表一個事務函數的完整執行。 （我猜Hickey會說這些量子是「時代」，但也許我錯了; Datomic詞彙表中「epoch」的定義只是有點相關）。由於每個事務函數都有效地包含了它自己的執行的斷言，交易標識符可以被認爲是時間量的代理;事實上，與單個交易者一起使用的交易標識符可能會被迫成爲與某個機器時鐘巧合相關的單調增加的數字序列（儘管不是完全相同，因爲個別時鐘可以隨時間跳躍向後）。

所以我將這個想法解釋爲兩倍：

1. 附加一個「時間戳」給每個突變;和

2. 安排突變來增加而不是替代過去的數據。

如果是這樣，那麼Bigtable - 有一些實現方面的限制 - 而Spanner確實符合Hickey的模型。

---

Bigtable的[2]提供了一種鍵時間戳值的映射，但保留這些給每個應用程序，以保證時間戳單調性。對於實現單調時間戳並使用單個寫入器的應用程序，它看起來與Datomic非常相似;它也基於不可變的數據結構，並允許基於時間戳的查詢（「過去是現在的子範圍」）。但是，正如Spanner論文[3]所指出的，Bigtable不提供同步更新，因此不能保證從副本讀取的兩個不同密鑰具有相同的過去子範圍。由於這顯然導致谷歌內部團隊使用昂貴且速度慢的Bigtable替代品，因此Spanner的設計目的在於以相對高效的方式提供同步更新，即使交易成本更高。如果我正確理解了Spanner文件，那麼這部分費用是由於數據庫的每個部分在任何給定的時間點都有一個選定的事務處理負責人，因此增變器不能依賴與本地可用的處理器進行通信。

儘管Spanner提供了一個類似於SQL的API，但它的內部數據存儲Bigtable等是key-timestamp-value。與Bigtable不同的是，時間戳是由交易者提供的，並且保持在與實際時間的仔細監控的偏差之內（Google顯然購買了自己的原子鐘，「不那麼昂貴」，以幫助保持這種保證）。 Datomic在設計上是單個交易者系統，但允許配置備用交易者以實現高可用性。 （只有一個，如果我正確地閱讀文檔。）這使得時間同步更容易，並且它也使用實時作爲時間戳。

所有三個數據庫系統，在某種程度上或其他方面，概念上都提供時間排序的突變。他們對於單獨突變時間戳的一致性和單調性以及提供全局讀寫一致性的實際能力有所不同，但它們都滿足了Hickey在其演講的前幾分鐘中的相同基本特徵：突變（「更新」）是數據模型的一部分，易於解釋，並且基本無損。

---

[1]：在約19分鐘，放入視頻，希基指出，「劃時代的時間模式」僅僅是他想出了一個短語，並沒有正式的定義。 [1]：Hickey在他的演講中約42分鐘描述了Bigtable架構，顯然是他正在談論的一個例子。 Spanner顯然是一種後繼技術，它擴展了但並不替代底層數據模型。

[3]：PDF: Scanner paper from OSDI 2012