I do not know if it can really help in your situation,
but from NGCC notes I discovered the existence of GatlingCQL (
https://github.com/gatling-cql/GatlingCql) as an alternative to
cassandra-stress.
In particular you can tweak a bit the data generation part.
giampaolo
2016-06-16 10:33 GMT+02:0
Thanks Paulo. I made some changes along those lines, and seeing good
improvement. I will discuss further (with a possible patch) on
https://issues.apache.org/jira/browse/CASSANDRA-4663 (this is for bootstrap, so
maybe we can repurpose it for rebuilds or create a separate one).
From: Paulo Motta
Hello! Recently I have been trying to familiarize myself with Cassandra but
don't quite understand when data is removed from disk after it has been
deleted. The use case I'm particularly interested is expiring time series data
with DTCS. As an example, I created the following table:
CREATE TABL
First, DTCS in 2.0.15 has some weird behaviors -
https://issues.apache.org/jira/browse/CASSANDRA-9572 .
That said, some other general notes:
Data deleted by TTL isn’t the same as issuing a delete – each expiring cell
internally has a ttl/timestamp at which it will be converted into a tombs
Hey Jeff,
Do most of those behaviors apply to TWCS too?
-J
On Fri, Jun 17, 2016 at 1:25 PM, Jeff Jirsa
wrote:
> First, DTCS in 2.0.15 has some weird behaviors -
> https://issues.apache.org/jira/browse/CASSANDRA-9572 .
>
>
>
> That said, some other general notes:
>
>
> Data deleted by TTL isn’t
Hi Jeff,
Thanks for the information! That helps clear up a lot of things for me. We've
had issues with SSTables not being dropped despite being past their TTLs (no
read repairs or deletes) and I think issue 9572 explains why (definitely going
to look into updating soon). Just to clarify, in th
getFullyExpiredSSTables behavior and read repair mixing data apply to TWCS as
well, though TWCS does a major compaction per window to try to decrease the
interwoven graph that can happen in DTCS windows with sstable expired blockers
(and the way DTCS windowing works, using minTimestamp to choos
Anytime the memtable is flushed to disk, the compaction strategy will look for
tables to compact. If there exists fully expired sstables (again, where
getFullyExpiredSStables agrees that they’re fully expired, which may not be
when YOU think they’re fully expired), they’ll be included/dropped.
Correcting myself - https://issues.apache.org/jira/browse/CASSANDRA-9882 made
it check for fully expired tables no more than once every 10 minutes (still
happens on flush as described, just not EVERY flush). Went in 2.0.17 / 2.1.9.
- Jeff
From: Jeff Jirsa
Reply-To:
Date: Frida
Got it. Thanks again! But in versions of Cassandra after 2.0.15
getFullyExpiredSSTables is more in line with what people would consider to be
fully expired (i.e. any SSTable whose newest value is past the default TTL for
the table)?
From: Jeff Jirsa
Sent: Frida
Also, just out of curiosity, if the TTL is stored internally in the cell does
that mean Cassandra checks the timestamp everytime it reads the data to
determine if its valid?
Thanks,
Jerome
From: jerome
Sent: Friday, June 17, 2016 4:32:47 PM
To: user@cassandra
Hi,
I downloaded Cassandra 3.6/3.7 and on my OSX machine having Java 1.8.0_45,
I can't launch whenever I try to launch it using
"bin/cassandra -f"
it gives me error
"Error: Could not find or load main class -ea"
Any help is appreciated.
Thanks
Ali
12 matches
Mail list logo
