...

Overview of run-time components

...

Summary table

Logical components: the account administrator's view

Deployment components: the deployment/SRE view

Description	In-code abstraction	In-memory instance	Unix process	Running container
Routes SQL clients to the right server Image Modified	“SQL proxy”	“SQL proxy instance”	“SQL proxy server”	“SQL proxy pod”
Runs SQL queries Image Modified

“SQL”or

“SQL” or “SQL gateway”	“SQL instance”	“SQL server”or “SQL-only server” to highlight server contains no KV instance	“SQL pod”(implies “SQL-only server”)
Runs KV queries Image Modified	“KV components” (plural)	“KV instance”	“KV server” but the term is inclusive of mixed servers, we don't yet support KV-only servers.	N/A, we don't currently run KV-only servers.
Stores data for multiple

tenants

virtual clusters, 1 unit Image Modified			NEW: “Shared storage server”	NEW: “Shared storage pod”
Runs both SQL and KV queries Image Modified			NEW: “Mixed SQL/KV servers”	NEW: “Mixed SQL/KV pods”
Stores data for all

tenant

virtual clusters, fleet of all servers Image ModifiedImage ModifiedImage Modified

NEW: “Shared storage cluster”

NEW: “Shared storage cluster”

N/A

N/A

We also use the word “node” to designate either a unix process or Docker container, when the distinction does not matter.

...

This complete fleet of “All the things” is named a Serverless host cluster.

...

...

What's virtualized

...

New name for the virtualized logical concept

...

Previous terminology

...

New name for the physical infrastructure 

...

The CockroachDB cluster service, as a whole

...

“Virtual cluster”

...

“Cluster”

...

N/A: the underlying infrastructure is not visible to end-users any more.

...

Run-time state for a (virtual) cluster

...

“VC Servers/pods”

...

“Servers/pods”

...

NEW: “Shared storage servers/pods”

...

On-disk state for a (virtual) cluster

...

“VC-specific data” or “virtual keyspace”

...

“CockroachDB data”

...

NEW: “Shared storage data”

...

new: the SQL interface used to administer other virtual clusters = system interface (Previously “system tenant”)

Beware of the difference between “Shared storage cluster” (deployed system) and “System interface” (logical cluster an administrator connects to, to create additional virtual clusters)

...

Ownership (not data)

...

“Tenant” or “Workload”

...

“User”

Architectural terms

SQL Proxy

...

• Accepts incoming connections from SQL proxy.

• Responsible for SQL query execution for client apps, scoped to one virtual cluster.

• Performs KV data requests to a shared storage cluster.

• Also offers tenant-specific HTTP APIs scoped to one virtual cluster.

• Also known as “SQL-only server, pod, node” when the process only contains a SQL instance.

...

Today, the term “system interface” largely overlaps with “shared storage cluster” because, implementation-wise, we have chosen to give SQL semantics to the keyspace that does not use a VC prefix. However, this choice may be revisited in the future, such that we mandate a tenant VC prefix for all logical clusters including the system cluster. Should such plans materialize, the system interface would be supported by a virtual cluster too. It is thus useful to be disciplined about distinguishing the term “system interface”, which designates a SQL interface, and “shared storage cluster”, which designates the set of interconnected storage servers.

This system interface and all its “own” data also has an owner, which in the context of CC is Cockroach Labs itself. The owner of the system cluster interface is the system tenant.

System instances and servers

...

• At run-time:

  • The SQL proxy node(s) (server(s) and pod(s)), which routes SQL client apps to their own virtual cluster.

  • The shared storage/DB nodes (servers and pods).

  • The networked shared storage/DB cluster, as a fleet of nodes.

  • The run-time state of the system clusterinterface.

• On disk:

  • The aggregate state of all virtual clusters stored on a single storage cluster.