Cassandra Advanced Architecture Tutorial

7.1 Cassandra Advanced Architecture and Cluster Management

Hello and welcome to Lesson Seven of the Apache CassandraTM course offered by Simplilearn. This lesson will cover the advanced architecture of Cassandra and cluster management in Cassandra.

7.2 Course Map

The Apache Cassandra™ course by Simplilearn is divided into eight lessons, as listed. • Lesson 0—Course Overview • Lesson 1—Overview of Big Data and NoSQL Database • Lesson 2—Introduction to Cassandra • Lesson 3—Cassandra Architecture • Lesson 4—Cassandra Installation and Configuration • Lesson 5—Cassandra Data Model • Lesson 6—Cassandra Interfaces • Lesson 7—Cassandra Advanced Architecture and Cluster Management • Lesson 8—Hadoop Ecosystem around Cassandra This is the seventh lesson, ‘Cassandra Advanced Architecture and Cluster Management.’

7.3 Objectives

After completing this lesson, you will be able to explain partitioning, describe replication strategies and consistency levels in Cassandra, and explain time to live and tombstones (Note to the VO Artist: Please read ‘live’ as in ‘living’, in the previous version it is read as ‘live’ as in ‘live performance’). You will also be able to demonstrate the use of the nodetool utility and the installation and configuration of the OpsCenter utility.

7.4 Partitioning

Cassandra uses partitioners to distribute data evenly across cluster nodes. A partition key is used for data partitioning. It can be a single column or multiple columns. Three types of partitioners are available in Cassandra. • Murmur3Partitioner • RandomPartitioner, and • ByteOrderedPartitioner The partitioner is specified in the cassandra.yaml file.

7.5 Murmur3Partitioner

The Murmur3Partitioner is currently the default partitioner in Cassandra. It uses the MurmurHash function. The MurmurHash function is a non-cryptographic hash function that creates a 64-bit hash value of the partition key. The function token() can be used in CQL (Note to VO artist: See queue el)to select a range of rows based on the hash value of the partition key.

7.6 RandomPartitioner

The RandomPartitioner was the default partitioner in earlier versions of Cassandra. It is similar to the Murmur3Partitioner except that it uses the MD5 or message-digest version 5 hash function to calculate the hash value. MD5 is a widely-used cryptographic hash function that produces a 128-bit hash value based on the key. It is considered cryptographic because it performs a one-way encryption.

7.7 ByteOrderedPartitioner

The ByteOrderedPartitioner orders rows using partition key values. It performs distribution using the hexadecimal values of the partition key. This enables ordered scans with the use of the primary key. The downside is that this type of ordering makes load balancing difficult.

7.8 Replication of Data

Data replication is used for fault tolerance. A replication factor of three implies a fault tolerance of two. This means that even if two machines fail simultaneously, the third machine will provide the data. When a machine that has a data replica fails, Cassandra will automatically try to create a replica on another machine so that the replication count is brought back to three. There is a chance of data loss only if all three machines fail simultaneously. The probability of that happening is very low. Suppose the mean time to failure or MTTF of each machine is one in 365. This means that each machine is likely to fail once in 365 days. In this case, the probability of three machines failing simultaneously is 1 / (365*365*365), which is one in 200 million. This is a very low probability. Therefore, the presence of three replicas provides good fault tolerance even with commodity-type hardware.

7.9 Replication Strategy

The replication strategy determines how multiple replicas of a data row are maintained. Replication is specified at the keyspace level, and different keyspaces can have different strategies. The replication strategy is specified during the creation of a keyspace. The strategy for a keyspace cannot be modified, but the number of replicas can be modified. Cassandra provides two common replication strategies: SimpleStrategy and NetworkTopologyStrategy.

7.10 SimpleStrategy

SimpleStrategy is the replication strategy for single-rack clusters. It is used within a data center and is suitable for test or development clusters. In this replication strategy, the first copy is stored according to the partitioner. The second copy is placed on the node adjacent to where the first copy was placed. The third copy is placed on the node adjacent to the second node, and this proceeds in a clockwise direction. The replication factor is specified as an option and informs how many replicas need to be maintained. The statements show the creation of a keyspace called testDB with SimpleStrategy for replication. They specify the replication factor as three. This means Cassandra will try to keep three copies of each data row in the keyspace testDB.

7.11 NetworkTopologyStrategy

NetworkTopologyStrategy is used for multi-rack datacenters and is suitable for production clusters and multi-datacenter clusters. In this strategy, the number of replicas in each datacenter can be specified while creating the keyspace. Replicas are placed on different racks within a datacenter. Similar to SimpleStrategy, NetworkTopologyStrategy decides the first node based on the partitioner. Subsequent replicas are placed by checking for a different rack in the ring, in a clockwise direction. The statements show the creation of a keyspace called testDB with NetworkTopologyStrategy. It specifies three replicas in datacenter 1 and one replica in datacenter 2, thus providing a total of four replicas. Therefore, even if datacenter 1 fails, you can access the data from datacenter 2.

