I recommend truncating the table instead of dropping it since you don’t need to
re-issue DDL commands and put load on the system keyspace.
Both DROP and TRUNCATE automatically create snapshots, there no “snapshotting”
advantage for using DROP . See
http://docs.datastax.com/en/cassandra/2.1/cassa
Hello there,
We have a 3 node cluster with Cassandra 2.0.8 version. I am seeing data
that should be dropped already. In JMX, I can see that
DroppableTombstoneRatio is 0.68 for the column family and the
tombstone_threshold was left as default for the CF. We are using LCS on
related CF and replicati
Thanks Peer. I like the approach you're suggesting.
Why do you recommend truncating the last active table rather than just
dropping it? Since all the data would be inserted into a new table, seems
like it would make sense to drop the last table, and that way truncate
snapshotting also won't have t
Interesting approach Oded.
Is this something similar that has been described here:
http://radar.oreilly.com/2014/07/questioning-the-lambda-architecture.html
Regards,
Shahab
On Sun, Apr 26, 2015 at 4:29 AM, Peer, Oded wrote:
> I would maintain two tables.
>
> An “archive” table that holds all
I would maintain two tables.
An “archive” table that holds all the active and inactive records, and is
updated hourly (re-inserting the same record has some compaction overhead but
on the other side deleting records has tombstones overhead).
An “active” table which holds all the records in the la
