Architecture of the Playlist example application

The Playlist example application is a Java web application that manages a music library.

The Playlist application is a web application written in Java that can be deployed to a Java EE web container. Playlist uses a Model View Controller (MVC) design. The application model is handled by data-access objects to manage the Cassandra table data. The application view consists of JSP files that display the data. The application controller is made up of Java servlets to manage the requests from the view and the data returned from the model.



In the Playlist example, the single-node Cassandra database and the application are on the same host, which is not a typical production scenario. The design of the application allows you to easily add more nodes to the Cassandra cluster and separate the application server from the database node with minimal code changes.

Playlist components 

The Playlist example application is made up of several separate components that encapsulate the functionality of an online music service:

  • The song database: a collection of digital music files organized by artist, track name, and genre
  • User registration: creates users of the music service
  • User playlists: collections of music files created by users
  • Application statistics: overall data about the service

The data model 

The Playlist application's database tables differ significantly from the tables you typically find in a relational database application. In a typical relational database, the tables are designed based on the relations between the entities represented by each table. Creating the tables and relations to avoid duplication of data between tables is called data normalization. After the data has been completely normalized, relational database administrators and application developers write queries to retrieve the data, often using joins to find the related data in multiple tables.

Cassandra databases are designed around the type of queries used in the application. Cassandra's strength is its ability to support very fast reads and writes with large sets of data spread across many nodes in a cluster. For this reason, the database tables are denormalized: the data is broken out into different tables, and column data is often duplicated across many tables. This may seem strange to developers used to relational database applications, but it allows for much greater performance, particularly as the amount of data grows larger and nodes in the database cluster increase.

The Playlist example application uses separate tables for users, tracks organized by track name, tracks organized by artist, tracks organized by genre, artists, and playlists.

For more information on modeling data using Cassandra, see The CQL data modeling documentation.

The steps of this tutorial 

Each step in this tutorial represents a runnable version of the Playlist application, and is a branch of the Git project. Each successive step enhances the application. All the application code is updated for you at each successive step so you can concentrate on the changes in the queries and underlying Cassandra schema used in that step. All the application code changes, however, are explained as part of each step, and you can compare the changes between branches to see exactly what is different in the code.

In step 1, you will run a skeleton version of the application that simply connects to a Cassandra node in the configured cluster and displays information about the environment in which the node is running. In step 2, you will create the keyspace and tables used by the Playlist application, load the music catalog data to those tables, and enable the ability to browse through the music catalog in the web application.

In step 3, you will add the ability to mark a music track as a "hot track", using CQL to set an expiration time for a change in the data.

You will add the ability for individual users to log in and create customized playlists from the music catalog in step 4. In step 5 you will add a table to collect statistics from the Playlist web application.

Finally, in step 6 you will optimize how Playlist returns query data to improve performance.