硬件选择
与大多数数据库一样，Cassandra 的吞吐量随着更多 CPU 内核、更多 RAM 和更快的磁盘而提高。虽然 Cassandra 可以配置为在小型服务器上运行以进行测试或开发环境（包括 Raspberry Pis），但最小生产服务器至少需要 2 个内核和至少 8GB 的 RAM。典型的生产服务器具有 8 个或更多内核，并且至少有 32GB 的 RAM。
CPU
Cassandra 是高度并发的，使用在尽可能多的 CPU 内核上运行的多个线程处理许多同时请求（读写）。Cassandra 写入路径往往经过高度优化（写入提交日志，然后将数据插入内存表），因此写入，尤其是写入，往往受 CPU 限制。因此，添加额外的 CPU 内核通常会提高读写吞吐量。
内存
Cassandra 在 Java VM 中运行，该 VM 将预先分配固定大小的堆（Java 的 Xmx 系统参数）。除了堆之外，Cassandra 还会为压缩元数据、布隆过滤器、行、键和计数器缓存以及进程内页面缓存使用大量的非堆 RAM。最后，Cassandra 将利用操作系统的页面缓存，将最近访问的文件部分存储在 RAM 中以供快速重复使用。
为了获得最佳性能，操作员应根据其个人工作负载对集群进行基准测试和调整。但是，基本指南建议
-
始终使用 ECC RAM，因为 Cassandra 几乎没有内部保护措施来防止位级损坏
-
Cassandra 堆不应小于 2GB，也不应超过系统 RAM 的 50%
-
小于 12GB 的堆应考虑使用 ParNew/ConcurrentMarkSweep 垃圾收集
-
大于 12GB 的堆应考虑以下两种方法之一：
-
16GB 堆，新一代为 8-10GB，幸存者比率为 4-6，最大任期阈值为 6
-
G1GC
-
磁盘
Cassandra 将数据持久化到磁盘以实现两种截然不同的目的。第一个是在进行新的写入时写入提交日志，以便在崩溃或系统关闭后可以重新播放。第二个是在超过阈值时将内存表刷新到磁盘作为 SSTable。
提交日志接收写入到 Cassandra 节点的每个写入，并有可能阻塞客户端操作，但它们仅在节点启动时读取。另一方面，SSTable（数据文件）写入是异步发生的，但读取以满足客户端查找。SSTable 还定期合并和重写，这个过程称为压缩。提交日志目录中保存的数据是尚未永久保存到 SSTable 数据目录的数据 - 一旦它被刷新到 SSTable 数据文件，它将定期被清除。
Cassandra 在旋转硬盘和固态硬盘上都表现出色。在这两种情况下，Cassandra 的排序不变 SSTable 允许线性读取、很少的寻道和很少的覆盖，从而最大限度地提高 HDD 的吞吐量和 SSD 的使用寿命，避免写入放大。但是，在使用旋转磁盘时，重要的是提交日志 (commitlog_directory) 位于一个物理磁盘上（不仅仅是一个分区，而是一个物理磁盘），并且数据文件 (data_file_directories) 设置为一个单独的物理磁盘。通过将提交日志与数据目录分离，写入可以从对提交日志的顺序追加中受益，而无需像读取请求从磁盘上的各种 SSTable 中读取数据那样在磁头周围寻道。
在大多数情况下，Cassandra 旨在通过多个独立的、廉价的服务器提供冗余。因此，将 NFS 或 SAN 用于数据目录是一种反模式，通常应避免。同样，具有多个磁盘的服务器通常最好使用 RAID0 或 JBOD 而不是 RAID1 或 RAID5 - Cassandra 提供的复制使磁盘层面的复制变得多余，因此通常建议操作员利用 RAID0 的额外吞吐量，而不是使用 RAID1 或 RAID5 来防止故障。
常见的云选择
许多 Cassandra 的大型用户在各种云中运行，包括 AWS、Azure 和 GCE - Cassandra 将很乐意在任何这些环境中运行。用户应选择与物理空间中所需的硬件类似的硬件。在 EC2 中，流行的选择包括
-
i2 实例，它们提供高 RAM:CPU 比例和本地短暂 SSD
-
具有 NVMe 磁盘的 i3 实例
-
如果您想要轻松备份和更换，EBS 运行良好
-
-
m4.2xlarge / c4.4xlarge 实例，它们提供现代 CPU、增强型网络，并且与 EBS GP2（SSD）存储配合使用良好
通常，磁盘和网络性能会随着实例大小和代数的增加而增加，因此每个系列中更新的实例代数和更大的实例类型通常比它们更小或更旧的替代方案表现更好。
