Plan an OSS Apache Cassandra® deployment
Before you install Cassandra, you must provision and deploy a cluster. The hardware you choose for your Cassandra cluster directly influences cluster performance.
This guide provides general capacity planning recommendations for a broad range of Cassandra use cases. Adjust these recommendations as needed for your environment and workload characteristics. For example, environments with static, infrequently accessed data have different requirements than environments with volatile, frequently accessed data.
|
These recommendations aren’t fixed limits, and they don’t guarantee optimal performance or stability. Use these recommendations as a starting point. Then, test the configuration and make adjustments as needed for your workloads and performance targets. This guide assumes you have basic knowledge of Cassandra databases and DevOps concepts. Use this guide in conjunction with other Cassandra documentation. |
Deployment sizing
Before deployment, plan for capacity and performance by determining the cluster size. This includes selecting the number of datacenters, the number of nodes per datacenter, and the appropriate node size, cloud instance types, and disk capacity.
Operating system
For optimal performance in Linux environments, DataStax recommends using the latest version of a supported Linux distribution. Newer versions of Linux handle highly concurrent workloads more efficiently. For more information, see Install Apache Cassandra.
Memory
The more memory a node has, the better its read performance will be. More RAM also allows memory tables (memtables) to hold more recently written data. Larger memtables lead to fewer SSTables being flushed to disk, more data held in the operating system page cache, and fewer files to scan from disk during a read. The ideal amount of RAM depends on the anticipated size of your hot data, which includes, at minimum, frequently accessed data and indexes.
| Environment type | System memory | Heap |
|---|---|---|
Production |
32 GB |
8 GB |
Development (non-load testing) |
8 GB |
4 GB |
Development (non-load testing) |
16 GB |
8 GB |
For more information, see Hardware choices for Apache Cassandra.
Disks
Disk space depends on usage, so it’s important to understand how Cassandra uses it. The database writes data to disk when appending data to the commit log for durability and when flushing memtables to SSTable data files for persistent storage. For more information about these concepts, see Apache Cassandra Storage Engine.
The commit log has a different access pattern (read/writes ratio) than the pattern for reading data from SSTables. This is more important for spinning disks than for SSDs. For more information about disks, see Hardware choices for Apache Cassandra.
Disk space required for compaction
Periodically, the database merges SSTables and discards old data in a process called compaction. This helps maintain read/write performance by ensuring that data is efficiently organized on disk. However, depending on the compaction strategy and size of the compactions, this process can temporarily increase disk utilization and the size of data directory volumes. Make sure nodes have adequate free disk space available for compaction.
| Compaction strategy | Minimum requirements |
|---|---|
SizeTieredCompactionStrategy (STCS) |
Sum of all SSTables being compacted must be smaller than the remaining disk space. Worst-case: 50% of free disk space. This scenario can occur in a manual compaction where all SSTables are merged into one large SSTable. |
LeveledCompactionStrategy (LCS) |
Generally 10%. Worst-case: 50% when the Level 0 backlog exceeds 32 SSTables. LCS uses STCS for Level 0. |
TimeWindowCompactionStrategy (TWCS) |
Similar to STCS. TWCS requires approximately 50% extra disk space for the total size of SSTables in the last created bucket. To ensure adequate disk space, determine the size of the largest bucket ever generated and add 50% extra disk space. |
DateTieredCompactionStrategy (DTCS) |
Deprecated. |
Estimate usable disk capacity
To estimate how much data your nodes can hold, calculate the usable disk capacity per node and then multiply that by the number of nodes in your cluster. For a production cluster, DataStax recommends separating the commit log and data directories onto different disks.
-
Start with the raw capacity of the physical disks:
raw_capacity = disk_size * number_of_data_disks -
Calculate the usable disk space accounting for file system formatting overhead (roughly 10 percent):
formatted_disk_space = (raw_capacity * 0.9) -
Calculate the recommended working disk capacity:
usable_disk_space = formatted_disk_space * (0.5 to 0.8)
During normal operations, the database routinely requires disk capacity for compaction and repair operations.
For optimal performance and cluster health, DataStax recommends not filling your disks to capacity, but running at 50% to 80% capacity.
For more information, see the CREATE TABLE command’s COMPACTION option.
Estimate capacity per node (node density)
Unless you are using SSDs with many CPUs and significant RAM, DataStax doesn’t recommend more than 1 TB per node. However, actual node capacity is highly dependent on the environment, including factors such as the following:
-
Data frequency change and access frequency.
-
Using HDDs or SSDs.
-
Storage speed and whether the storage is local.
-
SLAs (service-level agreements) and ability to handle outages.
-
Data compression.
-
Compaction strategy, depending on whether the workload is write-intensive, read-intensive, or time dependent.
Network and ports
The minimum recommended bandwidth is 1000 Mb/s (gigabit).
A distributed data store puts load on the network to handle read/write requests and replication of data across nodes. Be sure that your network can handle inter-node traffic without bottlenecks. DataStax recommends binding your interfaces to separate Network Interface Cards (NIC). You can use public or private NICs depending on your requirements.
The database efficiently routes requests to replicas that are geographically closest to the coordinator node and chooses a replica in the same rack when possible. The database always chooses replicas located in the same datacenter over replicas in a remote datacenter.
Poor node network performance can limit storage bandwidth and increase latency.
If using a firewall, make sure that nodes within a cluster can communicate with each other.
The following ports must be open to allow bi-directional communication between nodes. Configure the firewall running on nodes in your cluster accordingly. Without the following open ports, nodes act as a standalone database server and do not join the cluster.
| Port type | Port number | Description |
|---|---|---|
Public |
22 |
SSH port |
Inter-node |
7000 |
Inter-node cluster communication |
Inter-node |
7001 |
SSL inter-node cluster communication |
Inter-node |
7199 |
JMX monitoring port |
Client |
9042 |
Client port |
Client |
9160 |
Client port for Thrift |
Client |
9142 |
Default for |
Recommended production configuration
In addition to selecting hardware for your cluster, you must configure the operating system and Cassandra installation for optimal performance in production. This includes hardware-related configurations, such as disk settings, as well as Cassandra settings, such as compression and compaction.
|
DataStax recommends that you review the recommended production settings before finalizing your hardware choices. Although you cannot apply these recommendations until you provision your cluster and (for some settings) install Cassandra, this information might influence your hardware choices and deployment plan. |
Review the recommendations for your version of Cassandra:
