Last week at re:Invent 2019, AWS CEO Andy Jassy announced the launch of the preview for the new Amazon Managed Apache Cassandra service (MCS). But what exactly is it, and why should you care?
Apache Cassandra is a free, datacenter scale No SQL database, originally designed by Facebook engineers to power the Facebook Inbox Search feature, and then later open sourced by Facebook. Apache Cassandra is designed to manage huge datasets across commodity server clusters, providing high availability with no single points of failure. Asynchronous replication between datacenters ensures low latency performance and the ability to lose an entire datacenter without loss of data.
According to DB-Engines ranking, Cassandra is the 10th most popular database, and the most popular wide column format database.
5 Key Challenges running Cassandra...
Despite the popularity of Cassandra, it is notoriously difficult to set up and manage. Some common challenges that Cassandra developers and administrators encounter include:
Read Time Degradation – when data is deleted from Cassandra, it is not immediately deleted from disk – instead it is replaced with a ‘Tombstone’ – a marker to show that the data has been deleted. The default duration for a tombstone is 10 days, but in certain circumstances they may not be deleted at all. Tombstones can affect read performance in a database that is filling up rapidly.
Slow nodes can bring down the cluster – slow nodes can be caused by slow network connectivity, saturated hardware or a mismatch between the data stream and the schema.
Failed operations – chunks of data can get ‘stuck’ due to latency issues which can be caused by hardware being unable to handle the volume of triggers – either due to the hardware being under specified or the software relaying incorrect triggers.
High Frequency of read round trips – due to the design of Cassandra it is common for transactions to occur which make too many requests per end user. These transactions attempt to read too much data from the database which can slow the transaction down.
Planning for peak capacity – if your database workloads experience busy peaks, then the cluster capacity needs to be scaled to handle those peaks – this can be a tricky capacity planning exercise, particularly with a rapidly growing database.
Enter Amazon MCS...
If you are an Apache Cassandra user and the above issues sound familiar, then you should take a serious look at the new Amazon Managed Cassandra Service. MCS enables AWS customers to operate Cassandra at scale.
The MCS preview is available in the following regions:
US East (N. Virginia)
US East (Ohio)
Asia Pacific (Singapore)
Asia Pacific (Tokyo)
The benefits of MCS include:
- Apache Cassandra-compatible (release 3.11) – The Amazon MCS service implements the Cassandra Cassandra Query Language API, so existing Cassandra users simply need to update their application endpoint to start using the MCS service. Customers can use the same Cassandra drivers and tools for easy migration.
- Serverless – no clusters to manage – you will no longer need to provision, patch or manage servers as your database grows – you can focus on building your application. And as with most AWS services, you pay only for the resources you use, so you you don’t need to worry about capacity planning or peaks and troughs in workloads. You can simply log on to the service and create a key store and tables without worrying about infrastructure.
- Single digit millisecond performance at any scale – MCS customers can build applications that have access to virtually limitless throughput and storage that can handle thousands of requests per second.
- Integrated with IAM with Amazon Cloudwatch, Amazon VPC and AWS Key Management – making Amazon MCS secure, yet easy to integrate and manage.
But beware the Key functional Differences...
Despite the MCS preview looking impressive, AWS themselves highlight some key functional differences between MCS and Apache Cassandra, and if you are a current open source user it is important to bear these in mind:
- No multi-region support
- No UDT
- No ALTER TABLE
- No counters
- No materialized views
- No ability to load SSTables directly
If you are managing Cassandra at scale and are familiar with the challenges highlighted in this post, then MCS is worth a serious look, as long as you can live with the key functional differences. While MCS is Pay-as-You-Go, it doesn’t come cheap at $1.45 per million writes which can soon add up if you are operating at scale. However, like with all AWS Managed Services you will need to consider the total cost of ownership of a self managed cluster versus Amazon MCS, taking into account peaks and troughs in database workload, facilities and hardware management and engineering resource.