The Dulin Report

 

[caption id="attachment_165" align="aligncenter" width="584"] Things to Consider.[/caption]

1. Do you know what your queries will look like ?

In traditional SQL you design your data model to represent your business objects. Your queries can then evolve over time and can be ad-hoc. You can even create views, materialized or otherwise, to facilitate even more complex analytical queries.

Cassandra does not offer the flexibility of traditional SQL. While your data model can evolve over time and you are not tied to a hard schema, you have to design your data model around the queries you plan to run. The problem with that approach is that it is very rare for end users to say with certainty what they want. Over time their needs change and so do the queries they want to run. Changes to the storage model in Cassandra involve running massive data reloads.

2. What is your team's skillset ?

Consider the human factor. Ability to get to the application's data and build reports and run analytical queries is critical to developer and business user productivity. This is often overlooked but it can mean a difference between delivering features in days vs. weeks.

Not all developers are created equal. SQL is a widely accepted and simple query language that business users should be capable of learning and using. Yet, many have trouble with even the simplest SQL. Introducing a whole new mechanism for querying their data, even if it is as mockingly similar to SQL as CQL, could be a problem.

Traditional SQL databases have well established libraries and tool sets. While other platforms are supported, Java is the primary target platform for Cassandra. Cassandra itself is written in Java, and the vast majority of tools and client libraries for it are written in Java. Running and operating a Cassandra cluster requires understanding of JVM intracacies, such as garbage collection.

3. What is your anticipated amount of data ?

Consider whether the amount of data you expect to store justifies entirely new way of thinking about your data. Cassandra was conceived at the time when multi-core SSD-backed servers were expensive, and Amazon EC2 was in its infancy.

A single modern multi-core SSD-backed server running PostgreSQL or MySQL can offer a good balance of performance and query flexibility. AWS RDS is available up to 3 Terabytes. Both PostgreSQL and MySQL can easily handle tables hundreds of gigabytes in size.

4. What are your anticipated write performance requirements ?

In Cassandra, all writes are O(1) and do not require a read-before-write pattern. You write your data, it gets stored into commit log and control is returned back to your application. Eventually it is available for reads, usually very quickly.

In SQL, things are little more complex. If the tables are indexed all writes require a lookup in the index, which in most cases is a O(log(n)) operation (n is the number of unique values in the index). Over time this is going to slow down writes. The writes are equally performant as reads.

5. What is the type of data you plan on storing ?

Cassandra has some advantages over traditional SQL when it comes to storing certain types of data. Ordered sets and logs are one such case. Set-style data structures in SQL require a read-before-write (aka upsert). Logs to be analyzed at a later point using another set of tools can take advantage of Cassandra's high write throughput.

One has to be cautious about frequently updated data in Cassandra. Compactions are un-predictable and repeatedly updating your data is going to introduce read performance penalties and increase disk storage costs.

6. What are your anticipated read performance requirements ?

Depending on the type of data you are storing, Cassandra may or may not hold advantages. Cassandra is eventually consistent, meaning that the data becomes available at some later point than when it was written. Typically it happens very quickly, but workloads where data is read almost immediately after it was written with expectation that it is exactly what was written are not appropriate for Cassandra. If that is your requirement, you need an ACID-capable database.

Any data that can be easily referred to by primary key at all times is a good fit for Cassandra. A traditional SQL database requires an index scan before it takes you to the right row. Cassandra primary key lookups are essentially O(1) operations and can work equally fast across extremely large data sets. On the other hand, secondary indices present a challenge.

7. Are you prepared for the operations costs ?

Since Cassandra is scaled by adding more nodes to the cluster operations can become quite expensive. Using an SQL database per-se doesn't solve this problem, however. The question becomes managed cloud service vs. rolling your own cluster. On-premise there is no difference between a multi-node Cassandra cluster vs an RDBMS with multiple read replicas in terms of operations and administrative costs. On-premise vs cloud is a topic for another discussion.

Amazon RDS is a managed RDBMS service. Changing the type of server, number of cores, RAM, and storage, involves simply modifying it and letting it automatically get upgraded during the maintenance window. The backups and monitoring are automatic and it requires very little of human interaction other than using the database itself. You do not need a DBA to manage it.

There are some services out there that will manage a Cassandra cluster in the cloud for you. You can and should consider these vs. rolling your own cluster. You should also consider not using Cassandra at all and see if DynamoDB meets your needs.

8. What are your burst requirements ?

The one area where Cassandra is better than DynamoDB (or other similar services) is burst performance. Cassandra's "0-60", so to speak, is instantaneous. It can handle and sustain thousands of operations per second on relatively cheap hardware.

Compared to the scaling profile of DynamoDB in AWS, Cassandra has an upper hand. While DynamoDB can be autoscaled, the autoscaling action can take minutes or hours to complete. In the meantime, your users suffer. With DynamoDB you are stuck with either paying a premium for always-on capacity or you have to come up with clever ways to work around it.

A relational OLTP database may meet your requirements here, however. Even managed service like AWS RDS can handle short bursts of read/write IOPS that are over the provisioned limit and then they get gracefully throttled back.

9. Are you installing on-premise or in the cloud ?

Compared to cloud environments, your options on-premises are limited. You don't have managed services like DynamoDB, RDS, or RedShift. Hardware and maintenance costs of a Cassandra cluster compared to a similarly sized RDBMS cluster are going to be about the same.

In the cloud environment, however, you are in a much better position to make the right decision. You have managed options like Google Big-Table, DynamoDB and RDS.

10. What are your disaster recovery requirements ?

Cassandra can play a crucial role in your design for failure because all data centers can be kept hot without the need for a master-slave failover. That type of a configuration is a lot more complex to achieve with an SQL database. SQL gives you consistency, while Cassandra gives you partition-tolerance.

Conclusion

Cassandra is constantly evolving, as are traditional databases and managed cloud services. What I see happening is convergence of functionality. There is a lot of cross pollination of ideas going on in the industry with NoSQL databases adopting some of the SQL functionality (think: Cassandra CQL and SQL) and SQL databases adopting some of the NoSQL functionality (think: PostgreSQL NoSQL features). It is important to keep a cool head and not jump on any new tech without understanding your use cases and skill sets.