Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Cockroach enforces this guarantee on a per-key basis as opposed to for the entire node. If a key has been read at time t, it may only be subsequently written at time > t. CockroachDB accomplishes this using a timestamp cache at the leader node for a range. But this doesn't cause writes to block. Instead, the write timestamp is pushed to the most recent read + 1 logical tick.


Interesting, thanks for the info.

Do reads execute through raft? If not, how do you guarantee that behavior - relying on leader leases? If so, does the lease period guarantee disjointness in the timestamps a leader can process, or do you rely on the leader abdicating control via timeout?

Since it can push the write timestamp, does that mean the write transaction aborts if it was in serializable mode? Does that cause problems updating a value that is heavily read?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: