RE: Insert Vs Updates - Both create tombstones

Thank you, We are updating the entire row (all columns) each second via the “insert” command. So if we did updates – no tombstones would be created? But because we are doing inserts- we are creating tombstones for each column each insert? From: Ali Akhtar [mailto:ali.rac...@gmail.com] Sent: 13

RE: Insert Vs Updates - Both create tombstones

If this how you update then you are not creating tombstones. If you used UPDATE it’s the same behavior. You are simply inserting a new value for the cell which does not create a tombstone. When you modify data by using either the INSERT or the UPDATE command the value is stored along with a time

RE: Insert Vs Updates - Both create tombstones

Thanks ☺ I think you might have got your T’s and V’s mixed up ? So we insert V2 @ T2, then insert V1 @ T1 where T1 is earlier to T2 = V2 Should it not be the other way around? So we insert V1 @ T1, then insert V2 @ T2 where T2 is earlier to T2 = V2 So in a tombstone manor over 5 seconds we a

LeveledCompactionStrategy

Hi, I’m using Cassandra 2.1.4 with a table using LeveledCompactionStrategy. Often I need to delete many rows and I want to make sure I don’t have too many tombstones. How does one get rid of tombstones in a table using LCS? How can we monitor how many tombstones are around? Thanks for your help

RE: Insert Vs Updates - Both create tombstones

I think you have over-simplified it just a bit here, though I may be wrong. In order to get a tombstone on a TTL row or column, some kind of read has to occur. The tombstones don’t magically appear (remember, a tombstone is a special kind of insert). So, I think it takes at least two compactions

Updating Table Schemas Slows Down Cluster

Hi all, We're running a 24 node cluster and we've noticed that whenever we either update an existing table or add a new table, the cluster's load increases immensely during and after for about 1 minute, triggering a lot of read and write timeouts. Has anyone seen this behavior before or have any

Re: Updating Table Schemas Slows Down Cluster

You might be seeing the effects of https://issues.apache.org/jira/browse/CASSANDRA-9136 which was just fixed in 2.0.15. The connection thrashing from the above would definitely cause some hiccups. On Thu, May 14, 2015 at 3:10 PM, Christopher Kelly wrote: > Hi all, > > We're running a 24 node cl

Re: LeveledCompactionStrategy

You can make LCS more aggressive with tombstone-only compactions via seting unchecked_tombstone_compaction=true and turn down tombstone_threshold to 0.05 (maybe going up or down as needed). Details on both can be found here: http://docs.datastax.com/en/cql/3.1/cql/cql_reference/compactSubprop.html

Re: CQL Data Model question

Thanks Ngoc, Jack On Tue, May 12, 2015 at 4:56 AM, Ngoc Minh VO wrote: > Hello, > > > > The problem with your approach is: you will need to specify all the 30 > filters (in the pre-defined order in PK) when querying. > > > > I would go for this data model: > > CREATE TABLE t ( > > name text

Re: LeveledCompactionStrategy

Thanks a lot. On 14 May 2015, at 22:45 , Nate McCall mailto:n...@thelastpickle.com>> wrote: You can make LCS more aggressive with tombstone-only compactions via seting unchecked_tombstone_compaction=true and turn down tombstone_threshold to 0.05 (maybe going up or down as needed). Details on bo