硬件选择
与大多数数据库一样，Cassandra吞吐量随着更多的CPU内核，更多的RAM和更快的磁盘而提高。虽然Cassandra可以在测试或开发环境（包括Raspberry Pis）的小型服务器上运行，但最小生产服务器至少需要2个内核和至少8GB的RAM。典型的生产服务器有8个或更多的内核和至少32GB的RAM。
*处理器（CPU）
Cassandra高度并发，使用在尽可能多的CPU核上运行的多线程来处理许多同时请求（读和写）。Cassandra写入路径需要被优化（写入提交日志，然后将数据插入到memtable中），因此写入严重受CPU约束。所以添加额外的CPU内核通常会提高读取和写入的吞吐量。
内存（Memory）
Cassandra在Java VM中运行，这将预分配固定大小的堆（java的Xmx系统参数）。除了堆之外，Cassandra还将使用大量的RAM非堆用于压缩元数据，bloom过滤器，行，键和计数器缓存，以及进程内页面缓存。最后，Cassandra将利用操作系统的页面缓存，将最近访问的部分文件存储在RAM中以便快速重用。
为了获得最佳性能，运营商应根据其各自的工作负载对其集群进行基准和调优。但是，基本准则建议：
- 应该总是使用ECC RAM，因为Cassandra几乎没有内部保护措施来防止位级别损坏
- Cassandra堆应该不小于2GB，并且不超过系统RAM的50％
- 堆大小小于12GB应该考虑ParNew / ConcurrentMarkSweep垃圾收集
- 堆大于12GB应考虑G1GC
磁盘（Disks）
Cassandra将数据保存到磁盘中，用于两种非常不同的目的。第一个是在进行新写入时的commitlog，以便在崩溃或系统关闭后可以重播。第二个是在超过阈值时到数据目录中将memtables作为SSTables刷新到磁盘。
委托日志接收对Cassandra节点的每个写入有可能阻塞客户端操作，但它们只能在节点启动时读取。另一方面，SSTable（数据文件）写入异步发生，但是满足客户端查找的读取需要。SSTables还在称为压缩的过程中定期合并和重写。commitlog目录中保存的数据是尚未永久保存到SSTable数据目录的数据 - 一旦将其刷新到SSTable数据文件，它将被定期清除。
Cassandra在旋转硬盘和固态磁盘上表现非常出色。在这两种情况下，Cassandra中排序不变的SSTables允许线性读取，只需要很少的查找和少量的覆盖，通过避免写入放大，最大化HDD的吞吐量和SSD的寿命。但是使用旋转磁盘时，重要的是commitlog（commitlog_directory）位于一个物理磁盘（不仅仅是分区，而是物理磁盘）上，而数据文件（data_file_directories）也应设置为单独的物理磁盘。通过将提交日志与数据目录分离，写入可以附加到提交日志之后从中获益，无需在读取磁盘上各种SSTables的请求数据时查找盘片。
在大多数情况下，Cassandra旨在通过多个独立，廉价的服务器提供冗余。因此，对数据目录使用NFS或SAN是反模式的服务器通常应避免使用。类似地，使用RAID0或JBOD而不是RAID1或RAID5,因为通常更好地服务器具有多个磁盘 。Cassandra提供的复制消除了在磁盘层进行复制的需要，因此通常建议运营商利用RAID0的额外吞吐量，而不是使用RAID1或RAID5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000保护故障。
常见的云选择
Cassandra的许多大型用户在各种云中运行，包括AWS，Azure和GCE - Cassandra将很乐意在这些环境中运行。用户应该选择与物理空间所需的类似的硬件。在EC2中，常用的选项包括：
- m1.xlarge实例，它提供1.6TB的本地临时旋转存储和足够的RAM来运行中等工作负载
- i2实例，其提供高RAM：CPU比率和本地短暂SSD
- m4.2xlarge / c4.4xlarge实例，提供现代化的CPU，增强的网络和与EBS GP2（SSD）存储
m4.2xlarge / c4.4xlarge实例，提供现代化的CPU，增强的网络和与EBS GP2（SSD）存储