Cassandra Update Boosts Recovery Speeds

Apache Cassandra is a row-oriented NoSQL database created by developers working at Facebook. With elasticity as one of its key features, open source contributors have added new streaming capabilities to Cassandra 4.0 for its beta launch. These improvements have been shown to enable the database to stream data between nodes at speeds up to five times faster than in the past.

What this means is that if a node on a network crashes, for example, the data can be transferred that much more quickly to another replacement node. Conversely, during peak load data times, different nodes on the cloud or on-premises servers can more readily and quickly manage potential data overflows for improved operations elasticity, Cassandra’s contributors say.

Elasticity—or lack of—was often seen as a weak point in previous Cassandra releases. Indeed, elasticity improvements, geared for DevOps taking advantage of distributed microservices environments are “really a key point,” said Josh McKenzie, a Cassandra committer and member of the project management committee. McKenzie is also the lead of open source strategy and vice president of software engineering for DataStax, which has historically funded the bulk of Cassandra’s contributions and support.

The new streaming capability also could potentially serve as a welcome feature for database management, especially in highly distributed stateless environments of Kubernetes and microservices, said Clive Longbottom, an analyst for Longbottom Associates.

“On the first one, this seems like an excellent update. It makes the ‘eventual consistency’ of Cassandra less of an issue, and the more guaranteed timescales of recovery across a range of scenarios is welcome,” Longbottom said. “I would hope that such a major change will get more to consider Cassandra for such data work—it can be, when implemented correctly and the right jobs put on it, an effective data platform.”

The new streaming speed is made possible because the data is able to bypass the use of the servers’ CPUs, McKenzie said.  “Being able to get anywhere from four to five times the throughput when bootstrapping a new node on recovering from failure or scaling clusters up and down means the process is now a totally different ballgame.”

For DevOps teams, this means Cassandra’s modifications—including its now less complex and shorter-in-size code configurations—make for faster streaming speeds when bootstrapping a new node or during disaster data recovery. “Running repair and dealing with [server failures] means you don’t have to rebuild data so much and you can now run at line speeds as fast as your network,”   McKenzie said.

The developers also sought to reduce the number of hours spent on performing what used to be an especially onerous task of transferring data to and from different database sources in a network. Multi-cloud and mixing and matching legacy and cloud environments further complicated the process.

In other database platforms, the process of doubling database capacity can take five to seven months. Building in part on steady improvements past releases have offered, Cassandra 4.0 now can complete the process in just a few hours, McKenzie said. “I love hearing about how people can now run Cassandra with a script and it just takes maybe six hours on a Saturday morning with one person and one with one script instead of a whole weekend,” McKenzie said.”So it’s just really doubling down on those unique strengths that make Cassandra such a good fit for exactly where we are in the world today: in the state of always scrambling with massive influxes of data.”

The committee members also sought to extend the timeline of the final beta release. Instead of adding more incremental improvements while attempting to accelerate the release cycle, Cassandra’s 4.0 contributors sought “to really take our time, making sure that we were hammering down and smoothing out all the dents,” McKenzie said. “We wanted to get things to where we have a really really stable platform to iterate on very rapidly.”