我需要一些帮助来提高Cassandra读取性能。我担心随着列系列大小的增加，读取性能会下降。我们有以下关于单节点Cassandra的统计数据。
操作系统： Linux - CentOS 版本 5.4 （最终版）
Cassandra版本：apache-cassandra-1.1.0
爪哇版本："1.6.0_14"Java（TM） SE 运行时环境（build 1.6.0_14-b08）Java HotSpot（TM） 64-bit Server VM（build 14.0-b16，混合模式）
Cassandra Configuration： （cassandra.yaml）
- rpc_server_type：HSHA
- disk_access_mode：mmap
- concurrent_reads：64
- concurrent_writes：32
平台：Amazon-ec2/Rightscale m1。具有 4 个带有 raid0 的临时磁盘的大型实例。（15 GB 总内存、4 个虚拟内核、2 个 ECU、总 ECU = 8）
实验配置：我尝试用GC做一些实验
Cassandra 配置：
10 GB RAM 分配给 Cassandra Heap，3500MB 是 Heap 新大小。
JVM 配置：
JVM_OPTS="$JVM_OPTS -XX：+UseParNewGC"
JVM_OPTS="$JVM_OPTS -XX：+UseConcMarkSweepGC"
JVM_OPTS="$JVM_OPTS -XX：+CMSParallelRemarkEnabled"
JVM_OPTS="$JVM_OPTS -XX：幸存者比率=1000"
JVM_OPTS="$JVM_OPTS -XX：MaxTenuringThreshold=0"
JVM_OPTS="$JVM_OPTS -XX：CMS占用分数=40"
JVM_OPTS="$JVM_OPTS -XX：+使用CMS仅占用 -XX：+使用压缩哎呀"
来自 OpsCenter 社区 2.0 的结果统计数据：
读取请求 208 到 240
每秒每秒写入请求 18 到 28
个操作系统负载 24.5 到 25.85
写入请求延迟 127 到 160 分钟
读取请求延迟 82202 到 94612 微
操作系统发送的网络流量 44646 KB 平均每秒
操作系统接收的网络流量 4338 KB 平均每秒
OS 磁盘队列大小 13 到 15 个请求
挂起的读取请求 25 到 32
OS 磁盘延迟 48 到 56 毫秒
OS 磁盘读取吞吐量 4.6 Mb/秒
磁盘 IOPS 每秒读取 420
IOWait 80 % CPU 平均
空闲 13 % CPU 平均
行缓存已禁用。
专栏家族
我只从中读取的列系列之一是通过 CLI 创建的
create column family XColFam
with column_type='Standard'
and comparator = CompositeType(BytesType,IntegerType)';"
7.10 GB，SST 可计数 = 2
XColFam列系列有59499904估计的行键（大多数是长度不同的 UTF8 文字，通过 MX4Jtools 估计），其中列本质上像 Thin，值为 0 字节.....现在。
大多数行应该有非常少的列数，可能是 1 到 10 列，所以列名的第一个组成部分大约有 20 到 30 个字节，第二个是 8 个字节的整数......复合列的第二个组成部分是动态的，可以重复，但概率很低......第一个组件在品种中重复，但行中的列数可能不同。
我已经尝试SnappyCompression压缩列系列，但大小没有变化。
我有一个计划服务，它使用 20 个线程运行数小时，并向该列系列发出多个键的随机读取请求（目前每个请求 2 个键）并读取整行、无列切片等。
我认为它现在表现不佳，因为它每分钟处理的请求太少。以前，当色谱柱系列的大小不是那么大时，它的效果更好。它大约是 3 到 4 GB。
恐怕随着列族大小的增加，读取性能下降得太快了。
我还尝试调整一些GC和内存的东西，因为在此之前我有很多GC和CPU使用率。当数据大小较小且波形形式的 iowait 非常小时。
如何提高卡桑德拉的性能。您的建议将不胜感激。
看 cassandra 是相对依赖于 I/O 的。EC 实例在设计上具有"不可靠"的 I/O（Xen 虚拟化）我的第一个建议是在真正的硬件上使用Cassandra，在那里你可以控制。例如，您可以使用SSD磁盘进行提交日志。看看Cassandra的硬件提案。
但是，切换到自己的硬件是一个激进的选择。要留在亚马逊，请尝试EBS
AmazonAmazon Elastic Block Store （EBS） 提供块级存储卷 用于 Amazon EC2 实例。亚马逊 EBS 卷是 网络连接，并独立于生命周期而持久 实例。Amazon EBS 提供高度可用、高度可靠、 可附加到正在运行的 Amazon 的可预测存储卷 EC2 实例，并作为实例中的设备公开。亚马逊电子买家 特别适用于需要数据库、文件的应用程序 系统，或访问原始块级存储。
EBS 允许您创建 1 GB 到 1 TB 的存储卷，这些卷可由 Amazon EC2 实例挂载为设备。可以将多个卷装载到同一实例。Amazon EBS 使您能够根据需要通过选择预配置 IOPS 卷来预置特定级别的 I/O 性能。这允许您以可预测的方式扩展到每个 Amazon EC2 实例的数千个 IOPS。
另请查看 EC2 上的 Cassandra 性能测试
简短回答：行缓存和键缓存。
如果数据包含像大多数系统一样经常读取的子集，请尝试使用行缓存和键缓存。
行缓存是一种内存缓存，它将经常读取的行完全存储在内存中。请记住，如果您的数据分散开来，这可能没有预期的效果。
键缓存通常更适合，因为它仅将分区键及其偏移量存储在磁盘上。这通常有助于跳过 Cassandra 的查找（无需使用分区索引和分区摘要）。
尝试使用密钥空间和表启用密钥缓存，并检查性能。