Database Reference
In-Depth Information
operations (create, update, and delete), but schemas also get updated when any-
thing in the keyspace changes. The actual information that pertains specifically to
the schema and its validation criteria is stored in
schema_columnfamilies
,
schema_columns
, and
schema_keyspaces
.
The Versions ColumnFamily shows you what versions of each of the primary
systems you are using. This is typically things like the Cassandra version, Thrift
version, and CQL version.
The System Keyspace is not something that should be modified by hand. While
it can be changed, be very careful if you do so as some changes could create prob-
lems. It can be very difficult to recover from data corruption.
Authentication
Out of the box, Cassandra provides the capability to build your own authentication
and authorization layers. Most people don't do that, nor do they have the need to
do that, but setting up simple authentication and authorization is pretty straightfor-
ward. The default Cassandra setting for authentication is AllowAllAuthenticator,
which is equivalent to no authentication. Setting this SimpleAuthenticator will en-
able the use of two files, the access.properties file and the password.properties file.
If there are users specified in the access.properties file that don't have correspond-
ing entries in the password file, they will not have access to Cassandra.
To use the access.properties file, all entries should be in the format shown in
Listing 11.1
.
The first line of each file in the example is commented out for refer-
ence.
Listing 11.1
Format of the access.properties File
# $keyspace.$table.$permission=$user_list
video_store.videos.@rw:=randalgraves
To use the password.properties file, all entries should be in the format shown in
Listing 11.2
Format of the password.properties File
# $user=$password
randalgraves=videostoreclerk
