Cassandra's Tunable Consistency

Cassandra's Tunable Consistency

Cassandra is an AP (Available and partition tolerant) system. But it also provides tunable consistency. Consistency can be defined as the same data available on all the replica nodes even concurrent updates are done. High consistency gives low availability.
For read queries consistency is given as the number of replica nodes must respond for that particular read.
For write queries consistency is given as number of replica nodes must write the data.
There are types of consistency levels in Cassandra. They are:
  1. One : One of the replica node must respond to the query.
  2. Two: Two of the replica nodes must respond to the query.
  3. Quorum: These many nodes ("(RF/2)+1") must respond from the cluster. where RF is the replication factor. For example if we have RF = 3 then two nodes must respond to the query. 
  4. Each_Quorum: Simply, must read from the maximum number of replica nodes from each data center.
  5. Local_Quorum: Must read from the maximum number of replica nodes from that particular data center. If we use this consistency level we can afford to loose one data center.
  6. ALL: Each and every node must respond to the query. It is not used in the production deployment. Because higher the consistency, lower the availability.
The recommended consistency level for production deployment is read and write at "Quorum". There is also an equation which is used in Cassandra in order to get strong consistency.
                                                                    
                                     R + W > RF
               where,
                             R = Read Replica Count
                             W = Write Replica Count
                             RF = Replication Factor

According to the above equation if the replication factor is greater than the sum of read replica count and write replica count then the system will have strong consistency.

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