Need advice about which tool to choose?Ask the StackShare community!
Cassandra vs FoundationDB: What are the differences?
Key Differences between Cassandra and FoundationDB
Cassandra and FoundationDB are both highly scalable distributed databases that offer different features and functionalities. Here are the key differences between them:
Data Model: Cassandra is a wide-column store database that follows a key-value data model. It is based on the key-value store concept, where each row has a primary key and multiple columns with values. On the other hand, FoundationDB is a key-value store database that follows a document data model. It supports advanced data structures like JSON or nested documents, allowing for more complex data representation and querying.
Consistency Model: Cassandra follows a tunable consistency model known as eventual consistency. It prioritizes high availability and partition tolerance over strong consistency, allowing for fast and scalable operations. FoundationDB, on the other hand, follows a strongly consistent model by default. It ensures that all clients see the same data at the same time, providing strong guarantees for correctness and integrity.
Scalability: Both Cassandra and FoundationDB are designed to scale horizontally. However, Cassandra provides a more seamless and auto-sharding approach to handle large datasets and high traffic loads. It employs a shared-nothing architecture with peer-to-peer replication, allowing for easy addition and removal of nodes. FoundationDB also supports horizontal scalability, but it requires explicit partitioning of data to distribute it across multiple nodes.
Conflict Resolution: In the case of concurrent updates or conflicts, Cassandra uses a last-write-wins conflict resolution strategy. The most recent write will overwrite the previous values. On the other hand, FoundationDB uses multi-version concurrency control (MVCC) to handle conflicts. It keeps track of different versions of a value and enables clients to resolve conflicts based on their specific requirements.
Transactions: Cassandra has limited support for transactions that only span a single partition. It does not provide support for distributed ACID transactions. In contrast, FoundationDB provides full support for distributed ACID transactions, allowing multiple operations across different keys or key ranges to be executed atomically.
Query Language: Cassandra uses Cassandra Query Language (CQL), which is a SQL-like language with some extensions specific to Cassandra's data model. It allows for basic CRUD operations, as well as filtering and aggregation. FoundationDB does not have a specific query language but provides client libraries and APIs that allow developers to build their own query interface using their preferred programming language.
In summary, Cassandra is a wide-column store with eventual consistency, while FoundationDB is a key-value store with strong consistency. Cassandra prioritizes scalability and high availability, while FoundationDB focuses on strong consistency and ACID transactions. The choice between the two depends on the specific requirements of the application, data model complexity, and the need for transactional guarantees.
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.
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
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.
i love syclla for pet projects however it's license which is based on server model is an issue. thus i recommend cassandra
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.
Fauna is a serverless database where you store data as JSON. Also, you have build in a HTTP GraphQL interface with a full authentication & authorization layer. That means you can skip your Backend and call it directly from the Frontend. With the power, that you can write data transformation function within Fauna with her own language called FQL, we're getting a blazing fast application.
Also, Fauna takes care about scaling and backups (All data are sharded on three different locations on the globe). That means we can fully focus on writing business logic and don't have to worry anymore about infrastructure.
So, we started using foundationDB for an OLAP system although the inbuilt tools for some core things like aggregation and filtering were negligible, with the high through put of the DB, we were able to handle it on the application. The system has been running pretty well for the past 6 months, although the data load isn’t very high yet, the performance is fairly promising
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
Pros of FoundationDB
- ACID transactions6
- Linear scalability5
- Multi-model database3
- Key-Value Store3
- Great Foundation3
- SQL Layer1
Sign up to add or upvote prosMake informed product decisions
Cons of Cassandra
- Reliability of replication3
- Size1
- Updates1
Cons of FoundationDB
Sign up to add or upvote consMake informed product decisions
What is Cassandra?
What is FoundationDB?
Need advice about which tool to choose?Ask the StackShare community!
What companies use FoundationDB?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with FoundationDB?
Sign up to get full access to all the tool integrationsMake informed product decisions
Blog Posts
+5
+17
+42
+26