Jargon: CockroachDB words for newcomers

Focusing here on those words you won't find otherwise explained on our blog. Why?

  • you want to understand the chatter between devs
  • you're an external contributor to CockroachDB and want to ensure you're not missing anything
  • if you're just starting at Cockroach Labs
  • if you've been at Cockroach Labs for a while but somehow you missed an explanation and you're too afraid to ask

If you wish to have some more words explained, just ask!

The definitions should be given in Simple English. If you find them difficult to understand, ask to clarify!

  • aggregation: an operation that a client app can perform in SQL to simplify a lot of data into a simple result (e.g. counting)
  • Aphyr: the usual name Kyle Kingsbury goes by
  • AWS (Amazon Web Services): Amazon's Cloud hosting
  • Azure: Microsoft's Cloud hosting
  • Bikeshed: many engineers spending a lot of time debating a minor issue - see the story here
  • Blue: A test cluster on Azure
  • Cassandra: another DB product we hear about often
  • Change feeds: a way for a user to ask the database to ping the user (or an app, i.e. a 3rd party) back when some data changes. The changed data is notified to the 3rd party (usually) asynchronously, i.e. possibly not atomically with the transaction where the change occurs. See also "Trigger".
  • Chaos: testing method that stops nodes in a test cluster unpredictably
  • Chaos monkey: program that performs chaos testing
  • CI (Continuous integration): program that runs tests and produces reports automatically in the background
  • Cloud: someone else's computer
  • Code review: A process by which a second (or more) engineer reviews code before it is merged into the main codebase. At CRL, every code must be reviewed, and approved (see LGTM).
  • Code yellow: moving an issue to top company priority (idea comes from Google). During a code yellow, any task pertaining to the code yellow takes precedence over non code yellow related tasks.
  • Cutting the release: selecting one particular version of the product to publish out
  • Data sovereignty: the demand for some apps/companies to have data located in specific places geographically, for example in EU data for citizens must be hosted in the EU
  • DDL (Data Definition Language): the part of SQL that apps can use to manage tables and indexes (the schema), e.g. create/rename/delete them. This includes e.g. "CREATE TABLE" but does not include "SELECT". See also "DML."
  • Delta: test cluster on GCE
  • Denormalization: An explicit copy of some normalized data in a different format, in order to enable faster access. "Denormalized data" = indexes, materialized views, etc. --- all the stuff that copies "base" data into a different format for speed on operations that aren't by primary key.
  • DML (Data Manipulation Language): the part of SQL that apps can use to read and write data, e.g. query tables or update table rows. This includes e.g. "SELECT" or "INSERT" but does not include "CREATE TABLE". See also "DDL."
  • Encryption at rest: have the data encrypted in the database, not only when queried by clients
  • Gamma: test cluster on GCE
  • GCE (Google Compute Engine): Google's Cloud hosting
  • Geospatial index: An index that is efficient for storing 2d coordinates (such as lat/long) such that two points on the coordinate system that are close on the (lat/long) map are stored relatively close together in the index ordering. The uniqueness of the Geospatial index is in maintaining the "closeness" when going down from 2 dimensions (lat/long) to one dimension (the index). Usually achieved with a space filling curve
  • GIS (Geographical Information System): A system optimized for geographical data, makes heavy use of geospatial indexes, but also spatial-temporal indexes (combination of geospatial data and time series data), and also can understand and digest data stored in standard formats used for geographic data.
  • Git: a tool and database to store and share source code
  • Index: A copy of some parts of a database table, ordered to make lookups very quick according to the index columns. There is always a "primary index", ordered by primary key, making lookups of a row if you know the primary key very fast. Other indexes are called "secondary indexes", and are ordered by some other criteria (could be some other columns, or even combinations of columns, or even combinations of columns from different tables). An index is a denormalization.
  • Jepsen: a tool that tests databases in a harsh way, made by Aphyr; also the name of Aphyr's blog about database testing
  • LGTM: Short for "looks good to me", the typical way one says they approve of a PR at the end of a code review, okaying it for merge. LGTM doesn't necessarily mean you can hit the merge button, for instance "LGTM, if you fix XYZ" still means XYZ should be done. They are just trusting you to do so, and don't necessarily need to verify that (if XYZ is trivial).
  • Materialized view: a SQL view where the data of the view is duplicated from the original table (As opposed to a simple/dematerialized view, where a query on the view is automatically translated to a query on the underlying table). Materialized views are useful when the query that creates the view is complex and the views is used more often than the data is changed, because it then saves SQL execution time for the clients using the view.
  • Merge: the action of accepting a PR to the main product
  • Merge skew: An error condition encountered when master moves on, and your commit can be merged according to git (because syntactically it can be merged) but fails CI tests when merged (because logically it cannot be merged). For example, if a function's behavior changes in some way on master, but you call it relying on the old behavior, this might pass in CI and only be detected once you attempt the merge (since CI will rerun every build on master, to detect if this happened). Can be avoided by a healthy regimen of regularly rebasing on master. If master has moved on by more than a few dozen commits, usually a good idea to rebase before merging!
  • Mongo: short for MongoDB, another DB product we hear about often
  • Normalization: Normalization refers to the process of reducing copies of data as much as possible so that there aren't too many logical copies of the same information (as that would increase the possibility of errors if some copies are updated without updating all copies). See wikipedia. Usually contrasted with explicit denormalization.
  • OLAP (Online Analytics Processing): a class of applications where the most common queries are long and touch most of the data at a time with complex computations -- contrast with OLTP
  • OLTP (Online Transaction Processing): a class of applications where the most common queries are short and touch a bit of data at a time with simple computations -- contrast with OLAP
  • ORM (Object-Relational Mapping): a piece of software used by an app to access a DB
  • PR (Pull Request): a proposal for a change to the source code submitted for review to colleagues. See "merge"
  • Production monkey: person deploying new versions and maintaining test clusters. Usually rotates and a rotation lasts a week, to encourage all engineers to be familiar with running a full cluster.
  • Range: a portion of the data in a DB. In other distributed databases called a "shard", "chunk", or "tablet".
  • Rebase: Take a git commit (the set of line-by-line changes) and apply those deltas to a different commit. Usually done because "master" moved on while you were working on a change, and now your commit won't merge cleanly. Usually a good habit to do before merging anyway, as not all conflicts are caught by git. See "merge skew".
  • Reg cluster: short for "registration cluster", a production cluster on Google Cloud storing our usage stats
  • Replication factor: how many copies there are of each Range in a DB or Zone. Default is 3.
  • Replica: one of the copies of some Range in a DB or Zone. There are replication factor replicas of a range across a cluster.
  • RFC: Short for "Request for comments". An RFC is a description of a larger change, written to outline why the change, what the change will consist of, etc. before the code is written. Used to build consensus around a code, before diving into writing code for weeks. This lets issues/thoughts get surfaced early, so that time is not wasted writing code, only to discover in a code review that there was a much better way to do things, if only, say, the author had requested some comments on their thoughts before diving off.
  • Rho: A test cluster on GCE
  • Spanner (Google product): another project we get inspiration from
  • SRE: Site Reliability Engineer - a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems, with the goal of creating scalable and reliable software systems
  • Team City: one of our continuous integration tools
  • Time series: a way to organize data in a DB where the data is organized primarily by time; commonly used to store events over time; sometimes subject to OLAP applications
  • Trigger: a way for a user to ask the database to ping the user (or an app) back when some data changes, or run a stored procedure on the server. The trigger (usually) happens before the transaction commits, so that the consumer can see the changes atomically. See also "Change feed".
  • Zone config/zones: CockroachDB way to set different configuration parameters to different parts of a cluster, can be used to set constraints on replication (e.g. at least one copy must be on a different continent) or for data sovereignty (e.g. no copies of this data should reside outside EU territory)