7.12 NetworkTopologyStrategy (contd.)

The presence of multiple replicas in NetworkTopologyStrategy ensures two things. First, it ensures fault tolerance because even if one rack fails, a copy of the data is available on another rack within the datacenter. Similarly, even if one datacenter fails, you can access the data from another datacenter. Second, it facilitates data locality. Accessing data in the same node is faster. Therefore, even if one node is busy, you can find another node where the data is local.

7.13 Replication Example

Let us discuss an example of replication with NetworkTopologyStrategy. There are three data copies in datacenter 1 and one copy in datacenter 2. Nodes 1 to 6 are present in datacenter 1 and nodes 7 to 12 are present in datacenter 2. The first copy is placed on node 1 as determined by the partitioner. The second copy is placed on node 4 as it is present on a different rack while moving clockwise in the ring from node 1. The third copy is placed on node 6 as it is present on a different rack, rack 3. Node 6 is present after node 4 while moving clockwise on the ring. This completes the allocation of three copies for datacenter 1. The fourth copy is placed on node 8 in datacenter 2 as determined by the partitioner.

7.14 Tunable Consistency

Let us discuss tunable consistency now. Cassandra provides tunable consistency for better performance, that is, it provides a tradeoff between consistency and performance. A higher consistency implies a slower response to reads and writes. In Cassandra, consistency can be specified for each read and write operation. One is the default consistency and is specified in the configuration file. In the earlier versions of Cassandra, consistency was specified as part of CQL, but in the latest version, consistency is specified as part of the command line interface, cqlsh. A quorum of replicas is considered for some consistency levels. A quorum of replicas signifies a quantity greater than 50% of the replicas. This constitutes a majority of replicas. For a replication count of five, a quorum refers to having at least three replicas. A local quorum requires a presence of more than 50% of the replicas within a datacenter. In our earlier example with three replicas in datacenter 1, a local quorum requires at least two replicas.

7.15 Read Consistency

The following are the descriptions of the different levels of consistency that can be specified for a read operation: • ONE returns as soon as one replica of the data is received. This is the lowest consistency level for a read. • QUORUM returns as soon as a quorum of replicas is received. • LOCAL_QUORUM returns the moment a quorum of replicas within the datacenter is received. • EACH_QUORUM returns after a quorum of replicas is received from each datacenter where replicas are specified. • ALL returns only after all the replicas are received. When multiple replicas are received, the replica with the most recent timestamp is returned as the result of the read. In the given statements, a consistency level of LOCAL_QUORUM is set in cqlsh and a read is executed using the SELECT statement. The SELECT statement will fail on the VM because the replication count has been set to three, in which case, a quorum is two replicas. However, data is present on only one node.

7.16 Write Consistency

The following are the descriptions of the different levels of consistency that can be specified for a write operation: • ANY returns as soon as a replica is written to any node or a commitlog is written. • ONE returns as soon as a replica is written to the correct node. • QUORUM returns the moment a quorum of replicas is written. • LOCAL_QUORUM returns after a quorum of replicas is written within the datacenter. • EACH_QUORUM returns after a quorum of replicas is written in each datacenter where replicas are maintained. • ALL returns only after all the replicas are written. The consistency level of ANY provides the fastest response but has the least consistency. The consistency level of ALL provides the most consistent write but has a slower performance. The write consistency applies to insert, update, and delete operations. In the given statements, a consistency level of ANY is specified in cqlsh and a write is executed with an UPDATE command. This will return immediately after writing to the commitlog.

7.17 Read or Write Failure

Read and write operations will fail if a certain consistency level cannot be achieved due to node failure. Node failure will occur in one of the following cases: • If LOCAL_QUORUM is specified and the number of live nodes is less than the local quorum. • If ALL is specified and one of the replica nodes is down. • If EACH_QUORUM is specified and the number of live nodes on any datacenter is less than the quorum. In a single node cluster with a replication factor of three, any consistency level other than ONE or ANY will fail as shown. In the given set of statements, a consistency level of LOCAL_QUORUM is set in cqlsh, and an UPDATE statement is executed. In the VM, this fails with the message as shown since the local quorum is two replicas.

7.18 Hinted Handoff

Hinted handoff is used during data writes in Cassandra when one of the nodes to write to is down. The process is as follows: • One of the live nodes acts as the temporary write node. • Commitlog is written by the temporary node so that the write is persistent. • Write is completed as if written to the actual node. • The temporary node will send the data to the actual node once the node is up. • The consistency level of ANY for write succeeds even when writing to the temporary node.

