November 2017 Summaries

Phillip Tribble's blog post introduces the concept of a Mutant Monitoring System (MMS) designed to manage the activities of mutants, who pose a threat to society, by using a database to track their actions as mandated by the Mutant Registration Act. The system employs ScyllaDB, chosen for its high availability and fault tolerance, to create a Mutant Catalog and a Monitoring System that stores and analyzes time-series data such as location and powers. The article details the initial steps in setting up a ScyllaDB cluster using Docker and creating a keyspace for the Mutant Catalog, which records basic mutant information like name and address. The post concludes with a look forward to the development of a Tracking System in subsequent entries, emphasizing the urgency and importance of deploying the MMS to protect national security.

Zenly, a mobile application for real-time location sharing, faced challenges with their initial database, Elasticsearch, due to poor performance with update operations and difficulty in data monitoring. Although they considered Apache Cassandra as a replacement, concerns about Garbage Collection interruptions and the high costs associated with large cluster maintenance led them to choose ScyllaDB instead. ScyllaDB offered Zenly enhanced performance and lower latencies with fewer nodes, reducing operational costs, and provided a straightforward monitoring solution through a stack using Grafana and Prometheus. This switch allowed Zenly to optimize hardware usage and address their monitoring issues effectively.

Allegro Group, a leading e-commerce company in Poland, faced challenges with their existing 44-node Apache Cassandra cluster, which struggled with latency and performance issues that risked breaching their 100-millisecond service level agreement (SLA). To address these concerns, Allegro's database team, led by Lukasz Pachiarek and Szymon Szymanski, evaluated ScyllaDB as a potential solution. They found that ScyllaDB significantly outperformed Apache Cassandra in terms of maintenance tasks like cleanup, node joining, and decommissioning, as well as in production traffic scenarios. ScyllaDB's performance improvements eliminated latency spikes, allowing Allegro to maintain better response times while reducing hardware requirements, ultimately replacing their 44-node Cassandra cluster with a more efficient 16-node ScyllaDB setup. This transition not only enhanced their system's efficiency but also aligned with Allegro's need for faster response times to meet customer expectations and protect sales.

Snapfish, a leading photo retail company with over 100 million members and extensive data storage needs, sought to improve its database performance and scalability by evaluating ScyllaDB as an alternative to their current system. Faced with the challenge of processing high volumes during peak periods, Snapfish found ScyllaDB to be significantly more efficient in hardware management and performance, achieving five times faster operations than their existing setup. The transition to ScyllaDB was deemed straightforward due to its compatibility with Snapfish's required functions and features, and it also promised cost savings through lower licensing fees compared to their previous technology. Their positive evaluation results were shared at the ScyllaDB Summit 2017, highlighting ScyllaDB as a powerful NoSQL database solution.

ScyllaDB Enterprise 2017.1.2 is a minor release of the production-ready ScyllaDB Enterprise, designed to fix bugs in the 2017.1 branch, which is built on the open-source ScyllaDB 1.6 and incorporates backported bug fixes from versions 1.7, 2.0, and 2.1 alongside enterprise-specific fixes. Notable bug fixes include resolving a rare race condition, preventing repairs until nodes reach a NORMAL status, addressing long latencies caused by generating sstable sharding metadata, and fixing issues with nodetool refresh and coordinator-side speculative retries. Additionally, the release introduces new tools such as scyllarepair, a recurrent repair script, and detectors for stalling and large allocations, which are intended to assist the support team in identifying potential issues. ScyllaDB Enterprise customers are encouraged to upgrade to this version and can reach out to the support team with any questions.

ScyllaDB 2.0.1, released by the ScyllaDB team on November 17, 2017, is a bugfix update within the 2.0 stable branch, maintaining backward compatibility and supporting rolling upgrades. Transitioning from version 1.7.x requires users to refer to the 2.0 release notes, particularly since upgrades are only viable from version 1.7.4 or later, and older driver versions are no longer supported. Key issues addressed include the lack of visibility of resharding compaction statistics in monitoring tools, potential data loss in large clusters due to slow gossip state propagation, incorrect data reads under certain conditions, and cache issues during range deletions. Users are encouraged to report any encountered problems to facilitate further improvements.

