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