Skip to content
#Architecture

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

#Architecture #Software #DistributedSystems #SystemDesign

Over a year ago, I read this book about the popular NoSQL database and planned to write a short sammari. But when I started writing sammari, I realized that I had to do separate posts first.

These posts contain all the information you need in order to proceed to the study of the book, which consists of the following parts:

1. Beyond Relational Databases This chapter contains a brief summary of the posts I cited above. 2. Introducing Cassandra - here the author gives the keywords that characterize Cassandra in the elevator pitch format and sells its coolness to readers: distributed and decentralized, elastic scalability, high availability and fault tolerance, tuneable consistency, Brewer's CAP Theorem, row-oriented, high performance:) 3. Installing Cassandra - basic description of the cluster installation, creation of keyscpace (database analog in RDBMS) and tables. This chapter is enough to raise the cluster for experiments, but for administration it is worth reading docks or a book for Cassandra administrators. 4. The Cassandra Query Language The author begins this chapter by recalling the data model in the RDBMS. And then he draws parallels with the data model in Cassandra. It all starts with key-value map pairs, which together with the primary key is a row in Cassandra. Then the row set is going to the party. Inside the line there is a primary key, which in Cassandra is a composite, which consists of a necessarily partition key and an optional set of clustering columns. The partition key defines how the strings are distributed across the nodes of the cluster, and the clustering columns set determines the order of placement of the rows already inside the node. There’s also a static column for optimizations – it’s a column that’s not part of the primary key, but all the lines inside the partition shuffle a common value. Parts are assembled in plaques, plates are collected in keyspace, and keyspace is placed on a cluster. Next, the author talks about data types in Cassandra, which are quite a lot and in which there are interesting types of counter, set, list, map, tuples. 5. Data Modeling This is the most interesting chapter in which the authors talk about simulation inside Cassandra and how it differs from simulation inside RDBMS. If we talk about RDBMS, then there we go from the conceptual model of the subject area. We normalize data and arrange them conveniently in terms of consistent data storage. Next, we can relatively easily write the desired delarate requests for data, where we calmly use joins, connecting tables as we need. And if we need to write other requests for data selection, then it is likely that it can be done quite simply.

At Cassandra, we model data in a very different way. The authors of the book show this on the example of modeling a service for booking hotels. In Cassandra, you need to go not from the conceptual model of the subject area, but from the query model. (query model) The authors give such advice.

Think of the most common query paths your application will use, and then create the tables that you need to support them. The goal is to create a data model in Cassandra that minimizes the number of batches we need to touch to answer a query. The point is that a party is a unit of storage, and if we get into one party, we usually get optimal performance. Separately, it is worth noting that data sorting in Cassandra is also a design solution, since the data on the node inside the batch are arranged in the order that is determined by a set of clustering columns. By the way, for data modeling in Cassandra are used Chebotko diagrams, on which the simulation comes from query, which are supported by tablets, and then for the table I specify incoming columns and all types of keys.

Overview of the rest of the book in the following posts: 2 and 3.

#Software #Architecture #DistributedSystems #SystemDesign