ScyllaDB emphasizes optimizing query performance through a series of strategies, as discussed by Shlomi Livne at a ScyllaDB Summit. Livne, with a background in performance and integration from his previous role at Oracle, presented seven rules to enhance ScyllaDB query execution. Key strategies include using prepared statements to reduce repetitive work, enabling paging to manage large data sets efficiently, and selecting appropriate page sizes based on row size for optimal performance. Additionally, he advises caution with multi-partition CQL IN queries and suggests splitting them into single-partition queries for better latency. For full scans, leveraging token ownership and sharding can expedite processes by utilizing all machine cores in parallel. Finally, utilizing various tools such as probabilistic tracing and CQL tracing can aid in troubleshooting and benchmarking the performance of ScyllaDB queries.

Hinted Handoff is a feature introduced in ScyllaDB 2.1 to address the issue of data inconsistency caused by write failures when replica nodes become unresponsive. This feature allows the coordinator node to store a "hint" whenever it fails to write to a replica, enabling it to later send this hint to the recovered replica to ensure data consistency. While Hinted Handoff reduces inconsistency and speeds up synchronization, it does not eliminate the need for running repair operations, as it operates on a best-effort basis without guaranteeing complete data consistency. The feature is configurable through parameters such as enabling hints for specific data centers, setting a maximum hint window, and specifying a storage directory for hints. Although it mimics the Apache Cassandra implementation, ScyllaDB's version ensures that hints do not consume excessive disk space, and it does not count hints towards the consistency level, except under specific conditions.

Alex Gallego, a principal engineer at Akamai’s Platform Group, presented a session titled "SMF: The Fastest RPC in the West" at the ScyllaDB Summit, focusing on the development of SMF, a Remote Procedure Call (RPC) framework designed to achieve microsecond tail latency. Drawing on his experience as the founder and CTO of Concord.io, a distributed stream processing engine built in C++ for enhanced performance, Gallego highlighted the limitations of existing open-source queues in handling high traffic and explained how SMF addresses these challenges. SMF is built on the Seastar framework, which is also used by ScyllaDB, and Gallego shared benchmarks demonstrating significant improvements in tail latency compared to other RPC systems. The session offered attendees a user-centric walkthrough of SMF's internals and emphasized its potential for high-performance computing environments.

Migrating from Apache Cassandra to ScyllaDB offers significant performance improvements, including a 10x increase and better latency, with the migration process designed to ensure zero downtime. The migration involves four key phases: dual writes to update application logic for both databases, forklifting historical data with sstableloader, dual reads to validate ongoing data synchronization, and phasing out the old Apache Cassandra database. ScyllaDB provides comprehensive documentation to guide users through these steps, along with resources to understand its architecture, consistency levels, and CQL modeling. Users are encouraged to explore ScyllaDB through demos, live performance tests, and performance comparison blogs to fully appreciate its benefits over Apache Cassandra.

ScyllaDB's blog post introduces a console demo designed to help users understand and experiment with the concept of consistency levels in ScyllaDB using practical, hands-on examples. The demo, accessible via asciinema.org's sharable terminal sessions, provides step-by-step guidance on setting up a multi-node cluster with Docker, running CQLSH, setting consistency levels, creating keyspaces and tables, enabling tracing, and performing basic read and write operations. It illustrates how changes in consistency levels and node failures affect these operations, offering users an interactive way to explore ScyllaDB's fault tolerance and ring architecture. The blog encourages trying out the demo and further exploring ScyllaDB's capabilities through various resources, including documentation, tutorials, and live performance tests.

ScyllaDB and Apache Cassandra utilize different strategies for implementing secondary indexes, which are crucial for efficient data retrieval on non-partition keys. While Apache Cassandra employs local indexing, where indexes are stored on the same node as the data, ScyllaDB leverages global indexing, creating a Materialized View for each index that uses the indexed column as the partition key. This approach enhances read scalability by breaking queries into two parts: querying the index table and then retrieving data from the indexed table. However, it introduces slower write performance due to the overhead of maintaining the index view. Secondary indexes are generally transparent to applications, allowing for flexibility in querying columns with less storage overhead compared to Materialized Views. The choice between using secondary indexes or Materialized Views largely depends on application requirements, with Materialized Views offering maximum performance for fixed column queries, while secondary indexes provide adaptability for querying various column sets.