Happy holidays from ISC!
ISC is fortunate to have staff members in so many different countries around the world: our software development benefits from all the different perspectives - and we benefit personally!
Read post
Kea can use several different databases as storage “backends” for leases, host reservations, or configuration data.
The first database we integrated with was MySQL, because it offered robust clustering and was widely adopted. We added support for PostgreSQL in response to user requests, and our experience has been that PostgreSQL performs better and is currently more popular than MySQL. Kea added support for the CQL lease backend in Kea 1.1.0-beta1 and the CQL host backend in 1.4.0-beta1. These features never gained much traction with users, particularly compared to the level of interest in and deployments of the alternatives, MySQL and PostgreSQL. To date, we know of only one user for the Cassandra backend, so we are announcing plans to deprecate this feature.
What Are the Issues With Cassandra?
Unlike our other two backends, Cassandra is a non-relational NoSQL database. The non-relational nature of Cassandra makes it exceedingly difficult to implement more complex DHCP features such as the configuration backend, which requires over 20 tables of tightly coupled data that change over time and need to be kept in sync. With the Cassandra philosophy of data duplication, this requires creating and maintaining a massive number of tables. To be specific, there are 36 different types of get queries in the DHCPv4 code for the MySQL configuration backend. In the worst case, where each query requires its own table, this implies a duplication factor of over 70. This is clearly a very bad design. When we created the initial MySQL and PostgreSQL designs for the configuration backend, we also attempted to come up with a design for Cassandra, but it was a complete failure. We determined that Cassandra is simply not the right technology for this task.
Another problem with Cassandra is performance. In our performance tests MySQL and PostgreSQL were roughly 5-10 times faster than Cassandra, even though we did not do any special tuning for MySQL or PostgreSQL performance.
Cassandra setup is complicated. As of June 2021, Cassandra is not available in many major distributions. It requires custom installation, with native packages now limited to Debian only. The Debian packages available require Python 2 (which reached end-of-life on 1 Jan 2020) and uninstall some Python 3 packages. This is a very risky step in a production environment, because it removes the current 3.8 or 3.9 Python and installs an old, unsupported version. Support for Python 3 is only available in the alpha release of the upcoming Cassandra 4.0, which is not released as of July 2021. The user has a tough choice between running an antiquated version past its end of life or running unreleased alpha software. Neither option is reasonable in a production environment.
Cassandra is also very picky about the Java version. For example, on modern systems such as Ubuntu 21.04, Cassandra simply doesn’t start and produces no logs. After running Cassandra manually, it produces a cryptic “Improperly specified VM option ‘ThreadPriorityPolicy=42’” error message. This is an obscure indication that the Java version is too new (11.x) and needs to be downgraded (to 8.x).
To use C++ bindings (Kea is written in C++), a data driver is required. For a long time the data driver didn’t use the standard pkg-config approach and required custom hacking of the software detection. Compared to MySQL and PostgreSQL, which are widely available in all popular Linux and BSD distributions, setting up Cassandra is complex and the complexity is not decreasing over time.
Cassandra is also an ongoing maintenance burden. As we introduce new features in Kea, such as the ability to get database statistics that are synced between multiple Kea instances sharing the same database, we need to extend our API and we want to maintain parity between backends. Porting solutions between MySQL and PostgreSQL is frequently very easy but is almost always a problem with Cassandra. That is not a Cassandra flaw on its own; the core problem here is that it is different from the other solutions Kea supports.
Plan to Deprecate Cassandra
For these reasons, we are deprecating Cassandra support as of Kea 1.9.9. The feature will function as before in the Kea 2.0.x and 2.1.x series, but will print a warning. We plan to remove the feature entirely in a future release, possibly as soon as Kea 2.2.0.
References