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
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
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
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
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
