Database Reference
In-Depth Information
itions and is aware of any modifications to the schema made at runtime. It can propagate any
changes made in one node to the rest of the cluster based on timestamps.
To see the version of the API you're using, type:
[default@Keyspace1] show api version
10.0.0
There are a variety of other commands with which you can experiment. For now, let's add some
data to the database and get it back out again.
Creating a Keyspace and Column Family
A Cassandra keyspace is sort of like a relational database. It defines one or more column families,
which are very roughly analogous to tables in the relational world. When you start the CLI client
without specifying a keyspace, the output will look like this:
>bin/cassandra-cli --host localhost --port 9160
Starting Cassandra Client
Connected to: "Test Cluster" on localhost/9160
Welcome to cassandra CLI.
Type 'help' or '?' for help. Type 'quit' or 'exit' to quit.
[default@unknown]
Your shell prompt is for default@unknown because you haven't authenticated as a particular
user (which we'll see how to do in Chapter 6 ) and you didn't specify a keyspace.
NOTE
This authentication scheme is familiar if you've used MySQL before. Authentication and authorization
are very much works in progress at the time of this writing. The recommended deployment is to put a
firewall around your cluster.
Let's create our own keyspace so we have something to write data to:
[default@unknown] create keyspace MyKeyspace with replication_factor=1
ab67bad0-ae2c-11df-b642-e700f669bcfc
Don't worry about the replication_factor for now. That's a setting we'll look at in detail
later. After you have created your own keyspace, you can switch to it in the shell by typing:
[default@unknown] use MyKeyspace
Authenticated to keyspace: MyKeyspace
[default@MyKeyspace]
Search WWH ::




Custom Search