Is it bad design to rotate tables in Cassandra?

user_304151 0
Viewed 46

We're going to be using Cassandra for storing large volumes of data. This data is inserted and read but never updated or deleted. From what I've understood, UPDATE ops lead to tombstones and DELETE ops to shadows.

In order to design around this, intend to use monthly tables and TRUNCATE and then DROP tables after n (approx 4) months. Under the assumption that the data is evenly distributed and there's enough disk to store this - are there any other caveats to this approach.

On a side note, is there a technical term for this schema design? I'm happy to share more information if the question needs more details.

cassandra
1 Answers

I have seen some projects that were doing that to avoid deletions, so they just had the monthly tables, that were removed after N months by just dropping them (you don't need to do TRUNCATE before drop!). But that knowledge about table naming required that applications knew about it.

But in your case Time Window Compaction Strategy in combination with TTLs may work better because it drop the whole SSTables when all data in them expires. You can look into this blog post for explanations on how it works and where it should be used.

Alex_Ott_186270
Related