Database Reference
In-Depth Information
Summary
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 deve-
loper. 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 transac-
tions 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, Cas-
sandra 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 op-
timal setting, and you just need to read the next chapter to make sure everything is fine.
