在我的场景中提高 Cassandra 读取性能的方法答案

【问题标题】：Ways to improve Cassandra read performance in my scenario在我的场景中提高 Cassandra 读取性能的方法
【发布时间】：2013-05-13 18:36:22
【问题描述】：

我们最近开始在生产中使用 Cassandra 数据库。我们有一个single cross colo cluster of 24 nodes，意思是12 nodes in PHX和12 nodes in SLC colo。我们有一个replication factor of 4，意思是2 copies will be there in each datacenter。

以下是我们的Production DBA's 创建keyspace 和column families 的方式。

使用placement_strategy = 创建键空间配置文件 'org.apache.cassandra.locator.NetworkTopologyStrategy' 和 strategy_options = {slc:2,phx:2};
create column family PROFILE_USER
with key_validation_class = 'UTF8Type'
and comparator = 'UTF8Type'
and default_validation_class = 'UTF8Type'
and gc_grace = 86400;

我们正在运行Cassandra 1.2.2，它有org.apache.cassandra.dht.Murmur3Partitioner，同时启用了KeyCaching、SizeTieredCompactionStrategy 和Virtual Nodes。

Cassandra 生产节点的机器规格-

16 cores, 32 threads
128GB RAM
4 x 600GB SAS in Raid 10, 1.1TB usable
2 x 10GbaseT NIC, one usable

下面是我得到的结果。

Read Latency(95th Percentile)      Number of Threads    Duration the program was running(in minutes)    Throughput(requests/seconds)    Total number of id's requested    Total number of columns requested
    9 milliseconds                         10                      30                                               1977                              3558701                        65815867

我不知道我应该用 Cassandra 尝试什么其他的东西来变得更好read performance。我假设它在我的情况下击中磁盘。我应该尝试将复制因子增加到更高的数字吗？还有什么建议吗？

我相信与 SSD 相比，从 HDD 读取数据大约需要 6-12 毫秒？在我的情况下，每次我猜测它都会撞击磁盘并且启用密钥缓存在这里无法正常工作。我无法启用 RowCache，因为使用 OS 页面缓存更有效。在 JVM 中维护行缓存非常昂贵，因此建议行缓存用于较少的行数，例如

有什么方法可以验证密钥缓存在我的情况下是否正常工作？

这是我在显示列族架构时得到的结果-

create column PROFILE
  with column_type = 'Standard'
  and comparator = 'UTF8Type'
  and default_validation_class = 'UTF8Type'
  and key_validation_class = 'UTF8Type'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and populate_io_cache_on_flush = false
  and gc_grace = 86400
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'KEYS_ONLY'
  and compression_options = {'sstable_compression' : 'org.apache.cassandra.io.compress.SnappyCompressor'};

为了获得良好的读取性能，我应该做些什么改变吗？

【问题讨论】：

你的复制因子是 2。
'nodetool cfstats' 将显示键缓存命中率
rf 为 4。但每个数据中心为 2。
可以改用SSD吗？还可以启用键缓存，并监控命中率，以获得 > 80% 的良好性能。我们使用 7 个节点 32GB RAM、关键缓存命中率 ~=80% 和 ssd 驱动器进行读取延迟 99%

标签： nosql cassandra

【解决方案1】：

我假设它在我的情况下击中磁盘。我应该尝试将复制因子增加到更高的数字吗？还有什么建议吗？

如果您的数据比内存大得多并且您的访问接近随机，您将访问磁盘。这与约 10 毫秒的延迟一致。

增加复制因子可能会有所帮助，尽管它会降低缓存效率，因为每个节点都会存储更多数据。只有当您的读取模式大多是随机的、您的数据非常大、您的一致性要求低并且您的访问量很大时，这可能才值得这样做。

如果您想减少读取延迟，可以使用较低的一致性级别。以一致性级别 CL.ONE 读取通常会以一致性为代价提供最低的读取延迟。如果写入位于 CL.ALL，您将只能在 CL.ONE 处获得一致的读取。但如果不需要一致性，这是一个很好的权衡。

如果您想增加读取吞吐量，可以减少 read_repair_chance。此数字指定 Cassandra 对每次读取执行读取修复的概率。读取修复涉及从可用副本读取并更新任何具有旧值的副本。

如果以低一致性级别读取，则读取修复会产生额外的读取 I/O，因此会降低吞吐量。它不会影响延迟（对于低一致性级别），因为读取修复是异步完成的。同样，如果一致性对您的应用程序不重要，请将 read_repair_chance 降低到大约 0.01 以提高吞吐量。

有什么方法可以验证密钥缓存是否在我的情况与否？

查看“nodetool info”的输出，它会输出如下一行：

Key Cache：大小 96468768（字节），容量 96468992（字节），959293 次命中，31637294 次请求，0.051 最近命中率，14400 秒保存时间

这为您提供了键缓存命中率，这在上面的示例中非常低。

【讨论】：

【解决方案2】：

旧帖子，但万一其他人来了。

甚至不要使用射频。您的 4 的 RF 需要 3 个节点的仲裁，这与 5 的 RF 没有什么不同。
您的密钥缓存可能工作正常，这只告诉 cassandra 它在磁盘上的位置。这只会减少寻道时间。
在 3.0 之前的版本中，您有相当多的 ram，可能您没有充分利用所有这些。在较新的 cassandra 节点上尝试 G1GC。
行键缓存，确保您的分区按照您打算访问它们的方式排序。例如：如果您只获取最近的数据，请确保按timestamp ASC 而不是timestamp DESC 排序，因为它将从分区的 START 开始缓存。
并行化和存储桶查询。使用nodetool cfhistograms 评估分区的大小。如果分区超过 100mb，则尝试将它们分成更小的块。如果需要扫描，您可以从此处将查询更改为 SELECT x FROM table WHERE id = X and bucket in (1,2,3)。然后可以通过删除“in bucket”并将其移至 3 个单独的查询来获得显着的性能。前运行：Select... WHERE id = X and bucket = 1、Select ... WHERE id = X and bucket = 2 并在应用层进行聚合。

【讨论】：