A Cassandra Keyspace is a namespace or container of tables. It's similar to a database in the relational world.

When you create a keyspace, you give it a name and some attributes that tell Cassandra how to replicate your data. We'll show you how!

First, in cqlsh, let's list the existing keyspaces:

DESCRIBE KEYSPACES;

These are keyspaces that Cassandra uses to manage the system (see, they all begin with system). Other than being aware of their existence, you really don't need to worry about these.

Note: Notice that this, and all CQL commands, end with a semi-colon (;) delimiter.

Now, create your own keyspace named my_first_keyspace:

CREATE KEYSPACE my_first_keyspace WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };

There are a few of things to notice in the keyspace you just created:

• Cassandra will convert the name of the keyspace to be lower case, unless you put the name in single quotes.
• Inside the WITH REPLICATION clause, you see the class parameter. This is the replication strategy. The replication strategy tells Cassandra how to distribute replicas of your data across the cluster. There are several options, but the two main options are:
• SimpleStrategy - use this for prototyping and learning.
• NetworkTopologyStrategy - Use this in production. This strategy allows you to declare the number of data replicas on a per datacenter basis. See the documentation for more details.
• Notice the replication_factor parameter. This parameter tells Cassandra how many copies of your data to create. In this example we only have one copy, which is OK for learning, but in production we would use something more like three per datacenter.

So, how can we verify that we created the keyspace? You already know the answer to this! List the keyspaces and verify your new keyspace is there.

We have learned how to list the names of the keyspaces on our cluster, but what if we want to inspect the details of a keyspace? We can use the DESCRIBE command for that too:

DESCRIBE KEYSPACE my_first_keyspace;

In the results from the command, cqlsh shows the command for creating the keyspace, so you can see the replication details.

At some point, we may want to delete the keyspace. Here's the command:

DROP KEYSPACE my_first_keyspace;

List the keyspaces again to make sure the DROP command worked as expected.

OK, so now you know how to work with keyspaces. Let's put this knowledge to work. Create a keyspace we can use for a user management service. The name of the keyspace is user_management. Use the SimpleStrategy with a replication factor of one.

Verify you created the keyspace by first listing the keyspace names and then investigating the user_management keyspace in detail.

Congratulations! You have keyspace skills!

From a logical perspective, Apache Cassandra™ tables contain rows and columns of data.

As a NoSQL columnar database, Cassandra has you specify the table's columns and associated types. You also specify the keyspace that contains the table. Here's an example:

CREATE TABLE user_management.user_credentials ( email text, password text, PRIMARY KEY(email) );

This table, named user_credentials, has two columns (email and password), which both have a text data type, which is similar to VARCHAR in relational databases.

Also notice the PRIMARY KEY clause, which tells us that the email column is the primary key. You must specify a primary key, because Cassandra only allows queries on primary key columns, which we will explain in more detail in the next step.

Now, when you describe the user_management keyspace, you see the user_credentials table.

You can also describe a single table:

DESCRIBE TABLE user_management.user_credentials;

Note: We would never store passwords in plain-text in a production system, but we will for this example to keep things simple.

You may have noticed that we need to prefix the name of the table with the keyspace name. This can get tedious, so cqlsh lets you specify a default keyspace name like this:

USE user_management;

You see the cqlsh prompt changes to indicate the default keyspace. So now, when we work with the table, we only need to specify the table name.

After thinking about this table a bit, we realize that it would be nice to have another column for the user ID, so we could use this ID to refer to the user across other tables. We'll name this column user_id and it will be a Universally Unique Identifier (UUID) type.

Note: Cassandra uses UUID for ID columns because they are unique and efficient to generate in a distributed manner - as opposed to incrementing an integer.

Here's the command to add the column to the table:

ALTER TABLE user_credentials ADD user_id UUID;

Now, describe the table again and see what it looks like.

We can see the column we added.

If we want to delete the table, we use the DROP command - just like we did for the keyspace.

DROP TABLE user_credentials;

Look at the keyspace to see if the DROP command worked

So, now you know how to work with Cassandra tables. Let's use this knowledge to create a users table that has the following columns:

The user_id is the primary key.

We can add rows to the table with the following INSERT statements:

INSERT INTO users (user_id, first_name, last_name) VALUES(uuid(), 'Jeff', 'Carpenter'); INSERT INTO users (user_id, first_name, last_name) VALUES(uuid(), 'Patrick', 'McFadin'); INSERT INTO users (user_id, first_name, last_name) VALUES(uuid(), 'Rebecca', 'Mills');

We can also query the table with the following:

SELECT * FROM users;

NOTE: A SELECT statement without a WHERE clause performs a full table scan and should be avoided for production tables. We use it here for educational illustrative purposes only.

Finally, drop the users table.

Congratulations! You know how to work with tables!

Logically, Apache Cassandra™ tables appear to contain rows, but a closer inspection shows that tables actually contain partitions. A partition is a set of rows that share a partition key. In effect, they behave like pre-computed query results. To wrap our minds around this, we need to understand primary keys, partition keys and clustering columns.

Let's create a new table that is more complex than what we have seen so far.

USE user_management; CREATE TABLE people ( last_name text, first_name text, PRIMARY KEY((last_name), first_name) );

In this example, notice the primary key has two columns and the first column listed has an extra set of parentheses. This extra set of parentheses indicates the partition key. All rows that share this key reside in the same partition. Let's add some rows see how it works.

INSERT INTO people (last_name, first_name) VALUES('Smith', 'Chris'); INSERT INTO people (last_name, first_name) VALUES('Smith', 'Alex'); INSERT INTO people (last_name, first_name) VALUES('Smith', 'Blair');

All three of these rows have different primary keys, but they all share the same partition key (i.e., Smith). As a result, Cassandra stores all three rows together physically in the same partition. So, queries using the partition key are very fast.

SELECT * FROM people WHERE last_name = 'Smith';

The columns in the primary key that are not part of the partition key (e.g., first_name) are called clustering columns. They provide row ordering and uniqueness within the partition. Notice the order of the results in the previous query - Alex comes before Blair, and Blair comes before Chris. This is because Cassandra orders the rows by the first_name clustering column.

We can also use clustering columns in our query.

SELECT * FROM people WHERE last_name = 'Smith' AND first_name = 'Chris';

In this case, Cassandra retrieves the entire partition, but filters out the unrequested rows.

You may be surprised to learn that queries must contain at least the entire partition key. Try doing a query to find all people with the first name of Chris.

This query doesn't work because it does not include the partition key. The reason is, Cassandra hashes the partition key to find the partition. Since hashing has no intrinsic ordering, it would be outrageously expensive for Cassandra to find the partition without the key.

Since we no longer need the example table we created, drop the table.

At this point, you should have a general understanding of partitions, partition keys and primary keys.

As we learned in the previous step, partitions contain one or more rows - they act as precomputed query results. In this step, we'll take a closer look at rows.

Let's create a table so we can illustrate a couple of characteristics about rows. Create a table that has the following specification.

Use last_name as the partition key and first_name as a clustering column.

Next, insert a row with the following values.

Now, write and execute a query to see the entire contents of the table.

You see the row you inserted into the table you created - no big surprise here.

Insert a second row with these values (notice the email is different from the previous row).

Finally, query all the rows in the table again.

What the...? What happened to the first row we inserted?

We have just illustrated two ideas here:

• First, when Cassandra writes, it does not do a read first - that would be too slow.
• Second, a row's primary key values uniquely identify the row - and none of the other columns in the row count towards uniqueness.

Because the primary key was the same in both INSERT statements, the second statement actually performed an update - this is known as an upsert. Another version of an upsert involves using an UPDATE statement to insert a row - hence the name.

If we want the row to be unique, we could add another clustering column - something like people_id, which would be of type UUID. So, Alex Smith at gmail would have a primary key that was unique and different from Alex Smith at hotmail.

Let's look at another interesting aspect of Cassandra rows. Execute the following INSERT command:

INSERT INTO people (last_name, first_name) VALUES('Smith', 'Blair');

Notice in this INSERT command, there is no value for the email column, and yet the command executed without an error. This is because Cassandra supports sparse rows. In other words, rows only require values in the primary key fields. And, Cassandra does this with no space penalty - only the columns that have values require space.

Let's take one more look at the table to verify both rows are there and to see the sparse email column.

We're done with the people table, so you can drop it.

Great! Now you understand about uniqueness and column sparsity within Cassandra rows!