Engineering

A modern distributed database should do more than just split data amongst a number of servers; it should correctly manage partitions (or shards). Moreso, it should automatically detect failures, fix itself without any operator intervention, and completely abstract this management from the end user. This post is the first in a series on how CockroachDB handles its data and discusses the mechanisms it uses to rebalance and repair. These systems make managing a CockroachDB cluster significantly easier than managing other databases.

CockroachDB makes data easier to manage by providing a strongly-consistent, highly-scalable, SQL interface that you can trust to be there when you need it. We’ve designed it to be a truly cloud-native, distributed SQL database that’s easy to operate in any environment you throw at it. One such computing environment that has grown in popularity over the previous few years is Mesosphere’s DC/OS, a datacenter operating system built on top of Apache Mesos. DC/OS is an orchestration system for deploying and managing distributed applications across a cluster of machines as if they were a single pool of resources. DC/OS has both an open source and an enterprise version that gives you the ability to elastically scale your infrastructure on prem or in the cloud. It provides scheduling, resource allocation, service discovery, automatic recovery from failure, load balancing, and more, all with the goal of making it easier to manage your applications.

Alex Robinson

September 28, 2017

Most databases offer a choice of several transaction isolation levels, offering a tradeoff between correctness and performance. However, that performance comes at a price, as developers must study their transactional interactions carefully or risk introducing subtle bugs. CockroachDB provides strong (“SERIALIZABLE”) isolation by default to ensure that your application always sees the data it expects. In this post I'll explain what this means and how insufficient isolation impacts real-world applications.

Ben Darnell

September 21, 2017

As CockroachDB approaches beta, user documentation has become increasingly important, and one of the meatiest requirements is documentation of our SQL implementation. For inspiration, I researched how other databases have documented SQL. The most effective example I found was SQLite’s grammar diagrams.

The goal of CockroachDB is to “make data easy,” and while it seems like a stretch now, we eventually want CockroachDB to be able to act as the entire state layer for web applications. We are currently addressing the SQL layer, and a full-text search like ElasticSearch is somewhere ahead on the product horizon. Since Cockroach Labs offered a flexible policy for work on experimental projects, I decided to use mine to experiment with implementing the Redis protocol on top of CockroachDB, attempting to answer the question: Could CockroachDB ever replace Redis?

In this blog post, we’ll explore the motivations behind the REGIONAL BY ROW abstraction, take a deeper dive into the abstraction itself, and look behind the scenes to understand how REGIONAL BY ROW works under the covers. We also have a hands-on demo for you to try out at the end, so you can play around with a toy multi-region cluster yourself!