[2/3] Cassandra: The Definitive Guide, 3rd edition (Category Architecture)

In this post, I continue with an interesting book on Cassandra. (beginning previous post) And I'm just talking about chapter six.The Cassandra Architecture" This chapter begins with the definition of architecture.

Architecture—fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. —ISO/IEC/IEEE 42010 And then the interesting thing begins.

1. About the topology of cluster deploymentMore specifically, about data centers and racks (racks). This is important for understanding how fault tolerance is ensured - there's gossip at Cassandra for that. (gossip protocols) fault-detection (phi accrual failure detector). Both of these are funly described in the book Database Internals, which we discussed at CoA. (release once and two).

2. The mechanism of consistent hashing with tokens, rings and virtual nodes (DataStax is available perfect description visualization). About how the partitioner works, which spreads our parts along the nodes of the cluster and about replication strategies. Next comes the time to discuss the consistency level and tunable consistency of the cashier, which we can put on each request.

3. Coordination of the request A coordinating node that interacts with replicas on behalf of the client to ensure the requested level of consistency. There is such a thing as a hinted handoff for writing requests, when the coordinating node failed to write the data, but she left herself a reminder that you need to hear the gossip about the return of the replica in order to send there write the request. Here are the topics of how to deal with entropy. (anty-entropy) and repair replicated data (Cassandra’s approach is based on Amazon’s Dynamo approach. whitepaper from 2007 year). Here comes the knowledge of algorithms and data structures, for example, the hash tree or the Merkle tree. (Merkle trees).

4. More specifically, lightweight transactions. (LWT) Paxos protocol to achieve consensus. Actually, LWT is needed to achieve linearizability, which was discussed in the famous CAP theorem. (More in previous posts: The CAP theorem and On the formalization of the CAP theorem and its proof). The author explains that quorum reading and quorum writing, which guarantee strong consistency, do not prevent the state of the race. (race conditions) In cases where customers first need to read and then write down the data. This is why LWT is based on Paxos. (Which should be discussed separately). But it should be noted that

Cassandra’s lightweight transactions are limited to a single partition. This means that we cannot guarantee linearizability if we make requests for different parties.

5. About the internal device of the data storage engineWe have Memtables, SSTables, and Commit Logs. This works so that we write write requests to commit log and do it durable, and then write the data to the in-memory memtable structure, where each memtable contains data for a specific Cassandra table. Further, when a certain limit is reached, memtable is written to disk. (This is called a sorted strings table or sorted row table.). There are many such SSTables on the disk and Cassandra periodically compacts them, producing mergesort. (This algorithm will be useful for understanding.).

Next, it is interesting to discuss reading data, where probabilistic data structures, or rather Bloom filters, help us. (Bloom filters). They let you know if there is a desired record inside a particular SSTable without a full scan. Caching strategies are also used for productivity. Plus, deleting records with an append-only storage structure looks interesting - we can't just delete the record, as we need to save tombstone that it's deleted. If we don’t, then with compaction, our deleted recordings will come to life... not as zombies, but as full-fledged recordings:)

Final review in next post.

#Software #Architecture #DistributedSystems #SystemDesign