need to run “nodetool repair” reflects a design
> bug; it should be automated.
>
>
>
> Don
>
>
>
> *From:* Laing, Michael [mailto:michael.la...@nytimes.com]
> *Sent:* Sunday, April 06, 2014 11:31 AM
> *To:* user@cassandra.apache.org
> *Subject:* Re: Timeseries
omated.
Don
From: Laing, Michael [mailto:michael.la...@nytimes.com]
Sent: Sunday, April 06, 2014 11:31 AM
To: user@cassandra.apache.org
Subject: Re: Timeseries with TTL
Since you are using LeveledCompactionStrategy there is no major/minor
compaction - just compaction.
Leveled compaction doe
Since you are using LeveledCompactionStrategy there is no major/minor
compaction - just compaction.
Leveled compaction does more work - your logs don't look unreasonable to me
- the real question is whether your nodes can keep up w the IO. SSDs work
best.
BTW if you never delete and only ttl your
Hi,
Most of the queries to that table are just getting a range of values for a
metric:
SELECT val FROM metrics_5min WHERE uid = ? AND metric = ? AND ts >= ? AND
ts <= ?
I'm not sure from the logs what kind of compactions they are. This is what
I see in system.log (grepping for that specific table
Hi Vincent,
> Is that a good pattern for Cassandra? Is there some compaction tunings
> I should take into account?
Actually it depends on how you use Cassandra :). If you use it as
key-value storage TTL works fine. But if you would use rather complex
CQL queries to this table I not sure that it wo
Hi there,
I have this table where I'm inserting timeseries values with a TTL of
86400*7 (1week):
CREATE TABLE metrics_5min (
object_id varchar,
metric varchar,
ts timestamp,
val double,
PRIMARY KEY ((object_id, metric), ts)
)
WITH gc_grace_seconds = 86400
AND compaction = {'class': 'Lev
