As DataStax' Astra DB gains in popularity, many existing applications written for DataStax Enterprise (DSE) or Apache Cassandra are being migrated to Astra DB. At Data Aces, we have worked on several such Astra Migration Projects. One of the first questions that comes up is "how much of my existing code do I have to change?"
While there are the obvious ones such as differences between the Datastax driver connection and Astra’s secure connect bundle, this post focuses on a more nuanced issue around Consistency Levels.
Consistency Levels in Cassandra
Cassandra famously has ‘tunable consistency’ which means that we can set consistency at an application level, or even at a per request (read or write) level if we choose to. Hence, when migrating apps, it is critical to know which of our Cassandra CLs are supported in Astra and which ones require code changes. When we did our first large conversion project from DSE to Astra DB, we looked up the Datastax documentation for Astra and this is what we found:
The client application configures the consistency level per request to manage response time versus data accuracy. By tracing activity on a five-node cluster, this tutorial shows the difference between these consistency levels and the number of replicas that participate to satisfy a request:
ONE
Returns data from the nearest replica.
QUORUM
Returns the most recent data from the majority of replicas.
ALL
Returns the most recent data from all replicas.
Follow instructions to set up five nodes on your local computer, trace reads at different consistency levels, and then compare the results.
The ONE Consistency Level
The above documentations seems to suggest that One consistency level is supported in Astra but the very first time we tried a query, we got the following error:
The TWO Consistency Level
In our project, there was a lot of existing code written with LOCAL_QUORUM and TWO consistency levels. The documentation made no mention of the support for these levels in Astra DB. This raised the issue of whether we needed to change the existing code for the Astra migration. The impact of this would be huge, because the Astra migration project involved 30 different java and python applications as well as over 100 spark jobs !
With so much at stake, we decided to write a small program and try out all the consistency levels in DSE and Astra. Interestingly, we found that the results were different for reads vs writes, even though the above documentation link makes no mention of it.
Write Consistency in Astra DB
Using the python driver for AstraDB, we created queries to write data into an empty Astra DB table. We tested the following Consistency Levels:
ANY, ALL, ONE, TWO, THREE, LOCAL_ONE, QUORUM, LOCAL_QUORUM, EACH_QUORUM for writes into Astra DB.
Here is a code snippet for a portion of the write test. A row in the test table is inserted along with the consistency level being tested::
Here are the result rows in the table after execution. We can see that the consistency levels LOCAL_QUORUM and TWO (which were used heavily in our applications) are supported. However, a few others are missing - but we will get to that later.
Read Consistency in Astra DB
Using the python driver for Astra DB, we created a query to read data from a table using all the following Consistency Levels: ANY, ALL, ONE, TWO, THREE, LOCAL_ONE, QUORUM, LOCAL_QUORUM, EACH_QUORUM
Here is the code snippet for the query:
Test Results for Consistency in Astra DB
The interesting result here is that there is a difference between the consistency levels supported when performing reads and writes. Specifically, when using ONE, LOCAL_ONE, and ANY consistency levels for writes, we encountered the following error: “disallowed values are: [ANY, ONE, LOCAL_ONE]”.
When using the ANY consistency level for reads, we encountered the following error: “ANY ConsistencyLevel is only supported for writes".
Conclusion
The result from this testing was overall very positive – we were able to verify that both LOCAL_QUORUM and TWO consistency level queries are successful with Astra DB (even though these are not mentioned in the documentation), greatly reducing the amount of effort we have to spend in converting our existing code for the migration effort.
Data Aces has helped develop and migrate many Cassandra and DataStax applications to Astra DB. If you are planning on such a project, please contact us.