Question

我在cassandra

中定义了以下columnfamily

CREATE TABLE metric (
period int,
rollup int,
tenant text,
path text,
time bigint,
data list&lt;double>,
PRIMARY KEY ((tenant, period, rollup, path), time)
) WITH
bloom_filter_fp_chance=0.010000 AND
caching='KEYS_ONLY' AND
comment='' AND
dclocal_read_repair_chance=0.000000 AND
gc_grace_seconds=864000 AND
index_interval=128 AND
read_repair_chance=0.100000 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
default_time_to_live=0 AND
speculative_retry='NONE' AND
memtable_flush_period_in_ms=0 AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'LZ4Compressor'};

数据列表的大小是否会影响cassandra的读取性能？如果是，我们如何衡量它？？

问题在于，对于给定的路径/句点/汇总组合，从cassandra查询Data-Set1到获取8640行（其中每行的数据列表中的元素数为90）所花费的时间超过了时间查询数据集2所需的数据是8640行数据（其中每行数据列表中的元素数为10）。

此外，如果我同时运行10个用户访问Data-Set1的性能测试，那么我开始在后端看到cassandra超时，并且它在垃圾收集中花费了大量时间，但是当我这样做时也不会发生同样的事情。同样通过查询Data-Set2。

所以我得出结论，数据列表中的元素数量正在影响性能。

您是否在cassandra堆栈中看到类似的性能问题....？

Answer 1

我不认为一个集合中的90个项目会是一个很大的交易，但在你的情况下我猜它是。问题是，当您查询集合列时，Cassandra不能只返回集合的一部分。它必须返回整个列（集合）。这项行动不是免费的，但我不认为90次双打将是一件大事。

要尝试的一件事是打开跟踪。这应该可以让您了解Cassandra在您运行查询时正在做什么。

aploetz@cqlsh:stackoverflow> tracing on;

通常情况下，开启追踪可以引导你进入杯中。

它花了很多时间在垃圾收集

您使用的是任何特殊的JVM设置吗？你在每个节点上有多少RAM？中断正常操作的GC表明（对我而言）您的JVM堆设置可能存在问题。 Tuning Java Resources上的DataStax文档表明，您应该根据节点的RAM使用以下有关调整堆大小的指南：

System Memory       Heap Size

Less than 2GB       1/2 of system memory
2GB to 4GB          1GB
Greater than 4GB    1/4 system memory, but not more than 8GB

cassandra使用Collection阅读性能

1 个答案: