Database Reference
In-Depth Information
We're “authorized” to the keyspace because MyKeyspace doesn't require credentials.
Now we can create a column family in our keyspace. To do this on the CLI, use the following
command:
[default@MyKeyspace] create column family User
991590d3-ae2e-11df-b642-e700f669bcfc
[default@MyKeyspace]
This creates a new column family called “User” in our current keyspace, and takes the defaults
for column family settings. We can use the CLI to get a description of a keyspace using the de-
scribe keyspacecommand, and make sure it has our column family definition, as shown here:
[default@MyKeyspace] describe keyspace MyKeyspace
Keyspace: MyKeyspace
Column Family Name: User
Column Family Type: Standard
Column Sorted By: org.apache.cassandra.db.marshal.BytesType
flush period: null minutes
------
[default@MyKeyspace]
We'll worry about the
Type
,
Sorted By
, and
flush period
settings later. For now, we have
enough to get started.
Writing and Reading Data
Now that we have a keyspace and a column family, we'll write some data to the database and
read it back out again. It's OK at this point not to know quite what's going on. We'll come to un-
derstand Cassandra's data model in depth later. For now, you have a keyspace (database), which
has a column family. For our purposes here, it's enough to think of a column family as a multi-
dimensional ordered map that you don't have to define further ahead of time. Column families
hold columns, and columns are the atomic unit of data storage.
To write a value, use the
set
command:
[default@MyKeyspace] set User['ehewitt']['fname']='Eben'
Value inserted.
[default@MyKeyspace] set User['ehewitt']['email']='me@example.com'
Value inserted.
[default@MyKeyspace]
Here we have created two columns for the key
ehewitt
, to store a set of related values. The
column names are
fname
and
email
. We can use the
count
command to make sure that we
have written two columns for our single key:
