Slashdot Mirror

What exactly is a "cloud native database"?

A distributed database that is designed to span data centers and withstand serious network faults. A couple of examples would be CockroachDB and google spanner.

The biggest innovation I see is that it does some kind of automatic sharding. Good comparison here.

A lot of the source code is written in Go, which is interesting and probably not a bad choice. The code is clean and easy enough to understand. Its primary weakness is poor organization, which is also the primary weakness of their documentation. Both would benefit from the concept of "topic sentence, supporting sentences," so when I approach and ask, "what are the most important points here?" the answer is immediately obvious.

Looking at alternative databases these days, you always need to evaluate them in terms of the CAP theorem. What do they give up? The website mentions several times that they are consistent. They are big on partitioning, so that isn't what they've given up, so they must have given up availability. They claim to have good survivability. It seems they can keep running even if one of the servers running a shard dies (they expect sharding based on geography), and they don't offer consistency for queries across shards.

It's an interesting approach, but given the name, if the idea's any good someone else will take the idea and win with a better name. Ebola is an easier sell.

It's a veritable hipster fest. The only thing missing is a penny-farthing.

"Cockroach Labs is the company behind CockroachDB, an open source, scalable SQL database headquartered in New York City." You are correct. Only hipsters would headquarter in New York City or anywhere in California. It looks more like a class project.

It's a veritable hipster fest. The only thing missing is a penny-farthing.

Horizontal scaling - does that mean it uses shards?

No, not according to the the FAQ, which says (emphasis mine):

Does CockroachDB support distributed transactions?

Yes. CockroachDB distributes transactions across your cluster, whether it’s a few servers in a single location or many servers across multiple datacenters. Unlike with sharded setups, you don’t need to know the precise location of data; you just talk to any node in your cluster and CockroachDB gets your transaction to the right place seamlessly. Distributed transactions proceed without downtime or additional latency while rebalancing is underway. You can even move tables – or entire databases – between data centers or cloud infrastructure providers while the cluster is under load.

From their FAQ (emphasis mine):

Can a MySQL or PostgreSQL application be migrated to CockroachDB?

The current version of CockroachDB is intended for use with new applications. The initial subset of SQL we support is small relative to the extensive standard, and every popular database implements its own set of extensions and exhibits a unique set of idiosyncrasies. This makes porting an existing application non-trivial unless it is only a very lightweight consumer of SQL functionality.

It may be a really cool software package, but, I gather, if you allowed for only a "small subset" of SQL to be supported, you could have MySQL, PostgreSQL, Oracle, and Sybase as "fault tolerant" and with "strong consistency".