Important Cassandra Recommendations
There are two replication strategies:
- Simple Strategy
- Network Topology Strategy.
Network Topology Strategy should be used in all cases because it is both data-center-aware and rack-aware. Simple Strategy has neither of these properties.
Switching between these strategies is complex and can be very expensive, so users should always put in the effort to properly configure Network Topology Strategy right from the creation of a keyspace.
If a keyspace is already configured to use Simple Strategy, there are a few ways to alter this. Two such ways are:
- Reading all data from the keyspace to a new keyspace which is a clone of the original with Network Topology Strategy enabled. This requires minor downtime and is very expensive as the cluster must rewrite all the data.
- If the cluster has a single data center and the number of nodes is equal to the replication factor then the keyspace can be altered to use Network Topology Strategy with no side-effects. This is because all nodes contain a full copy of all the data.
Altering the Replication Factor
If the replication factor of a keyspace is increased, the client driver will immediately begin to read from the new replicas which “should” contain the data but will not until the cluster is repaired. For this reason it’s important to ensure your read consistency level can handle a node being down when increasing the replication factor.
When decreasing the replication factor everything should act largely as expected immediately, the exception being the old SSTables will continue to take up space until they are manually removed using nodetool cleanup.
The Apache Cassandra project provides a few snitches. Some like Ec2Snitch may sound like the optimal choice when using AWS. However, although they may take away some of the complexity of configuring a snitch, this comes at the expense of full functionality. In all situations uses should configure the GossipingPropertyFileSnitch, which can be configured to use racks and data centers.
It is mandatory to ensure that time is correctly synchronized on each host where Cassandra is running, using NTP for example. Failing to do so may result in incoherent behaviour such as incorrectly created tables/index, inconsistent or disappearing data.
Be sure to follow the vendor's recommended settings for production systems.
There is more information in vendor documentation here.
In order to support attachments larger than 100 Kb, the following option should be populated in the Cassandra configuration:
batch_size_fail_threshold_in_kb : 16384
The following option defines a batch size warning threshold:
It is advised to increase write request timeout by changing the below option:
Concurrent Operations for Indexed Searches
In order to provide the best performance on indexed searches and index updates, it is recommended to configure the following settings, as a minimum to the values below, on all your Cassandra nodes.
concurrent_reads : 128 concurrent_writes : 64
Cassandra’s concurrent read threads are used by the plugin to find results from Elasticsearch and then load the corresponding rows from Cassandra. Cassandra’s concurrent write threads are used by the plugin to send updates to Elasticsearch when the corresponding row is inserted/updated/deleted.