Cassandra读取超时

7

我正在从Cassandra 2.0中提取大量数据,但很不幸出现了超时异常。 我的表:

CREATE KEYSPACE StatisticsKeyspace
  WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };


CREATE TABLE StatisticsKeyspace.HourlyStatistics(
KeywordId text,
Date timestamp,
HourOfDay int,
Impressions int,
Clicks int,
AveragePosition double,
ConversionRate double,
AOV double,
AverageCPC double,
Cost double,
Bid double,
PRIMARY KEY(KeywordId, Date, HourOfDay)
);
CREATE INDEX ON StatisticsKeyspace.HourlyStatistics(Date);

我的查询:

SELECT KeywordId, Date, HourOfDay, Impressions, Clicks,AveragePosition,ConversionRate,AOV,AverageCPC,Bid 
FROM StatisticsKeyspace.hourlystatistics 
WHERE Date >= '2014-03-22' AND Date <= '2014-03-24'

我已经在我的cassandra.yaml文件中更改了配置。

read_request_timeout_in_ms: 60000
range_request_timeout_in_ms: 60000
write_request_timeout_in_ms: 40000
cas_contention_timeout_in_ms: 3000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 60000

但它仍然在大约10秒钟左右抛出超时。有什么想法可以解决这个问题吗?

1
这是使用cassandra-cli还是Java应用程序?从您的标签中仍不清楚,尽管查询提示了cli。 - John
1个回答

8

如果使用Datastax的Java客户端,则默认启用5000行集的分页功能。如果仍然遇到超时问题,您可以尝试减少此设置。

public Statement setFetchSize(int fetchSize)

(查看更多)

如果您正在使用cli,您可能需要尝试一些手动分页:

SELECT KeywordId, Date, HourOfDay, Impressions, Clicks,AveragePosition,ConversionRate,AOV,AverageCPC,Bid 
FROM StatisticsKeyspace.hourlystatistics 
WHERE Date >= '2014-03-22' AND Date <= '2014-03-24' 
LIMIT 100;

SELECT * FROM ....  WHERE token(KeywordId) > token([Last KeywordId received]) AND ...
LIMIT 100;

为了检测一些集群问题,您可以尝试使用限制为1的select语句,也许存在潜在的问题。
希望对您有所帮助。
如果您的查询仍然存在性能问题,我建议您查看您的二级索引,因为传输的数据量似乎是合理的(只返回“小”数据类型)。如果我没错的话,更改提取大小不会有太大变化。 相反,您是否只在“日期”(时间戳)列中插入日期?如果您插入实际的时间戳,由于基数较高,该列上的二级索引将非常缓慢。如果您只插入日期,则时间戳将默认为日期+"00:00:00"+TZ,这应该减少基数,从而提高查找速度。(注意时区问题!)为了绝对确定,尝试在具有不同数据类型的列上进行二级索引,例如Date的int(计算自1970-01-01以来的天数或其他内容)。

1
谢谢!实际上我已经更改了SocketOptions并在我的Datastax Java客户端中设置了超时。现在它不会超时,但是需要很长时间。您认为通过调整FetchSize可以提高性能吗? - Wild Goat
1
我更新了我的回答。尝试减少FetchSize是否有助于确定问题所在。也许是次要索引(请参见我的回答)。 - John
1
谢谢您的回复。我仍然不明白为什么时间戳会降低性能,因为我将其舍入到午夜,按照我的理解,索引数量不应该与自1970年以来的天数有所变化,但我现在一定会尝试!另外,您认为我应该将我的日期作为主索引,关键字ID作为次要索引,这对我的插入/读取性能有何影响?非常感谢! - Wild Goat
1
PK的主要影响是在节点之间的分布。为了获得最佳的写入性能,您需要均匀分布。仅使用与时间相关的属性将始终导致热点(例如,在10:00到11:00之间的每次写入可能都会发送到同一节点)。您能否提供有关“keywordId”字段的一些信息?如果关键字ID数量有限,则可以随时将其添加为另一个辅助索引,并查看是否增加了查找速度。此外,尝试监视读/写吞吐量,例如使用Datastax opsCenter或类似工具。 - John
1
谢谢!我尝试使用自1970年以来的int天数,看起来它提高了性能,但无论如何,我只有一个节点,请问您能否解释一下这种行为以及为什么它更快,考虑到我将所有日期四舍五入到午夜00:00:00并在一个节点上运行。此外,我的关键字是以下格式的字符串:53961673d446bd71503d8bde - Wild Goat
显示剩余5条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接