May 2016 Summaries

Michael Hausenblas, a Mesosphere Developer and Cloud Advocate, undertook the task of running CockroachDB on DC/OS and shared his experiences in a Medium post. He detailed the process of utilizing CockroachDB’s Docker image, setting up a DC/OS cluster, and testing both data ingestion and querying capabilities. His overall assessment of the experience was positive, encapsulated by his enthusiastic remark, "It’s awesome."

Paul Steffensen, known as uptimeDBA, has conducted an analysis of how CockroachDB handles NULL values in comparison to the SQL standard and various other SQL implementations. He presents his findings in a blog post titled "I’ve got nothing. NULL handling in CockroachDB," offering insights into the differences and similarities in NULL value processing across platforms. The full post is available for those interested in exploring the intricacies of SQL NULL handling and CockroachDB's approach.

CockroachDB is designed to ensure data survivability through its distributed consistent key-value store and replication model, utilizing Raft consensus for replicated writes to guarantee data durability. Each write is synchronously replicated across multiple nodes, ensuring that if one node fails, others retain an exact copy of the data. To bolster confidence in this model, a subsystem periodically verifies the consistency of data across replicas, using SHA-512 checksums to identify replication discrepancies. Despite initial confidence in the system's reliability, verification processes uncovered bugs such as non-deterministic protocol buffer encodings, unauthorized replica updates, incorrect merging of time series data, and non-deterministic floating point additions, which were subsequently addressed. CockroachDB not only aims to provide a robust database system that withstands failures but also aspires to implement automatic online verification for additional features like indexes and foreign keys, ensuring trust through continuous validation.

CockroachDB, initially a NoSQL distributed key-value store, has evolved into a relational SQL database, necessitating the use of two network ports due to protocol differences between HTTP and PGWire. The original setup allowed multiplexing admin UI and RPC traffic on a single port using net/rpc, but implementing PostgreSQL's wire protocol required a distinct port because PGWire operates over plain TCP. To manage this, CockroachDB employed cmux to distinguish between protocols and route traffic accordingly. While the switch to gRPC, which supports HTTP2 features, improved performance by avoiding blocking with multiplexed streams, it also introduced complications with TLS and the admin UI. The current solution involves separating the HTTP admin UI onto its own port while gRPC and PGWire share another, pending potential performance fixes from gRPC maintainers that could reinstate a single-port configuration.

CockroachDB's architecture ensures serializable isolation in distributed transactions using an optimistic, multi-version, timestamp-ordered concurrency control system. The Serializable Snapshot isolation level guarantees that transactions are recoverable and serializable by enforcing strict scheduling and disallowing any conflicting operations that could create a cyclic serializability graph. CockroachDB achieves this by using a multi-version concurrency control (MVCC) mechanism, where multiple timestamped versions of a key's value are stored, ensuring that write-read conflicts with later transactions are avoided. Additionally, a timestamp cache records read operations to prevent read-write conflicts, while write-write conflicts are managed by aborting transactions that attempt to commit out of order. Transactions are prioritized, with random priorities assigned and adjusted upon restarts to resolve conflicts deterministically. The system also includes mechanisms for dealing with abandoned transactions by using a heartbeat timestamp to identify and abort inactive transactions. CockroachDB's isolation level allows for high concurrency without a central coordinator, offering a robust solution for executing distributed ACID transactions.