Question

我们最近开始在生产中使用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。

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

使用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-12ms？在我的情况下，它每次我都想击中磁盘，启用密钥缓存在这里工作不正常。我无法启用RowCache，因为使用OS页面缓存更有效。在JVM中维护行缓存非常昂贵，因此建议将行缓存用于较少的行，例如仅<100K行。

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

这是我为列族显示模式时得到的结果 -

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'};

我应该做些什么来改善阅读效果吗？

Answer 1

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

如果您的数据比内存大得多，并且您的访问权限接近随机，那么您将会遇到磁盘。这与~10ms的延迟一致。

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

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

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

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

有什么方法可以验证我的密钥缓存是否正常工作案件与否？

查看'nodetool info'的输出，它将输出如下行：

密钥缓存：大小96468768（字节），容量96468992（字节），959293次点击，31637294次请求，0.051最近命中率，14400个保存期限（秒）

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

Answer 2

旧帖子，但是其他人也会这样做。

不要使用RF。您的RF为4需要3个节点的法定数量，这与5的RF无异。
您的密钥缓存可能正常工作，这只会告诉cassandra它位于磁盘的哪个位置。这只会减少寻道时间。
你有一个相当大量的RAM前3.0，可能你没有利用所有这一切。在较新的cassandra节点上尝试使用G1GC。
行键缓存，确保按照您打算访问它们的方式对您的分区进行排序。例如：如果您只选择最近的数据，请确保按timestamp ASC而不是timestamp DESC进行排序，因为它将从分区的START缓存。
并行化和存储桶查询。使用nodetool cfhistograms评估分区的大小。然后尝试将分区分成较小的块，如果它们超过100mb。如果您需要扫描，请从此处将查询更改为SELECT x FROM table WHERE id = X and bucket in (1,2,3)。通过删除桶中的＆＃34;可以获得显着的性能。并将其移至3个单独的查询。 Ex运行：Select... WHERE id = X and bucket = 1，Select ... WHERE id = X and bucket = 2并在应用层进行聚合。

在我的场景中改进Cassandra读取性能的方法

2 个答案: