Cassandra's Read Path

 Cassandra's Read Path

Cassandra is a NoSql database that is designed for heavy writes. So the read path of Cassandra is a little complex.

Every node stores its data in immutable sstables. So there can be multiple sstables for one table of data.

So in order to read something from Cassandra, we have to search all the sstables which are responsible for that data.

So we have multiple components which are useful for optimizing the sstable search. They are:

1. Bloom Filter: 
Bloom filter says "Hey! The data you looking for doesn't exist here!" Meaning it helps us to find the correct sstable. But sometimes BF may give false positives(sometimes it says the data is in this sstable but we end up not finding the data.), but never gives false negatives (If BF says data is not there in a particular sstable it'll not be there.)

2. KeyCache: KeyCache stores the byte offset value of particular data which is already viewed.

3. Partition Summary: It is used when the partition index is very large. It will group the indexes so that we can search easily.

4. Partition Index: The partition index consists of the byte offset value and the partition key of the data stored in the sstable.
If we know the byte offset value makes the sstable search easier.

Fig: READ PATH

The thing I love the most in Cassandra is whenever a read/write request is received any node can respond to it. That node will become the coordinator node for that request.

When a coordinator node receives the request it will send the acknowledgement to all the replicas. 

The coordinator requests the original data from one node and digest values from other replica nodes. The coordinator will compare the hash values of the obtained data. 
>> If the hash values match with each other it will send the data to the client.
>> If the hash values mismatch then it will repair the inconsistencies based on the timestamp and simultaneously sends the data to the client. This is called read repair. This takes place only if we are using a consistency of more than 1.

So, let's see how the read operation will be when a read request hit the replica node.

>> It starts with bloom filter, It tells us, don't check that sstable, The partition you are looking for doesn't exist there.
>> BF never gives you False negatives. but BF may result in False positives. ( meaning It tells you the partitions exists in sstables, but it may not exists)

>> If sstable passes the BF, then it checks the keycahce to see if it contains the offset of the partition key in the sstable. 

>> If it finds it, it will skip the two index checks and reads the data from sstable directly. 

>> If it didn't fount it, then it checks the Partition Summary and Partition Index, and then it gets the offset information and reads the data from sstable.

>> After that, it will updates the key cache with a partition key and offset value. 

>> Finally it will return the data to the coordinator node.

Comments

Post a Comment

Popular posts from this blog

Cassandra Reaper Configuration

Image
Cassandra Reaper  Reaper is an open source tool that aims to schedule and orchestrate repairs of Apache Cassandra clusters. It improves the existing nodetool repair process by Splitting repair jobs into smaller tunable segments. Handling back-pressure through monitoring running repairs and pending compactions. Adding ability to pause or cancel repairs and track progress precisely. It also gives us a simple web interface to schedule, run, pause or stop the repair process. Cassandra Reaper Configuration >> The main prerequisite to configure reaper is there must be some backend system to store the reaper data.  >> These may be: In-Memory Cassanda PostgresQL H2 Astra >> I'm choosing Cassandra as my backend. For that I must have Cassandra running on my machine. >> Then visit this website http://cassandra-reaper.io/docs/ to know about the detailed documentation  >> I downloaded rpm from the below link: >> Reaper download     ...
Read more

Authorization in Cassandra

Image
Authorization in Cassandra  Authorization in Cassandra is disabled by default. This grants all permissions to all roles. But disabling authorization is not used in production deployment. Cassandra has role based access control and using this we can configure proper access profile and schema access limitations. To enable authorization we must enable authorizer in cassandra.yaml file. By default: After enabling authorization: Now restart the node using the following command: ndoetool drain; nodetool stopdaemon; cassandra Once we enable authorization we have to start creating roles.  Let's create a dba role, which has to have all the permissions on all the keyspaces. Create an sales_admin role, which has to have all permissions on that particular keysapce. Create an read_only role, which has to have only select access on all the keyspace. High level roles as place holder for all roles. create role 'dba_role' with login=false; create role 'sales_admin' login=false; crea...
Read more

Authentication in Cassandra

Image
Authentication in Cassandra Authentication in Cassandra is disabled by default. Which allows any one on your network to connect to the database.  To enable authentication we must make changes in the main configuration file in Cassandra, the "Cassandra.yaml" file.  The default file: Changes to perform in cassandra.yaml file in order to enable authentication: Make the above changes and save the file. The changes to make effect on the node we must restart the node. Command used for restarting the node: nodetool drain; nodetool stopdaemon; cassandra  Now if we try to connect with the database. It throws the following error. Now it is asking for username and password. The default username and password after enabling authentication is  username = cassandra password = cassandra cqlsh -u cassandra -p cassandra Every one who uses Cassandra knows about this default username and password. So, if we continue with the same user and password then there is no need of enabling authe...
Read more