Re: RE: Re: Re: High mutation stage in multi dc deployment

This is sufficiently atypical that many people aren't going to have enough intuition to figure it out without seeing your metrics / logs / debugging data (e.g. heap dumps). My only guess, and it's a pretty big guess, is that your write timeout is low enough (or network quality bad enough, though

RE: RE: Re: Re: High mutation stage in multi dc deployment

Kindly help in this regard. What could be the possible reason for load and mutation spike in india data center On 2021/07/20 00:14:56 MyWorld wrote: > Hi Arvinder, > It's a separate cluster. Here max partition size is 32mb. > > On 2021/07/19 23:57:27 Arvinder Dhillon wrote: > > Is this the same cl

Re: R/W timeouts VS number of tables in keyspace

Thanks Sean, I'm switching to G1 in order to gain some time while refactoring. I should be able to go down to 4 tables! Yes, the original design was that poor. Thanks again On Tue, Jul 20, 2021 at 6:41 AM Durity, Sean R wrote: > Each table in the cluster will have a memtable. This is why you d

RE: RE: Storing user activity logs

Thanks Elliott, Sean, Manish for the quick response. On 2021/07/20 13:31:17 "Durity, Sean R" wrote: > Yes, use the time-bucketing approach and choose a bucket-size (included in the partition key) that is granular enough to keep partitions to about 100 MB in size. (Unbounded partitions WILL destroy

Re: Do TTLs generate tombstones?

Both are true If you have a cell that exists in a data file that has expired, but not yet been compacted away, the read path will treat it like a delete/tombstone. Imagine you write a value (no tombstone) - set val=A 2 minutes later, you write a new value (set val=B) on top of it with an expirati

Do TTLs generate tombstones?

I was reading the docs here: https://docs.datastax.com/en/archived/cql/3.1/cql/cql_using/use_expire_c.html It says "Expired data is marked with a tombstone after on the next read on the read path” - is this correct?

RE: R/W timeouts VS number of tables in keyspace

Each table in the cluster will have a memtable. This is why you do not want to fracture the memory into 900+ slices. The rule of thumb I have followed is to stay in the low hundreds (maybe 200) tables for the whole cluster. I would be requiring the hard refactoring (or moving tables to different

RE: Storing user activity logs

Yes, use the time-bucketing approach and choose a bucket-size (included in the partition key) that is granular enough to keep partitions to about 100 MB in size. (Unbounded partitions WILL destroy your cluster.) If your queries *need* to retrieve all user activity over a certain period, then, ye