Need advice about which tool to choose?Ask the StackShare community!
Amazon DynamoDB vs Cassandra: What are the differences?
Data Model: Amazon DynamoDB uses a NoSQL data model, specifically a key-value pair model, where each item is uniquely identified by a primary key. Cassandra, on the other hand, utilizes a column-family data model, which allows for more flexible schema design and faster querying by columns.
Consistency Model: DynamoDB offers strong consistency, ensuring that when a read operation is performed, the latest version of an item is always returned. In contrast, Cassandra provides tunable consistency, allowing users to choose their desired level of consistency, trading off performance for data accuracy.
Scalability: DynamoDB is fully managed by Amazon Web Services (AWS) and automatically scales horizontally to handle any amount of traffic or data, making it highly scalable. Cassandra also provides scalability through its distributed architecture, but it requires manual configuration and monitoring to ensure efficient scaling.
Secondary Indexes: DynamoDB provides built-in support for secondary indexes, allowing users to query data using non-primary key attributes. Cassandra, on the other hand, requires users to design and manage their own secondary indexes, which can be more complex and error-prone.
Query Language: DynamoDB uses AWS SDKs or API to interact with the database, whereas Cassandra provides its own query language called CQL (Cassandra Query Language), which is similar to SQL and allows for more expressive and relational-like querying.
Durability and Availability: DynamoDB offers automatic data replication and multi-AZ deployments, ensuring high durability and availability. In contrast, Cassandra requires manual configuration for data replication and does not provide built-in multi-AZ support, requiring users to handle replication and fault-tolerance themselves.
In Summary, Amazon DynamoDB and Cassandra differ in their data models, consistency models, scalability approaches, secondary index support, query languages, and durability/availability features.
Developing a solution that collects Telemetry Data from different devices, nearly 1000 devices minimum and maximum 12000. Each device is sending 2 packets in 1 second. This is time-series data, and this data definition and different reports are saved on PostgreSQL. Like Building information, maintenance records, etc. I want to know about the best solution. This data is required for Math and ML to run different algorithms. Also, data is raw without definitions and information stored in PostgreSQL. Initially, I went with TimescaleDB due to PostgreSQL support, but to increase in sites, I started facing many issues with timescale DB in terms of flexibility of storing data.
My major requirement is also the replication of the database for reporting and different purposes. You may also suggest other options other than Druid and Cassandra. But an open source solution is appreciated.
Hi Umair, Did you try MongoDB. We are using MongoDB on a production environment and collecting data from devices like your scenario. We have a MongoDB cluster with three replicas. Data from devices are being written to the master node and real-time dashboard UI is using the secondary nodes for read operations. With this setup write operations are not affected by read operations too.
We are building a social media app, where users will post images, like their post, and make friends based on their interest. We are currently using Cloud Firestore and Firebase Realtime Database. We are looking for another database like Amazon DynamoDB; how much this decision can be efficient in terms of pricing and overhead?
Hi, Akash,
I wouldn't make this decision without lots more information. Cloud Firestore has a much richer metamodel (document-oriented) than Dynamo (key-value), and Dynamo seems to be particularly restrictive. That is why it is so fast. There are many needs in most applications to get lightning access to the members of a set, one set at a time. Dynamo DB is a great choice. But, social media applications generally need to be able to make long traverses across a graph. While you can make almost any metamodel act like another one, with your own custom layers on top of it, or just by writing a lot more code, it's a long way around to do that with simple key-value sets. It's hard enough to traverse across networks of collections in a document-oriented database. So, if you are moving, I think a graph-oriented database like Amazon Neptune, or, if you might want built-in reasoning, Allegro or Ontotext, would take the least programming, which is where the most cost and bugs can be avoided. Also, managed systems are also less costly in terms of people's time and system errors. It's easier to measure the costs of managed systems, so they are often seen as more costly.
The problem I have is - we need to process & change(update/insert) 55M Data every 2 min and this updated data to be available for Rest API for Filtering / Selection. Response time for Rest API should be less than 1 sec.
The most important factors for me are processing and storing time of 2 min. There need to be 2 views of Data One is for Selection & 2. Changed data.
Scylla can handle 1M/s events with a simple data model quite easily. The api to query is CQL, we have REST api but that's for control/monitoring
Cassandra is quite capable of the task, in a highly available way, given appropriate scaling of the system. Remember that updates are only inserts, and that efficient retrieval is only by key (which can be a complex key). Talking of keys, make sure that the keys are well distributed.
i love syclla for pet projects however it's license which is based on server model is an issue. thus i recommend cassandra
By 55M do you mean 55 million entity changes per 2 minutes? It is relatively high, means almost 460k per second. If I had to choose between Scylla or Cassandra, I would opt for Scylla as it is promising better performance for simple operations. However, maybe it would be worth to consider yet another alternative technology. Take into consideration required consistency, reliability and high availability and you may realize that there are more suitable once. Rest API should not be the main driver, because you can always develop the API yourself, if not supported by given technology.
6 months ago we finished migrating the Workjam channels module datastore. Reasons for the switch was frustrations with AWS read/write capacities being frequently exceeded because of unplanned explosive growth, hard limitations on batch updates and interesting Cassandra features such as consistency tuning and Datastax's Solr integration. The decision to use Cassandra might not have been the most practical one as our needs would probably have been better served by a document store such as MongoDB, as we are not dealing with intense document update operations, but Cassandra was used throughout the company and the aim of stack uniformity was favoured over functional needs. We implemented the migration with the aim of incurring no downtime and the ability to rollback by sending write commands over AMQP. Overall the migration went smoothly, the devs learned all the powers of Cassandra and got acquainted with its many constraints. Datastax's Solr integration made the search implementation very simple but we were very disappointed in some of Datastax's Solr integration limitations (ex: search highlights being deprecated).
Pros of Amazon DynamoDB
- Predictable performance and cost62
- Scalable56
- Native JSON Support35
- AWS Free Tier21
- Fast7
- No sql3
- To store data3
- Serverless2
- No Stored procedures is GOOD2
- ORM with DynamoDBMapper1
- Elastic Scalability using on-demand mode1
- Elastic Scalability using autoscaling1
- DynamoDB Stream1
Pros of Cassandra
- Distributed119
- High performance98
- High availability81
- Easy scalability74
- Replication53
- Reliable26
- Multi datacenter deployments26
- Schema optional10
- OLTP9
- Open source8
- Workload separation (via MDC)2
- Fast1
Sign up to add or upvote prosMake informed product decisions
Cons of Amazon DynamoDB
- Only sequential access for paginate data4
- Scaling1
- Document Limit Size1
Cons of Cassandra
- Reliability of replication3
- Size1
- Updates1