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