6

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

以下是我们keyspace的.column familiesProduction 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.Murmur3Partitionerwith和enabled 。KeyCachingSizeTieredCompactionStrategyVirtual 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 中维护行缓存非常昂贵，因此建议行缓存仅用于较少的行数，例如 <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'};

我应该做些什么来获得良好的读取性能吗？

4

2 回答 2

8

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

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

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

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

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

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

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

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

Key Cache : size 96468768 (bytes), capacity 96468992 (bytes), 959293 hits, 31637294 requests, 0.051 最近命中率, 14400 save period in seconds

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

于 2013-05-15T09:05:59.380 回答
0

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

  • 甚至不要使用射频。您的 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 个单独的查询来获得显着的性能。Ex running: Select... WHERE id = X and bucket = 1，Select ... WHERE id = X and bucket = 2并在应用层进行聚合。
于 2017-11-02T17:09:23.830 回答