Need advice about which tool to choose?Ask the StackShare community!
Cassandra vs Presto: What are the differences?
Key Differences between Cassandra and Presto
Cassandra and Presto are two widely used technologies in the field of data storage and processing. While they both serve different purposes and have unique features, it is important to understand their key differences.
-
Data Storage Model:
- Cassandra: Cassandra follows a distributed and decentralized data storage model. It uses a NoSQL approach and is designed for high scalability, allowing the storage and retrieval of large amounts of structured and unstructured data across multiple nodes.
- Presto: Presto, on the other hand, is not a data storage system but rather a distributed SQL query engine. It provides a unified interface to query data from multiple data sources, such as Cassandra, Hadoop, and relational databases, and is optimized for interactive and ad-hoc query performance.
-
Data Consistency:
- Cassandra: Cassandra offers eventual consistency, meaning that updates to the data may take some time to propagate across all nodes. It prioritizes availability and partition tolerance in the CAP theorem, making it suitable for use cases where high availability is critical, but data consistency can be relaxed.
- Presto: Presto emphasizes strong consistency by default. It uses the read-committed isolation level, ensuring that each query sees a consistent snapshot of the data at a specific point in time. It is better suited for use cases where data consistency is of utmost importance.
-
Query Language Support:
- Cassandra: Cassandra uses its own query language called Cassandra Query Language (CQL), which is a simplified version of SQL. It is optimized for fast writes and supports limited querying capabilities, such as basic CRUD operations and simple aggregations.
- Presto: Presto supports a wide range of SQL functionalities, making it easier for users who are already familiar with SQL to write complex queries. It provides advanced query features, including joins, subqueries, window functions, and complex aggregations.
-
Data Processing Paradigm:
- Cassandra: Cassandra is designed for high-speed writes and efficient storage of large amounts of data. Its data model is based on a wide-column store and it excels at write-intensive workloads, making it suitable for scenarios that require fast data ingestion and constant updates.
- Presto: Presto is optimized for fast data processing and is capable of executing complex analytical queries on large datasets. It follows a memory-based processing model, where data is stored and processed in-memory, enabling high-performance analytics and real-time querying.
-
Scalability and Flexibility:
- Cassandra: Cassandra is highly scalable and can handle a massive amount of data and user requests by adding more nodes to the cluster. It offers automatic data distribution and replication, allowing seamless expansion and fault tolerance.
- Presto: Presto is designed to be highly elastic and can scale up and down based on the workload demands. It supports dynamic allocation of computational resources and can efficiently utilize the available resources to handle varying query workloads.
-
Data Sources and Integration:
- Cassandra: Cassandra primarily serves as a self-contained database system and can be used as a standalone solution for storing and querying data. It has limited integration capabilities with other data sources and mostly focuses on its own data storage mechanisms.
- Presto: Presto acts as a bridge between various data sources, including Cassandra, and enables seamless querying across multiple data repositories. It provides connectors and connectors to integrate with different databases, data lakes, and big data platforms.
In summary, Cassandra is a highly scalable distributed data storage system with eventual consistency, optimized for write-intensive workloads, while Presto is a distributed SQL query engine focused on strong consistency and high-performance analytics on a variety of data sources.
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.
To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.
Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.
We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.
Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.
Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.
#BigData #AWS #DataScience #DataEngineering
The platform deals with time series data from sensors aggregated against things( event data that originates at periodic intervals). We use Cassandra as our distributed database to store time series data. Aggregated data insights from Cassandra is delivered as web API for consumption from other applications. Presto as a distributed sql querying engine, can provide a faster execution time provided the queries are tuned for proper distribution across the cluster. Another objective that we had was to combine Cassandra table data with other business data from RDBMS or other big data systems where presto through its connector architecture would have opened up a whole lot of options for us.
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 Presto
- Works directly on files in s3 (no ETL)18
- Open-source13
- Join multiple databases12
- Scalable10
- Gets ready in minutes7
- MPP6
Sign up to add or upvote prosMake informed product decisions
Cons of Cassandra
- Reliability of replication3
- Size1
- Updates1