Oct
30
2018
--

Cockroach Labs launches CockroachDB as managed service

Cockroach Lab’s open source SQL database, CockroachDB, has been making inroads since it launched last year, but as any open source technology matures, in order to move deeper into markets it has to move beyond technical early adopters to a more generalized audience. To help achieve that, the company announced a new CockroachDB managed service today.

The service has been designed to be cloud-agnostic, and for starters it’s going to be available on Amazon Web Services and Google Cloud Platform. Cockroach, which launched in 2015, has always positioned itself as modern cloud alternative to the likes of Oracle or even Amazon’s Aurora database.

As company co-founder and CEO Spencer Kimball told me in an interview in May, those companies involve too much vendor lock-in for his taste. His company launched as open alternative to all of that. “You can migrate a Cockroach cluster from one cloud to another with no down time,” Kimball told TechCrunch in May.

He believes having that kind of flexibility is a huge advantage over what other vendors are offering, and today’s announcement carries that a step further. Instead of doing all the heavy lifting of setting up and managing a database and the related infrastructure, Cockroach is now offering CockroachDB as a service to handle all of that for you.

Kimball certainly recognizes that by offering his company’s product in this format, it will help grow his market. “We’ve been seeing significant migration activity away from Oracle, AWS Aurora, and Cassandra, and we’re now able to get our customers to market faster with Managed CockroachDB,” Kimball said in a statement.

The database itself offers the advantage of being ultra-resilient, meaning it stays up and running under most circumstances and that’s a huge value proposition for any database product. It achieves up time through replication, so if one version of itself goes down, the next can take over.

As an open source tool, it has been making money up until now by offering an enterprise version, which includes backup, support and other premium pieces. With today’s announcement, the company can get a more direct revenue stream from customers subscribing to the database service.

A year ago, the company announced version 1.0 of CockroachDB and $27 million in Series B financing, which was led by Redpoint with participation from Benchmark, GV, Index Ventures and FirstMark. They’ve obviously been putting that money to good use developing this new managed service.

Mar
27
2017
--

What’s Next for SQL Databases?

SQL Databases

SQL DatabasesIn this blog, I’ll go over my thoughts on what we can expect in the world of SQL databases.

After reading Baron’s prediction on databases, here:

https://www.xaprb.com/blog/defining-moments-in-database-history/

I want to provide my own view on what’s coming up next for SQL databases. I think we live in interesting times, when we can see the beginning of the next-generation of RDBMSs.

There are defining characteristics of such databases:

  1. Auto-scaling. The ability to add and use resources depending on the current load and database size. This is done transparently for users and DBAs.
  2. Auto-healing. The automatic handling of node failures.
  3. Multi-regional, cloud-agnostic, geo-distributed. The ability to support multiple data centers and multiple clouds, in different parts of the world.
  4. Transactional. All the above, with the ability to support multi-statements transactional workloads.
  5. Strong consistency. The full definition of strong consistency is pretty involved. For simplicity, let’s say it means that reads (in the absence of ongoing writes) will return the same data, despite what region or data center you are getting it from. A simple counter-example is the famous MySQL asynchronous replication, where (with the slave delay) reading the data on a slave can return very outdated data. I am focusing on reads, because in a distributed environment the consistent reads performance will be affected. This is where network latency (often limited by the speed of light) will define performance.
  6. SQL language. SQL, despite being old and widely criticized, is not going anywhere. This is a universal language for app developers to access data.

With this, I see following interesting projects:

  • Google Cloud Spanner (https://cloud.google.com/spanner/). Recently announced and still in the Beta stage. Definitely an interesting projects, with the obvious limitation of running only in Google Cloud.
  • FaunaDB (https://fauna.com/). Also very recently announced, so it is hard to say how it performs. The major downside I see is that it does not provide SQL access, but uses a custom language.
  • Two open source projects:
    • CockroachDB (https://www.cockroachlabs.com/). This is still in the Beta stage, but definitely an interesting project to follow. Initially, the project planned to support only key-value access, but later they made a very smart decision to provide SQL access via a PostgreSQL-compatible protocol.
    • TiDB (https://github.com/pingcap/tidb). Right now in RC stages, and the target is to provide SQL access over a MySQL compatible protocol (and later PostgreSQL protocol).

Protocol compatibility is a wise approach, although not strictly necessary. It lowers an entry barrier for the existing applications.

Both CockroachDB and TiDB, at the moment of this writing, still have rough edges and can’t be used in serious deployments (from my experience). I expect both projects will make a big progress in 2017.

What shared characteristics can we expect from these systems?

As I mentioned above, we may see that the read performance is degraded (as latency increases), and often it will be defined more by network performance than anything else. Storage IO and CPU cycles will be secondary factors. There will be more work on how to understand and tune the network traffic.

We may need to get used to the fact that point or small range selects become much slower. Right now, we see very fast point selects for traditional RDBM (MySQL, PostgreSQL, etc.).

Heavy writes will be problematic. The problem is that all writes will need to go through the consistency protocol. Write-optimized storage engines will help (both CockroachDB and TiDB use RocksDB in the storage layer).

The long transactions (let’s say changing 100000 or more rows) also will be problematic. There is just too much network round-trips and housekeeping work on each node, making long transactions an issue for distributed systems.

Another shared property (at least between CockroachDB and TiDB) is the active use of the Raft protocol to achieve consistency. So it will be important to understand how this protocol works to use it effectively. You can find a good overview of the Raft protocol here: http://container-solutions.com/raft-explained-part-1-the-consenus-problem/.

There probably are more NewSQL technologies than I have mentioned here, but I do not think any of them captured critical market- or mind-share. So we are at the beginning of interesting times . . .

What about MySQL? Can MySQL become the database that provides all these characteristics? It is possible, but I do not think it will happen anytime soon. MySQL would need to provide automatic sharding to do this, which will be very hard to implement given the current internal design. It may happen in the future, though it will require a lot of engineering efforts to make it work properly.

Oct
05
2016
--

Percona Live Europe 2016: “Inside CockroachDB’s Survivability Model” with Marc Berhault

Percona Live Europe

Percona Live Europe

The Percona Live Europe 2016 conference is moving along quickly, and today we saw a lot of presentations on open source database that AREN’T MySQL or MongoDB.

There are more than 100 open source databases in the world, each with their own design and use case sweet spots. At Percona Live Europe, we get a chance to learn about some of the most popular open source databases, their design use cases, user stories as well as how they work with together with MySQL and MongoDB.

One such talk was from Marc Berhault, Engineer at Cockroach Labs. CockroachDB is a distributed SQL database built on a transactional and strongly-consistent key-value store.

This talk took a deep dive into CockroachDB, a database whose “survive and thrive” model aims to bring the best aspects of Google’s next generation database, Spanner, to the rest of the world via open source. Marc looked specifically at CockroachDB’s operations and deployment model, and explored how rebalancing, repair, and symmetric nodes combine to create both simple deployment and a strong recovery story. He then explored how you can both contribute to it and use it to build scalable, resilient applications that can be deployed to any cloud infrastructure.

Percona’s EMEA Field Marketing Manager Kamal Taibi was able to chat with Marc, and get better insight into his talk. Check it out below!

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com