Database Reference
In-Depth Information
Summary
In this chapter, we confronted and explored the major issues that stem from Cassandra's
masterless, distributed, and replicated architecture. Interacting with Cassandra often feels
indistinguishable from working with a single-node data store but, when working with any
distributed database, we need to think about the tradeoff between consistency and availabil-
ity. In some situations, we might be willing to read slightly out-of-date data for the sake of
performance and failure tolerance; in others, we will tolerate a higher probability of a re-
quest failing in order to ensure that the data we're reading is fully up-to-date.
You learned that the partition key for a row determines not only its physical location in
storage, but also which nodes within the cluster store copies of the row. This further motiv-
ates the practice of designing our table schemas such that most queries are looking for data
grouped under a single partition key.
You discovered how, in a distributed database, deletion is not as simple as removing a
value from storage and forgetting it ever existed. We saw that maintaining tombstones for
deleted data allows Cassandra to guarantee that deletions are always reflected when reading
a row with strong consistency. We also saw that tombstones can lead to performance de-
gradation in scenarios where we're trying to scan clustering column ranges that contain
many deleted rows.
In the first
Appendix A
,
Peeking Under the Hood
, we will peek under Cassandra's hood,
exploring how the advanced functionality of CQL is in fact a rich abstraction on top of a
much simpler underlying data structure. Peeking under the hood is often a great deal of fun;
and if you're interested in exploring the nuts and bolts of Cassandra data structures, I en-
courage you to read on. But the material in the
Appendix A
,
Peeking Under the Hood
is
purely supplementary: you are fully prepared to be an effective user of Cassandra without
it.
