3. Organizing Related Data | Learning Apache Cassandra

Sign In Start Free Trial

Book Overview & Buying
Table Of Contents
Feedback & Rating

Learning Apache Cassandra

By : Brown

4.4 (13)

Learning Apache Cassandra

4.4 (13)

By: Brown

Overview of this book

If you're an application developer familiar with SQL databases such as MySQL or Postgres, and you want to explore distributed databases such as Cassandra, this is the perfect guide for you. Even if you've never worked with a distributed database before, Cassandra's intuitive programming interface coupled with the step-by-step examples in this book will have you building highly scalable persistence layers for your applications in no time.

Preface

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Free Chapter

1. Getting Up and Running with Cassandra

1. Getting Up and Running with Cassandra

What Cassandra offers, and what it doesn't

Installing Cassandra

Bootstrapping the project

Creating a keyspace

Summary

2. The First Table

2. The First Table

Creating the users table

Inserting data

Selecting data

Developing a mental model for Cassandra

Summary

3. Organizing Related Data

3. Organizing Related Data

A table for status updates

Working with status updates

Anatomy of a compound primary key

Beyond two columns

Compound keys represent parent-child relationships

Coupling parents and children using static columns

Refining our mental model

Summary

4. Beyond Key-Value Lookup

4. Beyond Key-Value Lookup

Looking up rows by partition

Retrieving status updates for a specific time range

Paginating over rows in a partition

Reversing the order of rows

Paginating over multiple partitions

Building an autocomplete function

Summary

5. Establishing Relationships

5. Establishing Relationships

Modeling follow relationships

Storing follow relationships

Looking up follow relationships

Unfollowing users

Using secondary indexes to avoid denormalization

Summary

6. Denormalizing Data for Maximum Performance

6. Denormalizing Data for Maximum Performance

A normalized approach

Partial denormalization

Fully denormalizing the home timeline

Write complexity and data integrity

Summary

7. Expanding Your Data Model

7. Expanding Your Data Model

Viewing a table schema in cqlsh

Adding columns to tables

Deleting columns

Updating the existing rows

Removing a value from a column

Inserts, updates, and upserts

Lightweight transactions have a cost

Summary

8. Collections, Tuples, and User-defined Types

8. Collections, Tuples, and User-defined Types

The problem with concurrent updates

Collection columns and concurrent updates

Using lists for ordered, nonunique values

Using maps to store key-value pairs

Collections in inserts

Collections and secondary indexes

The limitations of collections

Working with tuples

User-defined types

Choosing between tuples and user-defined types

Comparing data structures

Summary

9. Aggregating Time-Series Data

9. Aggregating Time-Series Data

Recording discrete analytics observations

Recording aggregate analytics observations

Recording analytics observations

Summary

10. How Cassandra Distributes Data

10. How Cassandra Distributes Data

Data distribution in Cassandra

Data replication in Cassandra

Consistency

Handling conflicting data

Distributed deletion

Summary

A. Peeking Under the Hood

A. Peeking Under the Hood

Using cassandra-cli

The structure of a simple primary key table

Compound primary keys in column families

Collection columns in column families

Summary

B. Authentication and Authorization

B. Authentication and Authorization

Enabling authentication and authorization

Setting up a user

Controlling access

Authorization in action

Security beyond authentication and authorization

Summary

Wrapping up

Index

Index

Customer Reviews

4.4 (13)

5 star

38.5%

4 star

61.5%

3 star

0

2 star

0

1 star

0

Anatomy of a compound primary key

At this point, it's clear that there's some nuance in the compound primary key that we're missing. Both the username column and the id column affect the order in which rows are returned; however, while the actual ordering of username is opaque, the ordering of id is meaningfully related to the information encoded in the id column.

In the lexicon of Cassandra, username is a partition key. A table's partition key groups rows together into logically related bundles. In the case of our MyStatus application, each user's timeline is a self-contained data structure, so partitioning the table by user is a sound strategy.

Note

As a general rule, you should endeavor to only query one partition at a time for any core data access your application does. Cassandra stores the rows in each partition together, so queries within a partition are very efficient. Queries across multiple partitions, on the other hand, are expensive and should be avoided.

We call the id column a clustering...

Search

Your notes and bookmarks