我正在阅读Google's Spanner DB的论文。这似乎解决了Rich Hickey's Datomic的一些类似问题。
Google的Spanner数据库是否实现了Epochal Time的概念？
答案 0 :(得分：1)
总结：我想是的，但我不确定“Epochal Time”概念到底是什么。
我看过问题中引用的整个视频（幸运的是，这是一个有趣的视频），除了Hickey对未来的看法之外，没有看到“Epochal Time”概念（或者“epoch”可能是什么）的定义作为过去的纯函数（至少在数据库方面）[1]，或者更确切地说，作为一系列交易函数的组成。
在线之间阅读，我认为核心思想是时间可以分为量子，每个量子代表单个交易功能的完整执行。 （我想Hickey会说这些量子是“时代”，但也许我错了; Datomic词汇表中“epoch”的定义只是有些相关。）因为每个事务函数都有效地包含了自己执行的断言，事务标识符可以被认为是时间量子的代理;实际上，与单个交易者一起使用的交易标识符可能被迫成为与某个机器时钟同时相关的单调递增的数字序列（尽管不完全相同，因为各个时钟可以随着时间推移向后跳过。）
所以我把这个想法解释为双重的：
为每个突变附加一个“时间戳”;以及
安排突变添加，而不是替代过去的数据。
如果是这样，那么Bigtable - 有一些实现限制 - 和Spanner都符合Hickey的模型。
Bigtable [2]提供了一个key-timestamp-value映射，但将其留给每个应用程序以保证时间戳单调性。对于实现单调时间戳并使用单个编写器的应用程序，它看起来与Datomic非常相似;它也基于不可变数据结构，并允许基于时间戳的查询（“过去是现在的子范围”）。但是，正如Spanner论文[3]所指出的那样，Bigtable不提供同步更新，因此无法保证从副本读取的两个不同的键将具有相同的过去子范围。由于这显然导致谷歌内部团队使用昂贵，缓慢的Bigtable替代品，因此Spanner还旨在以相对有效的方式提供同步更新，即使以使交易更加昂贵为代价。如果我正确理解了Spanner的论文，那么这部分成本就是mutator不能依赖与本地可用的交易者进行通信，因为数据库的每个部分在任何给定的时间点都有一个当选的交易领导者。
尽管Spanner提供了“类SQL”API，但其内部数据存储区（如Bigtable）是密钥时间戳值。与Bigtable不同，时间戳由交易者提供，并且与实时保持密切监控（谷歌显然购买了自己的原子钟，“并不那么贵”，以帮助维持这种保证）。 根据设计，Datomic是一个单一的交易系统，但允许配置备用交易器以实现高可用性。 （只有一个，如果我正确阅读文档。）这使得时间同步变得更加容易，并且它还使用实时作为时间戳。
在某种程度上，所有三个数据库系统在概念上都提供了时间有序的突变。它们对单独突变的时间戳的一致性和单调性的保证以及它们提供全局写 - 读一致性的实际能力有所不同，但它们在演示的最初几分钟内确实满足了Hickey的相同基本特征。 ：突变（“更新”）是数据模型的一部分，易于解释，并且从根本上说是非破坏性的。
[1]：在大约19分钟的视频中，Hickey说“时代时间模型”只是他提出的一个短语，并没有正式的定义。
[2]：在他的演讲大约42分钟后，Hickey描述了Bigtable架构，显然是他所谈论的一个例子。 Spanner显然是一种后继技术，它扩展但不替代基础数据模型。