Selecting hardware for DataStax Enterprise implementations 

Choosing the appropriate hardware for DataStax Enterprise depends on selecting the right balance of memory, CPU, disks, number of nodes, and network.

General guidelines 

Attention: These recommendations are guidelines. To ensure your implementation meets expectations, DataStax recommends contacting the DataStax Services team and testing your configuration thoroughly before deployment.
Follow these guidelines when choosing hardware for DataStax Enterprise:
  • Hardware choices depends on your particular use case. The right balance of memory, CPU, disks, number of nodes, and network are vastly different for environments with static data that are accessed infrequently than for volatile data that is accessed frequently.
  • The suggested guidelines are the minimum required. You may need to increase memory, CPU, disk from the recommended minimums.
  • Be sure to read Anti-patterns in DataStax Enterprise for important information about SAN storage, NAS devices, and NFS.
  • Thoroughly test your configuration before deployment.

Stress testing 

To help make certain your that hardware selections meet your business needs, DataStax provide stress testing tools:
cassandra-stress 
The cassandra-stress tool at your desired configuration. Be sure to test common administrative operations, such as bootstrap, repair, and failure. See Testing your DataStax Enterprise cluster before production.
DSE Search stress demo 
The solr_stress demo is a benchmark tool that simulates the number of requests for reading and writing data on a DSE Search cluster using a specified sequential or random set of iterations.
CAUTION:
Do not use a machine suited for development for load testing or production. Failure may result.

Memory 

The more memory a DataStax Enterprise node has, the better read performance. More RAM also allows memory tables (memtables) to hold more recently written data. Larger memtables lead to a fewer number of 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.

Recommended minimum memory for dedicated hardware and virtual environments
Production
Node type System memory Heap
Transactional only 32 GB 8 GB
DSE Analytics 32 GB to 512 GB
  • System memory less than 64 GB: 24 GB
  • System memory greater than 64 GB: 32 GB
DSE Search

Also see Capacity planning for DSE Search.

32 GB to 512 GB
DSE Graph Add 2 to 4 GB to your particular combination of DSE Search or DSE Analytics. For a large dedicated graph cache, add more RAM.
Development (non-load testing environments)
Any 8 GB 4 GB
Any 16 GB 8 GB

CPU 

Insert-heavy workloads are CPU-bound in DataStax Enterprise before becoming memory-bound. (All writes go to the commit log, but the database is so efficient in writing that the CPU is the limiting factor.) DSE is highly concurrent and uses as many CPU cores as available. Recommendations:

  • Minimum dedicated hardware for production: 16-core CPU processors
  • Dedicated hardware in development in non-loading testing environments: 2-core CPU processors are sufficient.
  • DSE Graph: a slightly larger CPU is recommended as graph queries can be a CPU bottleneck due to query optimization and result set preparation.

Spinning disks versus solid state drives (local only) 

Note: For cloud deployments, contact the DataStax Services team.

SSDs are recommended for all DataStax Enterprise nodes. The NAND Flash chips that power SSDs provide extremely low-latency response times for random reads while supplying ample sequential write performance for compaction operations. In recent years, drive manufacturers have improved overall endurance, usually in conjunction with spare (unexposed) capacity. Additionally, because PBW/DWPD ratings are probabilistic estimates based on worst case scenarios, such as random write workloads, and because the database does only large sequential writes, drives significantly exceed their endurance ratings. However, it is important to plan for drive failures and have spares available. A large variety of SSDs are available from server vendors and third-party drive manufacturers.

Endurance is a key factor when purchasing SSDs. The best recommendation is to make the decision based on how difficult it is to change drives when they fail, not on workload of the drive. Remember, your data is protected because the database replicates data across the cluster. Buying strategies include:
  • If drives are quickly available, buy the cheapest drives that provide the performance you want.
  • If it is more challenging to swap the drives, consider higher endurance models, possibly starting in the mid range, and then choose replacements of higher or lower endurance based on the failure rates of the initial model chosen.

For additional help in determining the most cost-effective option for a given deployment and workload, contact the DataStax Services team.

Disk space 

Disk space depends on usage, so it's important to understand the mechanism. The database writes data to disk when appending data to the commitlog for durability and when flushing memtables to SSTable data files for persistent storage. The commit log has a different access pattern (read/writes ratio) than the pattern for accessing data from SSTables. This is more important for spinning disks than for SSDs.

SSTables are periodically compacted. Compaction improves performance by merging and rewriting data and discarding old data. However, depending on the type of compaction and size of the compactions, during compaction disk utilization and data directory volume temporarily increases. For this reason, be sure to leave an adequate amount of free disk space available on a node.

For large compactions:
Compaction strategy Minimum requirements
SizeTieredCompactionStrategy (STCS) Sum of all the SSTables compacting must be smaller than the remaining disk space.
Note: Worst case: 50% of free disk space. This scenario can occur in a manual compaction where all SSTables are merged into one giant SSTable.
LeveledCompactionStrategy (LCS) Generally 10%. Worse case: 50% if the Level 0 backlog exceeds 32 SSTables (LCS uses STCS for Level 0).
TimeWindowCompactionStrategy (TWCS) TWCS requirements are 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.

