Versionstamp as absolute time

Using FoundationDB
1

Hello! Is there anything about how versionstamp values are related to actual time?

I need to get some specific versionstamp and substract something from it to get versionstamp somewhere in the past (let’s say 15 seconds).

Are there any mapping between time and vt values?

2

They are related to time, but using them for a measurement of time is probably not a good idea… Also, it probably would be better to use read version and/or write version instead of the version stamp (you’re not interested in the transaction ordering or in getting a unique value anyways).

FoundationDB generates ~1 million versions per second. So in theory you could take a current version and then subtract 15 million to get a version from the past. However, there are some caveats:

  • FDB versions are monotonically increasing - however they are not strictly increasing. So if you do the above you might get to a version that doesn’t exist - depending on your use-case this might not be a problem.
  • FDB sometimes introduces large jumps in versions - namely whenever there is a recovery (so whenever something in the transaction subsystem failed). On each recovery we add 100 million new versions. You can also have multiple recoveries in a row - so seeing a version jump of billions of versions is not unheard of. Again: depending on your use-case, it might be possible to work around this, but this definitely makes the time property much less useful.
3

There is a key range called TimeKeeper in the system key space which stores a rolling history window of time to version mappings, with one data point every 10 seconds. It is not exposed via any user-facing API, though of course the data can be read by a user. It is not an official database feature and should not be relied on for anything where accuracy is critical as nothing prevents or detects system clock skew on the FDB process logging these data points.

TimeKeeper is used by backup and restore to convert timestamps to approximate versions and versions to approximate timestamps to make reasoning about backup data and restore operations easier. Lookups work by finding the nearest value for the query version or timestamp, taking the equivalent other value, and then adding an adjustment estimate based on 1 million versions per 1 second. This logic accounts for arbitrary version advancement due to recovery, DR switch operations, or any other reason.

4

Ugh - I am not a fan of every suggesting to access the system key space from an application. It’s kind of dangerous and you won’t get any guarantees that the application will work after the next release (even if that release was just a patch release).

That being said, having some time feature in FDB shouldn’t be terrible hard to implement.

@ex3ndr Can you please explain your use-case a bit better? Maybe there’s also another way it can be solved. In addition, please feel free to create an issue on GitHub.