In our last blog, we introduced the HCI approach that delivers the scalability and high availability inherent in the Cassandra approach. Now, we’ll discuss exactly why Cassandra runs much more efficiently on HCI 2.0 than on traditional bare-metal scale-out.

The fundamental reason why Cassandra runs so well on HCI 2.0 is directly related to the way Cassandra lays out its database, and how it handles transactions.  In database parlance, a query operation translates to doing read I/O, while an update operation translates to doing write I/O.  These I/O are structured differently.  Read I/O is very traditional, in that reads from disk are cached (in several places, or layers) of the system, with the most recently read data being ‘closest’ to the Cassandra processes themselves.  This is no different than many other databases and/or business applications.  However, writes are different; writes are first written to a specific area of memory known as a ‘memtable’, and memtables are later written to disk in a set of files known as an ‘SStable’.  Also, Cassandra, like other databases, keeps a log of transactions, known as a CommitLog; all new or updated data is first written to the CommitLog before it is applied to a memtable.

As with many databases, Cassandra can easily become I/O dominant, especially as the database grows.  Cassandra data is spread across the nodes in a technique called ‘sharding’ (which will not be explained in detail here).  Each node has a set of keys and the corresponding data values for those keys.  By design, Cassandra also replicates keys and values to more than one node on purpose, to avoid single points of failure.

In HCI 2.0, each node contains not only a large (relative to traditional servers) amount of cores to facilitate processing, but, most importantly, a significantly higher number of disks than is traditional.  For example, an HCI 2.0 node could contain as many as 144 NVMe solid-state disks (SSDs) as opposed to 6 or 12 in a traditional node.  This very high storage device density allows Cassandra to take full advantage of wide sharding, especially when combined inside virtual machines that use virtual disks, that could themselves be composed of multiple disks.

It is this storage density that enables Cassandra on HCI 2.0 to maintain extremely low latency and high throughput, simultaneously.  This translates to very quick database transactions, which in turn enable far more transactions per second.  It is not unusual to see a Cassandra cluster composed of N virtual machines on HCI 2.0 to out-perform a traditional bare-metal cluster with N servers, which in turn out-perform a Cassandra cluster composed of N virtual machines on HCI 1.0, or first-generation HCI.

Finally we can have our cake and eat it too!  Take advantage of the management simplicity of HCI, while realizing the higher levels of capability for Cassandra, all in one go.  It has taken a few years, but the promise of HCI 2.0 is real.  It’s time to begin to implement popular, open-source software on cost-effective HCI 2.0 infrastructure.

To learn more about HCI 2.0, check out the eBook: Hyper-converged Infrastructure 2.0.

We use cookies to offer you a better browsing experience. By using our site, you consent to the use of cookies. Learn more about how we use cookies in our privacy policy.