在 Google Spanner 中，是否有可能在已经观察到之后再次出现完全相同的提交时间戳

Question

在 Google Spanner 中，提交时间戳由服务器生成并基于 https://cloud.google.com/spanner/docs/commit-timestamp 中讨论的“TrueTime”。该页面还指出，时间戳不保证是唯一的，因此多个独立编写者可以生成完全相同的时间戳。

在一致性保证的文档上，写着In addition if one transaction completes before another transaction starts to commit, the system guarantees that clients can never see a state that includes the effect of the second transaction but not the first.

我想了解的是结合

1. 多个并发事务“同时”提交导致相同的提交时间戳（其中提交时间戳构成表键的一部分）
2. 一位读者观察到上表中输入了新行

在这些情况下，读者是否有可能观察到（最终）将使用完全相同的时间戳存储的部分但不是所有行？或者换一种说法，如果搜索直到已知确切时间戳的所有行，并且使用该时间戳插入行，查询是否有可能首先返回一些结果，但再次执行时返回更多结果？

这里的上下文是尝试以仅追加的方式对按时间排序的事件流进行建模-我需要能够将有效的光标保持在特定时间点（事件流中的点) 并且需要知道在时间 T 观察到的事件是否意味着您永远无法在确切的时间 T 再次获得更多事件。

Answer 1

Spanner 是外部一致的，这意味着任何读取器将只能读取已完成事务的结果...

除了所有外部一致的数据库之外，事务之外的读取器不可能能够读取另一个事务的“待定状态”。因此，时间 T 的读者将只能看到在时间 T 之前提交的事务。

在提交时间 T 的多个同时插入/更新事务（这会影响不同的行，否则它们不能同时发生）在时间 T 时读者不会看到，但在 T+1 时读者会看到两者

我...需要知道在时间 T 观察到的事件是否意味着您永远无法在确切的时间 T 再次获得更多事件。

是的 - 是的。稍微改述一下，因为这是细微差别的：
读取到时间 T 并包括时间 T 意味着您将永远不会在时间等于或早于时间 T 的时间内发生任何事件

但请记住，提交时间戳列是一个简单的 TIMESTAMP 列，其中可以存储 任何 值——它是应用程序请求存储的值是提交时间戳，并且没有任何内容停止应用程序存储它喜欢的任何值的 DB 级别...

与 Spanner 一样，应用程序必须强制/维护数据完整性。