The ability to effectively utilize a database's potential is more of an art than science. This chapter is probably the most important chapter from the perspective of an application developer. CQL 3 is de facto standard to work with Cassandra and Cassandra has evolved much more beyond the older Thrift protocol. CQL3 makes sure that a developer can never go wrong or use an antipattern. Addition of collections, tuples, UDTs, and lightweight transactions helped a lot to avoid exceptional coding and handling from the developer side and working with third party libraries.

Although the Cassandra client layer has been completely revamped, at its core, the data representation has stayed more or less the same. Working with CQL3, it is easy to forget about underlying storage and start thinking in terms of SQL. Then, at some point, you hit an exceptional behavior and wonder why it works this way—why indexes are like that, why compound keys behave in that way, how collections are stored, how could we put a time series in a table, and much more. Most of these questions can be quickly answered if you have a rough idea of how the data storage is modeled. This chapter tried to show you some of that.

Having applications ready to perform at their best is a good idea, and it is equally important to have a capable infrastructure to serve the expectations. Setting up a Cassandra cluster is simple and easier than most of the distributed software deployments. Out of the box, Cassandra comes with good defaults for most of the cases. So, if you have deployed your cluster before reading the next chapter, chances are that you are not far away from your optimal setting, and you just need to read the next chapter to make sure everything is fine.