问题描述
在Google Spanner中，提交时间戳是由服务器根据"TrueTime"生成的，如 https://cloud.google.com/spanner/docs/commit-timestamp .该页面还指出，时间戳不能保证唯一，因此多个独立的编写者可以生成完全相同的时间戳.
In Google Spanner, commit timestamps are generated by the server and based on "TrueTime" as discussed in https://cloud.google.com/spanner/docs/commit-timestamp. This page also states that timestamps are not guarnateed to be unique, so multiple independent writers can generate timestamps that are exactly the same.
在一致性保证文档中，指出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.
On the documentation of consistency guarantees, it is stated that 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.
我想了解的是
- 同时"提交的多个并发事务导致相同的提交时间戳(其中，提交时间戳构成了表键的一部分)
- 阅读器正在观察上表中输入的新行
在这种情况下，读者是否有可能观察到(最终)将使用完全相同的时间戳存储的一些但不是全部行?或者换句话说，如果搜索直到已知确切时间戳的所有行，并且正在使用该时间戳插入行，那么查询是否有可能首先返回某些结果，但是再次执行时会返回更多结果?
Under these circumstances, is it possible that a reader can observe some but not all of the rows that will (eventually) be stored with the exact same timestamp? Or put differently, if searching for all rows up to a known exact timestamp, and with rows are being inserted with that timestamp, is it possible that the query first returns some of the results, but when executed again returns more?
此上下文是尝试以仅追加的方式对按时间排序的事件流进行建模-我需要能够将有效的游标保持在特定时间点(事件流中的点) )，并且需要知道是否在时间T观察到了事件，这意味着您永远无法在时间T再次获得更多事件.
The context of this is an attempt to model a stream of events ordered by time in an append only manner - I need to be able to keep what is effectively a cursor to a particular point in time (point in the stream of events) and need to know whether or not having observed events at time T means you can never get more events again at exactly time T.
推荐答案
Spanner在外部是一致的，这意味着任何读者都只能读取已完成交易的结果...
Spanner is externally consistent, meaning that any reader will only be able to read the results of completed transactions...
与所有外部一致的数据库一起，事务外的读取器不可能读取另一个事务的挂起状态".因此，读者在时间T只能看到在时间 之前提交的交易.
Along with all externally consistent DB's, it is not possible for a reader outside of a transaction to be able to read the 'pending state' of another transaction. So a reader at time T will only be able to see transactions that have been committed before time T.
读取器在时间T不会看到在提交时间T的多个同时插入/更新事务(这会影响不同的行，否则它们不能同时发生)，但是读取器在T + 1会看到两者
Multiple simultaneous insert/update transactions at commit time T (which would affect different rows, otherwise they could not be simultaneous) would not be seen by the reader at time T, but both would be seen by a reader at T+1
是的-ish.略微改写，因为这有细微差别:
在时间T之前(包括时间T)读取事件意味着您永远不会再获得等于或早于时间T的事件.
Yes - ish. Rephrasing slightly as this is nuanced:
Having read events up to and including time T means you will never get any more events occurring with time equal to or before time T
但是请记住，commit timestamp列是一个简单的TIMESTAMP列，可以在其中存储任何值-这是应用程序要求存储的值是commit时间戳，并且没有任何内容数据库级别停止应用程序存储它喜欢的任何值...
But remember that the commit timestamp column is a simple TIMESTAMP column where any value can be stored -- it is the application that requests that the value stored is the commit timestamp, and there is nothing at the DB level to stop the application storing any value it likes...
与Spanner一样，应用程序必须强制/维护数据完整性.
As always with Spanner, it is the application which has to enforce/maintain the data integrity.
这篇关于在Google Spanner中，完全相同的提交时间戳是否有可能在已经观察到之后再次出现的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！