Note: DateTieredCompactionStrategy (DTCS) is deprecated.

Minimum disk space recommendations 

Important: Use these recommendations as a starting point. Be sure to thoroughly test before production deployment. DataStax highly recommends testing with the cassandra-stress tool at your desired configuration. Be sure to test common administrative operations, such as bootstrap, repair, and failure, to make certain your hardware selections meet your business needs. See Testing your DataStax Enterprise cluster before production. For DSE Search, also test using solr_stress.
Capacity per node (node density) 
Node capacity is highly dependent on the environment. Determining node density depends on many factors, including:
  • Whether data changes frequently or infrequently.
  • Access frequency.
  • Compaction strategy: choice of compaction strategycompaction strategy depends of whether the workload is write-intensive or read-intensive or time dependent. See Disk space above.
  • Using HDDs or SSDs.
  • Network performance: remote links likely limits storage bandwidth and increase latency.
  • Storage speed and whether the storage is local or not.
  • Replication factor: See About data distribution and replication.
  • SLAs (service-level agreements) and ability to handle outages.
  • Whether the data is compressed or not.
To avoid problems, DataStax recommends keeping data per node near or below 1 TB. Exceeding this value has the following effects:
  • Extremely long times (days) for bootstrapping new nodes.
  • Impacts maintenance (day-to-day operations), such as recovering, adding, and replacing nodes.
  • Reduces efficiency when running repairs.
  • Significantly extends the time it takes to expand datacenters.
  • Substantially increases compactions per node.

Higher capacity nodes works best with static data and low access rates.

Search node capacity 
For best performance, use a dedicated drive for search indexes.
DataStax recommends the following maximum index sizes:
  • Single index: 250 GB maximum

    Once a single index exceeds 250 GB or if performance degrades, consider adding nodes to further distribute the search index.

  • Multiple indexes: collective index size: 500 GB maximum

    Supporting more than one index is hardware dependent with respect to the number of physical CPU cores available. DataStax recommends a minimum of two physical cores per search index where the maximum number of search indexes is the number of physical cores divided by two.

    For example, if a machine has 16 virtual CPUs on 8 physical cores, the recommended maximum number of search indexes is 4.

See Managing the location of DSE Search index data.
Note: DataStax recommends extensive testing or consulting assistance from the DataStax Services team. Also see Capacity planning for DSE Search.
Capacity and I/O 
When choosing disks for your nodes, consider both capacity (how much data you plan to store) and I/O (the write/read throughput rate). Some workloads are best served by using less expensive SATA disks and scaling disk capacity and I/O by adding more nodes (with more RAM).
Number of disks - SATA 
Ideally DataStax Enterprise needs at least two disks per node, one for the commit log and the other for the data directories. At a minimum the commit log should be on its own partition.
Commit log disk - SATA 
The disk need not be large, but it should be fast enough to receive all of your writes as appends (sequential I/O).
Commit log disk - SSD 
Unlike spinning disks, it's alright to store both commit logs and SSTables are on the same mount point.
DSE Search - SSD 
Because DSE Search is very IO intensive, transactional data and search data must be on different SSDs. Otherwise, the SSD can be overrun from both workloads.
Data disks 
Use one or more disks per node and make sure they are large enough for the data volume and fast enough to both satisfy reads that are not cached in memory and to keep up with compaction.
RAID on data disks 
It is generally not necessary to use RAID for the following reasons:
  • Data is replicated across the cluster based on the replication factor you've chosen.
  • DataStax Enterprise includes a JBOD (Just a bunch of disks) feature to take care of disk management. Because the database responds according to your availability/consistency requirements to a disk failure either by stopping the affected node or by blacklisting the failed drive, you can deploy nodes with large disk arrays without the overhead of RAID 10. You can configure the database to stop the affected node or blacklist the drive according to your availability/consistency requirements. Also see Recovering from a single disk failure using JBOD.
RAID on the commit log disk 
Generally RAID is not needed for the commit log disk. Replication adequately prevents data loss. If you need extra redundancy, use RAID 1.
Extended file systems 
DataStax recommends deploying on XFS or ext4. On ext2 or ext3, the maximum file size is 2 TB even using a 64-bit kernel. On ext4 it is 16 TB.

Because the database can use almost half your disk space for a single file when using SizeTieredCompactionStrategy, use XFS when using large disks, particularly if using a 32-bit kernel. XFS file size limits are 16 TB max on a 32-bit kernel, and essentially unlimited on 64-bit.

Network 

Since DataStax Enterprise is a distributed data store, it 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 will always choose replicas located in the same datacenter over replicas in a remote datacenter.

Firewall 

If using a firewall, make sure that nodes within a cluster can communicate with each other. See Securing DataStax Enterprise ports table.

The default location of the solr_stress directory depends on the type of installation:
  • Package installations and Installer-Services: /usr/share/dse/demos/solr_stress
  • Tarball installations and Installer-No Services: installation_location/demos.solr_stress