【问题标题】:Cassandra read timeoutCassandra 读取超时
【发布时间】:2014-08-06 04:31:51
【问题描述】:

我正在从 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 秒内引发超时。有什么想法可以解决这个问题吗?

【问题讨论】:

  • 这是使用 cassandra-cli 还是 java 应用程序?从您的标签来看,尽管查询提示 cli,但仍不清楚。

标签: cassandra cassandra-2.0 datastax datastax-java-driver cassandra-cli


【解决方案1】:

如果使用 datastax 中的 java 客户端,分页默认启用,行集为 5000。如果仍然超时,可以尝试使用

public Statement setFetchSize(int fetchSize)

(read more)

如果您使用的是 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 的选择,可能存在潜在问题。

希望对您有所帮助。

如果您的查询仍然遇到性能问题,我会查看您的二级索引,因为传输的数据量似乎是合理的(仅返回“小”数据类型)。如果我是对的,更改 fetch 大小不会有太大变化。 相反,您是否仅在“日期”(时间戳)列中插入日期?如果您要插入实际时间戳,则由于基数,此列上的二级索引将非常慢。如果您只插入一个日期,时间戳will default to date + "00:00:00" + TZ 应该减少基数,从而提高查找速度。 (注意时区问题!)绝对确定,尝试在具有不同数据类型的列上使用二级索引,例如日期的 int (计算自 1970-01-01 或某事以来的天数)。

【讨论】:

  • 谢谢!我实际上被更改了SocketOptions 并在我的datastax java 客户端中设置了超时。现在它不会超时,但需要很长时间。你认为我可以通过调整FetchSize 来提高性能吗?
  • 我更新了我的答案。尝试减小 FetchSize 是否有助于查明问题。也许它是二级索引(见我的回答)。
  • 感谢您的回复。我仍然不明白为什么时间戳会降低性能,因为我将它四舍五入到午夜,据我所知,索引的数量不应该与自 1970 年以来的天数有所不同,但我现在肯定会尝试!另外,您是否认为我应该将我的 Date 作为主索引,将 keywordId 作为次要索引,这将如何反映我的 INSERT/READ 性能?非常感谢!
  • 嗯,PK的主要影响是你的节点之间的分布。为了获得最佳写入性能,您需要均匀分布。仅使用与时间相关的属性将始终导致热停止(例如,10:00 到 11:00 之间的每次写入都可能转到同一个节点)。你能提供一些关于你的“keywordId”字段的信息吗?如果关键字 Id 的数量有限,您可以随时将其添加为另一个二级索引,看看这是否会提高查找速度。此外,尝试监控读/写吞吐量,例如使用 Datastax opsCenter 或类似工具。
  • 谢谢!我从 1970 年开始尝试使用 int days 并且看起来它提高了性能,但无论如何我只有一个节点,你能否解释一下这种行为以及为什么它更快考虑到我将所有日期四舍五入到午夜 00:00:00 的事实并在一个节点上运行。另外,我的关键字是以下格式的字符串:53961673d446bd71503d8bde
猜你喜欢
  • 2019-08-14
  • 2016-11-26
  • 1970-01-01
  • 2013-07-09
  • 2019-07-28
  • 2015-08-25
  • 2014-07-02
  • 2020-03-24
  • 2015-07-24
相关资源
最近更新 更多