7.19 Time to Live

In Cassandra, it is possible to store data only for a limited period. Time to live or TTL refers to the number of seconds for which data should be stored. It is specified during an insert or update in terms of number of seconds. Data is removed when the data expires and is made null. The row, however, is not deleted. In the given statements, the value column is updated in the Stocks table using time to live of one day. Note that 86400 seconds represents the number of seconds in 24 hours. This data will be removed immediately after 24 hours.

7.20 Tombstones

In Cassandra, distributed deletes can cause anomalies when the consistency level is reduced. To overcome this, deletes are handled in the following manner: • Instead of removing the data during a delete operation, a special value called tombstone is created. • Tombstones are propagated to all replicas. • After all the replicas are removed, the tombstone still exists. • Tombstones are removed during compaction after a grace period. In the given statements, a consistency level of one is set in cqlsh and a DELETE statement is executed. The statement returns the moment one replica is deleted, but a tombstone is created so that a subsequent read or write will know that this data has been deleted.

7.21 Monitoring the Cluster

Cassandra is highly fault tolerant, so an administrator needs less effort to monitor the cluster. The following are a couple of utilities available to monitor the cluster: 1. The nodetool utility can be used to monitor and administer the cluster. 2. DataStax provides an OpsCenter utility that can be used to monitor the cluster through a graphical interface from one’s browser. It can be used to modify configuration parameters and add nodes to the cluster. It can also stop or start servers. In the diagram, a nodetool utility is run on a VM, and the status of one node in the cluster is shown. You can also see that the node is up and running normally. Further, you can see the node’s address and load on the node.

7.22 Nodetool Options

The table shows various options for the nodetool utility along with their descriptions. You can view all the options using the command ‘nodetool help.’

7.23 Install and Configure OpsCenter

With a few simple steps, you can install and configure OpsCenter from DataStax to monitor and administer the cluster. To install OpsCenter on the VM, execute the given commands.

7.24 Monitoring with OpsCenter

You can use the browser to connect to the OpsCenter from Windows and monitor and administer the cluster. Access the OpsCenter with the given link, where the vm address is the one used in PuTTY to connect to the VM. You can see cluster-, node-, and activity-level information and information on each node in the cluster. You can also use administration screens to add nodes to the cluster. The image shows the initial screen of the OpsCenter. It displays a dashboard with various graphs that show the status of the cluster. There are graphs on Cluster Health, Storage Capacity, Write Requests, Write Request Latency, Disk Utilization at the operating system level, and the load on the OS.

7.25 Monitoring with OpsCenter (contd.)

The OpsCenter also displays the keyspace information. You can click on the database icon on the left to view the keyspace and user keyspace information. You can expand the keyspace to look at the tables in it. Tables are shown under the heading ‘Column Families.’ The diagram shows a screenshot of the OpsCenter screen where the database is selected and the information about the keyspace testDB is displayed. The diagram shows the replication settings for keyspace testDB and also lists the tables under the heading ‘Column Families.’ Remember that Cassandra sometimes uses the term ‘column families’ for tables.

7.26 Administer using OpsCenter

The OpsCenter can be used to administer the cluster in various ways. You can use cluster actions->Add Nodes to add a node. On the Add Nodes screen, provide sudo user information to install the required software. (Note to the VO artist: There is an audio glitch or fumbling in the previous VO version) Additional configuration can also be done here. Finally, click on Add Nodes to start the installation. The image shows the Add Nodes screen where you can specify the address of the nodes to be added and the information, as mentioned earlier. It also shows the Add Nodes and Cancel options at the bottom of the screen.

7.27 Quiz

A few questions will be presented in the following screens. Select the correct option and click on submit to see the feedback.

7.28 Summary

Let us summarize the topics covered in this lesson. • Cassandra uses the Murmur3Partitioner by default, but the RandomPartitioner and the ByteOrderedPartitioner are also available. • The first copy of data is placed on a node based on the partitioner, while subsequent copies are placed based on the replication strategy. • SimpleStrategy and NetworkTopologyStrategy are available for replication. • Consistency is tunable in Cassandra, and you can set the consistency for each read and write operation. • Various consistency levels provide a tradeoff between speed and consistency of data. • Hinted handoffs are used to make writes faster even if the responsible node is down. • Tombstones are used to handle distributed deletes. • Nodetool and OpsCenter can be used to monitor and administer a cluster.

7.29 Conclusion

This concludes the lesson ‘Cassandra Advanced Architecture and Cluster Management’. In the next lesson, we will learn about the Hadoop Ecosystem around Cassandra.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Phone Number*
Job Title*