CODEWITHSUNDEEP
javacassandradatabasenosql
Gaurav Verma
Gaurav Verma

Reputation: 43

Low TTL with Leveled Compaction, should I reduce gc_grace_seconds to improve read performance without impacting delete replication?

Low TTL with Leveled Compaction, should I reduce gc_grace_seconds to improve read performance?

Scenario: Cassandra Table to cache an external db values - read performance needs to be good (less than 100ms) TTL = 4 hrs at row level Functional full table refresh (delete and then lazy load) every 6 hrs If I keep gc_grace_seconds at default value of 10 days, I can potentially have 60 rows with tombstones for every live row. This will affect read performance. Or not?

Is reducing gc_grace_seconds to say 1 day a safe enough value to allow delete replication across nodes? Given that even if a node is out of tier for some issue, it should be brought back in less than a day. Will this improve read performance?

Upvotes: 4

Views: 733

Answers (1)

Aaron
Aaron

Reputation: 57798

I can potentially have 60 rows with tombstones for every live row. This will affect read performance. Or not?

Yes, it will definitely affect your read performance. At a data/tombstone ratio of 1:60, you'll be asking Cassandra to weed through 60 deletes for every good row. If you have a lot of records, it will probably perform pretty terribly.

Is reducing gc_grace_seconds to say 1 day a safe enough value to allow delete replication across nodes? Given that even if a node is out of tier for some issue, it should be brought back in less than a day. Will this improve read performance?

This should improve your read performance significantly. But the drawback, is that if you have a node drop out of the cluster, you then only have 1 day to get it back in before it has no idea about the delete. But even if you miss it, you should be able to get your node back to a consistent state by running a nodetool repair. Otherwise you'll run the possible risk of deleted data re-appearing.

Upvotes: 3

Related Questions