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
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 oded.p...@rsa.com wrote:
I would maintain two tables.
An “archive” table
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
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