InsanityUnlimited.com

With CockroachDB version 21.1, a new concept of “ global tables ” was introduced. This functionality is a good fit for situations where read latency on a table needs to be very low and write latency can be much higher than normal [read: it needs to be fast when doing lookups, but we can tolerate lengthy writes] . It is also a fit for when reads must be up to date for business reasons or because the table is referenced by foreign keys or where latency critical reads cannot be tied to specific regions. So using the global tables functionality is ideal for any kind of reference table, where we want to get the data out very quickly, but we can handle long inserts and updates. With global tables, the lengthy writes go about doing all the pre-work to prevent any contention and serializable errors that we would traditionally see. When we read from the table, all the work has previously been done to avoid any contention and we can access the closest replica and read from it, effectively a...

In this post on CockroachDB, I will delve into the impacts of co-locating range leaseholders together when a multi-table join is executed via SQL.  We'll see that when all the leaseholders are geographically close to each other in a distributed system, the performance is much more predictable and latencies are lower.  The worst case scenario is when leaseholders for the various elements used in the join are scattered from a geographic perspective. To start from the beginning, within CockroachDB, all of the data and indexes in a cluster are part of a global KV store.  This KV store is sliced up into ranges that usually span 128MB to 512MB in size.  Each of these ranges will have a number of replicas (3 by default, but configurable) and one of those replicas of a given range will be elected the LeaseHolder for the range.  The leaseholder is used to coordinate all reads and writes for that range of data.  For writes, the leaseholder coordinates the quorum base...