Cassandra
Data Modeling
Database Schema
NoSQL
Schema Migration

Suggest Cassandra data model for an existing schema

System Design practice on Codemia

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

Practice system design

Introduction

Designing an effective data model for Cassandra is essential to leverage its scalability and performance benefits. Cassandra is a distributed NoSQL database designed for handling large amounts of data across many commodity servers. It provides high availability with no single point of failure. Although it requires a shift in design thinking from traditional relational databases, with the right strategy, it can accommodate complex and dynamic data with ease.

This article details how to model a simple existing schema into a Cassandra data model, providing technical insights and examples throughout the process.

Understanding Existing Schema

Consider an example of a relational database schema for an online bookstore:

  • Books Table
    • book_id: Primary Key
    • title: Text
    • author: Foreign Key to Authors table
    • publish_date: Date
    • genre: Text
  • Authors Table
    • author_id: Primary Key
    • name: Text
    • nationality: Text
  • Orders Table
    • order_id: Primary Key
    • customer_id: Foreign Key to Customers table
    • book_id: Foreign Key to Books table
    • order_date: Date
  • Customers Table
    • customer_id: Primary Key
    • name: Text
    • email: Text

Data Modeling in Cassandra

For successful Cassandra schema design, it's important to understand that it's query-driven, rather than entity-driven:

Principles of Cassandra Data Modeling

  1. Query-Driven Approach:
    Focus on queries instead of entities. In Cassandra, the schema should be driven by queries you'll execute against the data store.
  2. Denormalize Data:
    Unlike relational databases, Cassandra prefers denormalization and data duplication to improve performance. The cost of writes is low due to high throughput, making redundancy less of a concern.
  3. Define Partition and Clustering Keys:
    • Partition Key: Determines which node stores the data.
    • Clustering Columns: Define how data is sorted within a partition.
  4. Use Composite Keys for Row Uniqueness:
    Combine partition and clustering keys to uniquely identify rows.
  5. Avoid Joins:
    Joins are expensive and are best avoided by spreading the necessary data across tables.

Example Data Model for Bookstore

Books by Genre and Title

cql
1CREATE TABLE books_by_genre_and_title (
2    genre TEXT,
3    title TEXT,
4    book_id UUID,
5    author_id UUID,
6    publish_date DATE,
7    PRIMARY KEY (genre, title)
8);
  • Partition Key: genre
  • Clustering Key: title

This table allows fast lookups of books by genre and title within a genre.

Orders by Customer and Date

cql
1CREATE TABLE orders_by_customer_and_date (
2    customer_id UUID,
3    order_date DATE,
4    order_id UUID,
5    book_id UUID,
6    PRIMARY KEY (customer_id, order_date)
7) WITH CLUSTERING ORDER BY (order_date DESC);
  • Partition Key: customer_id
  • Clustering Key: order_date

This allows retrieving a customer's orders sorted by most recent.

Summary Table

Below is a summary table detailing key points of the suggested Cassandra data model:

Table NamePartition KeyClustering KeyUse Case
books_by_genre_and_titlegenretitleFast retrieval of books by genre/title
orders_by_customer_and_datecustomer_idorder_dateCustomer orders in chronological order

Optimizations and Considerations

Data Duplication Trade-off

Denormalization results in data duplication. While this leads to efficient read performance, storage costs and write overheads can increase. However, given Cassandra’s architecture, distributing data to optimize read patterns is crucial.

Tunable Consistency

Cassandra allows clients to tune the consistency level. Depending on the application's need for immediate consistency vs. eventual consistency, you can adjust how reads and writes are acknowledged across servers.

Backup and Restore

Unlike traditional databases that use complete daily backups, Cassandra provides an efficient way of Incremental Backup. However, ensure regular backup strategies to prevent data loss due to node failures.

Anti-patterns to Avoid

  • Distributing data unevenly, which may lead to hotspots.
  • Designing a schema without understanding your access patterns very clearly.
  • Over-reliance on secondary indexes, which can induce high latency.

Conclusion

Migrating to Cassandra involves understanding its architecture and adopting a query-centric design approach. By prioritizing query patterns over entity normalization, the resulting data model can provide efficient and highly scalable read/write operations. While Cassandra requires a somewhat different design philosophy compared to traditional RDBMS, mastering it can unlock the potential for high-throughput data applications.


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.