Now that we understand the data model, we’ll look at the different kinds of queries you can perform in Cassandra to read and write data. In this chapter, we use Cassandra 0.6.7-beta1, which is the most recent release version at the time of this writing.
There are several differences between Cassandra’s model and query methods and what’s available in RDBMS, and these are important to keep in mind.
There is no first-order concept of an update in Cassandra, meaning that there is no client query called an “update.” You can readily achieve the same effect, however, by simply performing an insert using an existing row key. If you issue an insert statement for a key that already exists, Cassandra will overwrite the values for any matching columns; if your query contains additional columns that don’t already exist for that row key, then the additional columns will be inserted. This is all seamless.
Cassandra automatically gives you record-level atomicity on every write operation. In RDBMS, you would have to specify row-level locking. Although Cassandra offers atomicity at the column family level, it does not guarantee isolation.
Because you need to denormalize tables to create secondary indexes, you might need to insert data into two or more tables (one for your primary table and one for your inverted or secondary index). This means ...