July 2018 Summaries

The blog post introduces a series focusing on integrating Apache Spark and ScyllaDB, outlining key components and functionalities of both systems. Spark is described as a powerful platform for distributed data processing, utilizing Resilient Distributed Datasets (RDDs) for parallel computations across cluster nodes. The post details how to run Spark using Docker, emphasizing the importance of understanding Spark's architecture, including its execution model and the role of RDDs. ScyllaDB, a high-performance NoSQL database compatible with Cassandra, is highlighted for its efficient data management and retrieval capabilities, particularly when using the Cassandra Query Language (CQL). The post also discusses the Datastax Spark/Cassandra Connector, which facilitates data transfer between Spark and ScyllaDB, enabling users to perform complex analytical tasks by leveraging the strengths of both technologies. This initial overview sets the stage for deeper exploration of specific topics in subsequent posts.

The blog post delves into the evolution of ScyllaDB's data caching mechanisms, highlighting improvements from version 1.7 to 2.4 to address read latency and cache management issues. Initially, ScyllaDB's cache was partition-based, causing inefficiencies with large partitions due to read amplification and cache pollution. Version 2.0 introduced row-level granularity for population, mitigating these inefficiencies by allowing for partial partition caching. However, eviction remained partition-based, leading to latency spikes. Version 2.2 further refined caching by switching to row-level eviction, thus enhancing efficiency by freeing individual rows based on usage, which aids in maintaining more relevant data in cache. Additionally, version 2.4 improved latency by enabling preemptive merging of in-memory partition versions, reducing CPU blocking during such processes. Performance tests compared ScyllaDB's advancements against previous versions and Cassandra, demonstrating significant improvements in read latency and cache management, particularly under conditions where partitions exceed cache size.

ScyllaDB 2.2 introduced notable performance enhancements over its predecessor, ScyllaDB 2.1, particularly in read and write operations. In benchmarking tests, the new version achieved a 42% reduction in 99th percentile latency for reads and an 18% increase in write throughput. These improvements were attributed to changes such as switching the row digest hash from md5 to xxHash and a new CPU controller that better manages resources during high-load scenarios, such as compactions. This performance comparison highlights ScyllaDB 2.2's ability to handle workloads more efficiently, offering smoother and more consistent performance by effectively balancing system resources.

The blog post discusses the integration of Apache Spark with ScyllaDB, highlighting key considerations and best practices for deploying Spark alongside ScyllaDB. It advises against co-deploying Spark and ScyllaDB on the same nodes due to their high resource demands, recommending separate deployments to avoid resource contention. The post provides tuning tips for handling high write workloads from Spark to ScyllaDB, such as optimizing connection settings and utilizing efficient batch processing. It also recommends compressing data transfer between Spark and ScyllaDB and adjusting input split sizes to improve data fetching efficiency. The post notes that the demo uses Spark standalone mode, which is common in setups involving ScyllaDB, and encourages viewers to watch the related on-demand webinar for further insights.

ScyllaDB 2.2 introduced significant improvements in query paging by transitioning from stateless to stateful queries, addressing performance issues with large partitions and increasing throughput by up to 2.5 times. Previously, stateless paging discarded all query-related data at the end of each page, leading to redundant work and lower efficiency. The new stateful approach retains the query state across pages, reducing initialization overhead and improving resource management, particularly for disk read scenarios. This is achieved by using a "querier" object stored in a cache, which ensures that the work done for one page can be reused for subsequent pages. While the new method enhances throughput for disk reads, it required optimization for network-constrained environments where the introduction of sticky replicas initially reduced performance. Ultimately, stateful paging has demonstrated notable efficiency improvements, particularly in scenarios involving large data partitions.

ScyllaDB 2.2, a minor release of the open-source ScyllaDB database, brings notable improvements in performance and security, including Role-Based Access Control (RBAC) for enhanced security and an experimental hinted handoff feature for better cluster consistency. The release also introduces GoogleCloudSnitch support, compatibility with Apache Cassandra features, and various performance optimizations such as row-level cache eviction and improved paged single partition queries, which significantly enhance throughput and reduce latency. A new CPU scheduler and compaction controller are introduced to manage internal workloads more efficiently. However, users employing certain compaction strategies may experience reduced throughput due to resource allocation changes in the static controller. Future updates like ScyllaDB 2.3 are expected to include dynamic controllers for all compaction strategies, while ScyllaDB versions 2.0 and older will no longer receive support.

ScyllaDB has released version 2.1.6 of its open-source database, focusing on fixing critical bugs related to the caching of data in DateTiered and TimeWindow compaction strategies. This update addresses issues where partitions might appear empty until a restart, although the data remains intact on disk. The release is backward compatible, supporting rolling upgrades, and resolves additional problems with clustering key restrictions that could result in missing deletions and static row writes. Users are encouraged to upgrade as soon as possible if utilizing the mentioned compaction strategies, with various download options available for different environments, such as Docker, binary packages, and AWS AMIs.

The benchmark comparison between ScyllaDB 2.2 and Cassandra 3.11, conducted on AWS EC2, sought to evaluate the performance, cost-efficiency, and scalability of these two database systems under similar conditions. Using a workload of 38.85 billion partitions with a 50:50 read/write ratio, ScyllaDB demonstrated significant advantages over Cassandra, including a 10x reduction in administrative overhead and a 2.5x reduction in AWS EC2 costs. ScyllaDB's modern hardware utilization and linear scale-up capabilities allowed it to meet stringent latency requirements across various workloads, achieving up to 45x better 99.9th percentile latency compared to Cassandra. While Cassandra required extensive tuning to improve its performance, it still fell short in several areas, meeting the 99% latency SLA only in less demanding scenarios. The results highlighted ScyllaDB's superior ability to handle high-throughput demands with lower latency, making it a more cost-effective and efficient solution for large-scale data operations.

ScyllaDB Enterprise 2018.1.4 is a minor, production-ready release aimed at fixing critical issues related to the caching of data for DateTiered and TimeWindow compaction strategies in the ScyllaDB Enterprise NoSQL database. This update addresses a problem where partitions could appear empty until the database is restarted, though the data remains safely stored on disk. Additionally, it resolves issues where reads using clustering key restrictions might miss some deletions and static row writes. Users employing these compaction strategies are advised to upgrade promptly, coordinating with the ScyllaDB support team to ensure a smooth transition. The release is available to ScyllaDB Enterprise customers and offers a 30-day evaluation for potential new users, along with various options for deployment, including AWS, local virtual machines, and Docker.

Grab, a leading mobile platform in Southeast Asia, faced performance challenges handling over 6 million daily rides, which required near-real-time data processing to avoid significant financial losses. The company initially used Redis to aggregate data from Apache Kafka streams but encountered CPU spikes and scalability issues, prompting a switch to ScyllaDB. After extensive testing, ScyllaDB proved to be more cost-effective, easier to manage, and comparable in performance to Redis, especially in handling write-heavy operations without hot partition issues. The implementation of ScyllaDB allowed Grab to efficiently manage peak loads with a smaller cluster configuration, significantly reducing operational costs compared to other solutions like Apache Cassandra. Encouraged by these results, Grab plans to expand its use of ScyllaDB for additional applications such as statistics tracking and time series databases, with the support of ScyllaDB's responsive support team enhancing their confidence in the platform.