ScyllaDB
Query Efficiency
Big Data
Database Management
High Cardinality

Efficiency of Querying 10 Billion Rows (with High Cardinality) in ScyllaDB

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

Querying large datasets with high cardinality can be a challenging task that requires a database management system (DBMS) optimized for high performance and scalability. ScyllaDB, often regarded as one of the most performant NoSQL databases, is particularly well-suited to handling large volumes of data efficiently. This article explores the efficiency of querying 10 billion rows with high cardinality in ScyllaDB, looking at its architecture, design patterns, and specific features that help achieve high performance.

Understanding ScyllaDB's Architecture

ScyllaDB is an open-source NoSQL database engineered to provide very high throughput and low latencies. It is a close-to-the-metal reimplementation of Apache Cassandra, designed to handle large-scale operations on commodity hardware. The core advantages of ScyllaDB’s architecture include:

  • Shared Nothing Architecture: Each node in the cluster is independent, which minimizes the overhead of coordination between nodes.
  • Shard-per-Core Approach: ScyllaDB assigns a shard per CPU core, ensuring that each core handles a distinct partition of data with its own querying, compaction, and caching. This maximizes the use of hardware and prevents resource contentions.
  • Asynchronous Non-blocking Design: ScyllaDB uses an asynchronous programming model and does not block threads on I/O operations. This helps to better utilize CPU and I/O resources without getting bogged down by slow disk operations.

Indexing and Data Modelling for High Cardinality

High cardinality data implies that there are large numbers of unique values in columns that are typically used as keys or indexes. Efficient querying of such datasets in ScyllaDB involves careful data modeling:

  • Partitioning: Choose partition keys that divide your data evenly across nodes. This reduces hotspots and balances the load, leveraging ScyllaDB’s horizontal scaling capabilities.
  • Clustering Columns: Use clustering columns to order data within partitions, optimizing access patterns for range queries.
  • Secondary Indexing: ScyllaDB supports secondary indexes for attributes that are frequently queried. However, these should be used judiciously, especially with high cardinality, as they can lead to performance degradation if not properly designed.

Performance Tuning and Optimization

To maximize query performance over large datasets, consider the following techniques:

  • Data Compaction Strategies: ScyllaDB offers several compaction strategies (like Size-Tiered, Leveled, and TimeWindowCompactionStrategy) that optimize how data is stored and accessed on disk.
  • Caching: ScyllaDB includes a sophisticated caching mechanism that keeps frequently accessed data in RAM. Configuring cache sizes and eviction policies can significantly impact response times.
  • Consistency and Replication: Adjusting consistency levels can also affect performance. For example, using a consistency level of QUORUM requires coordination between multiple nodes, which can be slower than using ONE or LOCAL_ONE, where fewer replicas are consulted.

Query Performance Example

Consider querying a user activity dataset with 10 billion rows, with each row representing a single activity by a user. If you want to find all activities by a specific user within a timeframe, you might model your data with user_id as the partition key and timestamp as the clustering column:

sql
1CREATE TABLE activities (
2    user_id UUID,
3    timestamp TIMESTAMP,
4    activity_type TEXT,
5    data TEXT,
6    PRIMARY KEY (user_id, timestamp)
7) WITH CLUSTERING ORDER BY (timestamp DESC);

This setup allows efficient retrieval of recent activities by a specific user, leveraging both partitioning and clustering.

Benchmarks and Real-world Use Cases

Benchmarks conducted on ScyllaDB with similarly sized datasets have consistently shown that it can handle hundreds of thousands of operations per second, per node, with latencies in the range of milliseconds. Real-world implementations, such as those by Comcast and Samsung SDS, demonstrate ScyllaDB handling billions of daily transactions efficiently.

Summary Table

AspectDetail
ArchitectureShared nothing, shard-per-core, asynchronous non-blocking
Data ModelingPartition keys, clustering columns, judicious use of indexes
Performance OptimizationCompaction strategies, caching, consistency levels
Real-world BenchmarkHundreds of thousands ops/sec, millisecond latencies

In conclusion, querying 10 billion rows with high cardinality in ScyllaDB can be highly efficient provided that the database is properly modeled and configured. Effective use of ScyllaDB’s features like shard-per-core architecture and compaction strategies can deal with the challenges posed by large, high-cardinality datasets. As with any large-scale system, continuous monitoring, tuning, and optimization ensure that the system remains performant as it scales.


Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.