RE: Insert Vs Updates - Both create tombstones

[Walsh, Stephen]

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 May 2015 12:10
To: user@cassandra.apache.org
Subject: Re: Insert Vs Updates - Both create tombstones

Sorry, wrong thread. Disregard the above

On Wed, May 13, 2015 at 4:08 PM, Ali Akhtar 
mailto:ali.rac...@gmail.com>> wrote:
If specifying 'using' timestamp, the docs say to provide microseconds, but 
where are these microseconds obtained from? I have regular java.util.Date 
objects, I can get the time in milliseconds (i.e the unix timestamp), how would 
I convert that to microseconds?

On Wed, May 13, 2015 at 3:45 PM, Peer, Oded 
mailto:oded.p...@rsa.com>> wrote:
Under the assumption that when you update the columns you also update the TTL 
for the columns then a tombstone won’t be created for those columns.
Remember that TTL is set on columns (or “cells”), not on rows, so your 
description of updating a row is slightly misleading. If every query updates 
different columns then different columns might expire at different times.

From: Walsh, Stephen 
[mailto:stephen.wa...@aspect.com]
Sent: Wednesday, May 13, 2015 1:35 PM
To: user@cassandra.apache.org
Subject: Insert Vs Updates - Both create tombstones

Quick Question,

Our team is under much debate, we are trying to find out if an Update on a row 
with a TTL will create a tombstone.

E.G

We have one row with a TTL, if we keep “updating” that row before the TTL is 
hit, will a tombstone be created.
I believe it will, but want to confirm.

So if that’s is  true,
And if our TTL is 10 seconds and we “update” the row every second, will 10 
tombstones be created after 10 seconds? Or just 1?
(and does the same apply for “insert”)

Regards
Stephen Walsh


This email (including any attachments) is proprietary to Aspect Software, Inc. 
and may contain information that is confidential. If you have received this 
message in error, please do not read, copy or forward this message. Please 
notify the sender immediately, delete it from your system and destroy any 
copies. You may not further disclose or distribute this email or its 
attachments.


This email (including any attachments) is proprietary to Aspect Software, Inc. 
and may contain information that is confidential. If you have received this 
message in error, please do not read, copy or forward this message. Please 
notify the sender immediately, delete it from your system and destroy any 
copies. You may not further disclose or distribute this email or its 
attachments.

RE: Insert Vs Updates - Both create tombstones

[Peer, Oded]

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 timestamp indicating the timestamp of the value.
Assume timestamp T1 is before T2 (T1 < T2) and you stored value V2 with 
timestamp T2. Then you store V1 with timestamp T1.
Now you have two values of V in the DB: , 
When you read the value of V from the DB you read both , , which 
may be in different sstables, Cassandra resolves the conflict by comparing the 
timestamp and returns V2.
Compaction will later take care and remove  from the DB.


From: Walsh, Stephen [mailto:stephen.wa...@aspect.com]
Sent: Thursday, May 14, 2015 11:39 AM
To: user@cassandra.apache.org
Subject: 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 May 2015 12:10
To: user@cassandra.apache.org
Subject: Re: Insert Vs Updates - Both create tombstones

Sorry, wrong thread. Disregard the above

On Wed, May 13, 2015 at 4:08 PM, Ali Akhtar 
mailto:ali.rac...@gmail.com>> wrote:
If specifying 'using' timestamp, the docs say to provide microseconds, but 
where are these microseconds obtained from? I have regular java.util.Date 
objects, I can get the time in milliseconds (i.e the unix timestamp), how would 
I convert that to microseconds?

On Wed, May 13, 2015 at 3:45 PM, Peer, Oded 
mailto:oded.p...@rsa.com>> wrote:
Under the assumption that when you update the columns you also update the TTL 
for the columns then a tombstone won’t be created for those columns.
Remember that TTL is set on columns (or “cells”), not on rows, so your 
description of updating a row is slightly misleading. If every query updates 
different columns then different columns might expire at different times.

From: Walsh, Stephen 
[mailto:stephen.wa...@aspect.com]
Sent: Wednesday, May 13, 2015 1:35 PM
To: user@cassandra.apache.org
Subject: Insert Vs Updates - Both create tombstones

Quick Question,

Our team is under much debate, we are trying to find out if an Update on a row 
with a TTL will create a tombstone.

E.G

We have one row with a TTL, if we keep “updating” that row before the TTL is 
hit, will a tombstone be created.
I believe it will, but want to confirm.

So if that’s is  true,
And if our TTL is 10 seconds and we “update” the row every second, will 10 
tombstones be created after 10 seconds? Or just 1?
(and does the same apply for “insert”)

Regards
Stephen Walsh


This email (including any attachments) is proprietary to Aspect Software, Inc. 
and may contain information that is confidential. If you have received this 
message in error, please do not read, copy or forward this message. Please 
notify the sender immediately, delete it from your system and destroy any 
copies. You may not further disclose or distribute this email or its 
attachments.


This email (including any attachments) is proprietary to Aspect Software, Inc. 
and may contain information that is confidential. If you have received this 
message in error, please do not read, copy or forward this message. Please 
notify the sender immediately, delete it from your system and destroy any 
copies. You may not further disclose or distribute this email or its 
attachments.

RE: Insert Vs Updates - Both create tombstones

[Walsh, Stephen]

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 are looking like this

Second 1
Insert  with TTL =5
Second 2
 (TTL 4)
Insert  with TTL= 5

Second 3
 (TTL 3)
 (TTL 4)
Insert  with TTL= 5

Second 3
 (TTL 2)
 (TTL 3)
 (TTL 4)
Insert  with TTL= 5

Second 4
 (TTL 1)
 (TTL 2)
 (TTL 3)
 (TTL 4)
Insert  with TTL= 5

Second 5
 (Tombstoned)
 (TTL 1)
 (TTL 2)
 (TTL 3)
 (TTL 4)

Second 6
 (Tombstoned)
 (Tombstoned)
 (TTL 1)
 (TTL 2)
 (TTL 3)

Second 7
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (TTL 1)
 (TTL 2)


Second 8
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (TTL 1)

Second 8
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)

Second 9
(Minor Compaction run to clean up tombstones)


And if I did an “update“, the result would be the same.
And like you mentioned, if I did a query at “second 4”, the query would be 
based of 5 versions of V1 to query against, and the highest T value would be 
returned.




From: Peer, Oded [mailto:oded.p...@rsa.com]
Sent: 14 May 2015 11:12
To: user@cassandra.apache.org
Subject: 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 timestamp indicating the timestamp of the value.
Assume timestamp T1 is before T2 (T1 < T2) and you stored value V2 with 
timestamp T2. Then you store V1 with timestamp T1.
Now you have two values of V in the DB: , 
When you read the value of V from the DB you read both , , which 
may be in different sstables, Cassandra resolves the conflict by comparing the 
timestamp and returns V2.
Compaction will later take care and remove  from the DB.


From: Walsh, Stephen [mailto:stephen.wa...@aspect.com]
Sent: Thursday, May 14, 2015 11:39 AM
To: user@cassandra.apache.org
Subject: 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 May 2015 12:10
To: user@cassandra.apache.org
Subject: Re: Insert Vs Updates - Both create tombstones

Sorry, wrong thread. Disregard the above

On Wed, May 13, 2015 at 4:08 PM, Ali Akhtar 
mailto:ali.rac...@gmail.com>> wrote:
If specifying 'using' timestamp, the docs say to provide microseconds, but 
where are these microseconds obtained from? I have regular java.util.Date 
objects, I can get the time in milliseconds (i.e the unix timestamp), how would 
I convert that to microseconds?

On Wed, May 13, 2015 at 3:45 PM, Peer, Oded 
mailto:oded.p...@rsa.com>> wrote:
Under the assumption that when you update the columns you also update the TTL 
for the columns then a tombstone won’t be created for those columns.
Remember that TTL is set on columns (or “cells”), not on rows, so your 
description of updating a row is slightly misleading. If every query updates 
different columns then different columns might expire at different times.

From: Walsh, Stephen 
[mailto:stephen.wa...@aspect.com]
Sent: Wednesday, May 13, 2015 1:35 PM
To: user@cassandra.apache.org
Subject: Insert Vs Updates - Both create tombstones

Quick Question,

Our team is under much debate, we are trying to find out if an Update on a row 
with a TTL will create a tombstone.

E.G

We have one row with a TTL, if we keep “updating” that row before the TTL is 
hit, will a tombstone be created.
I believe it will, but want to confirm.

So if that’s is  true,
And if our TTL is 10 seconds and we “update” the row every second, will 10 
tombstones be created after 10 seconds? Or just 1?
(and does the same apply for “insert”)

Regards
Stephen Walsh


This email (including any attachments) is proprietary to Aspect Software, Inc. 
and may contain information that is confidential. If you have received this 
message in error, please do not read, copy or forward this message. Please 
notify the sender immediately, delete it from your system and destroy any 
copies. You may not further disclose or distribute this email or its 
attachments.


This email (including any attachments) is proprietary to Aspect Software, Inc. 
and may contain information that is confidential. If you have received this 
message in error, please do not read, copy or forward this message. Please 
notify the sender immediately, delete it fr

LeveledCompactionStrategy

[Jean Tremblay]

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.

Jean

RE: Insert Vs Updates - Both create tombstones

[SEAN_R_DURITY]

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 to 
actually get rid of the data. One compaction to create tombstones, and a second 
one (after gc_grace_seconds) to rewrite the good data and leave out expired 
tombstones. And it has to happen on all replica nodes.

(I suppose it is possible that other kinds of reads might create TTL-based 
tombstones as an optimization, but I don’t know that this exists.)

Someone closer to the source code may correct me, but this is my understanding 
of how it works.

Sean Durity – Cassandra Admin, Big Data Team
To engage the team, create a 
request

From: Walsh, Stephen [mailto:stephen.wa...@aspect.com]
Sent: Thursday, May 14, 2015 6:37 AM
To: user@cassandra.apache.org
Subject: 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 are looking like this

Second 1
Insert  with TTL =5

Second 2
 (TTL 4)
Insert  with TTL= 5

Second 3
 (TTL 3)
 (TTL 4)
Insert  with TTL= 5

Second 3
 (TTL 2)
 (TTL 3)
 (TTL 4)
Insert  with TTL= 5

Second 4
 (TTL 1)
 (TTL 2)
 (TTL 3)
 (TTL 4)
Insert  with TTL= 5

Second 5
 (Tombstoned)
 (TTL 1)
 (TTL 2)
 (TTL 3)
 (TTL 4)

Second 6
 (Tombstoned)
 (Tombstoned)
 (TTL 1)
 (TTL 2)
 (TTL 3)

Second 7
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (TTL 1)
 (TTL 2)


Second 8
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (TTL 1)

Second 8
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)
 (Tombstoned)

Second 9
(Minor Compaction run to clean up tombstones)


And if I did an “update“, the result would be the same.
And like you mentioned, if I did a query at “second 4”, the query would be 
based of 5 versions of V1 to query against, and the highest T value would be 
returned.




From: Peer, Oded [mailto:oded.p...@rsa.com]
Sent: 14 May 2015 11:12
To: user@cassandra.apache.org
Subject: 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 timestamp indicating the timestamp of the value.
Assume timestamp T1 is before T2 (T1 < T2) and you stored value V2 with 
timestamp T2. Then you store V1 with timestamp T1.
Now you have two values of V in the DB: , 
When you read the value of V from the DB you read both , , which 
may be in different sstables, Cassandra resolves the conflict by comparing the 
timestamp and returns V2.
Compaction will later take care and remove  from the DB.


From: Walsh, Stephen [mailto:stephen.wa...@aspect.com]
Sent: Thursday, May 14, 2015 11:39 AM
To: user@cassandra.apache.org
Subject: 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 May 2015 12:10
To: user@cassandra.apache.org
Subject: Re: Insert Vs Updates - Both create tombstones

Sorry, wrong thread. Disregard the above

On Wed, May 13, 2015 at 4:08 PM, Ali Akhtar 
mailto:ali.rac...@gmail.com>> wrote:
If specifying 'using' timestamp, the docs say to provide microseconds, but 
where are these microseconds obtained from? I have regular java.util.Date 
objects, I can get the time in milliseconds (i.e the unix timestamp), how would 
I convert that to microseconds?

On Wed, May 13, 2015 at 3:45 PM, Peer, Oded 
mailto:oded.p...@rsa.com>> wrote:
Under the assumption that when you update the columns you also update the TTL 
for the columns then a tombstone won’t be created for those columns.
Remember that TTL is set on columns (or “cells”), not on rows, so your 
description of updating a row is slightly misleading. If every query updates 
different columns then different columns might expire at different times.

From: Walsh, Stephen 
[mailto:stephen.wa...@aspect.com]
Sent: Wednesday, May 13, 2015 1:35 PM
To: user@cassandra.apache.org
Subject: Insert Vs Updates - Both create tombstones

Quick Question,

Our tea

Updating Table Schemas Slows Down Cluster

[Christopher Kelly]

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 ideas as
to why schema updates are such an intensive operation? We are running on
2.0.10.

Thanks,
Chris

Re: Updating Table Schemas Slows Down Cluster

[Nate McCall]

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 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 ideas as
> to why schema updates are such an intensive operation? We are running on
> 2.0.10.
>
> Thanks,
> Chris
>



-- 
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: LeveledCompactionStrategy

[Nate McCall]

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

As for monitoring tombstones, there is a "tombstoneScannedHistogram" on
ColumnFamilyMetrics which measures how many tombstones were discarded
during reads.

Also, you should take a couple of SSTables from production and use the
sstablemetadata utility specifically looking at "Estimated droppable
tombstones" and "Estimated tombstone drop times" output from such.

Spend some time experimenting with those settings incrementally. Finding
the sweet spot is different for each workload will make a huge difference
in overall performance.



On Thu, May 14, 2015 at 8:06 AM, Jean Tremblay <
jean.tremb...@zen-innovations.com> wrote:
>
> 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.
>
> Jean




--
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: CQL Data Model question

[Alaa Zubaidi (PDF)]

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,
>
> filter_name1 text, filter_value1 text,
>
> filter_name2 text, filter_value2 text,
>
> filter_name3 text, filter_value3 text, -- since you only have up to 3
> filters in one query
>
> PRIMARY KEY (name, f_n1, f_v1, f_n2, f_v2, f_n3, f_v3)
>
> );
>
>
>
> And denormalize the data when you import to the table :
>
> One line in Oracle table with K filters become C(3, K) lines in C* table.
>
>
>
> Best regards,
>
> Minh
>
>
>
> *From:* Alaa Zubaidi (PDF) [mailto:alaa.zuba...@pdf.com]
> *Sent:* lundi 11 mai 2015 20:32
> *To:* user@cassandra.apache.org
> *Subject:* CQL Data Model question
>
>
>
> Hi,
>
>
>
> I am trying to port an Oracle Table to Cassandra.
>
> the table is a wide table (931 columns) and could have millions of rows.
>
>  name, filter1, filter2filter30, data1, data2...data900
>
>
>
> The user would retrieve multiple rows from this table and filter (30
> filter columns) by one or more (up to 3) of the filter columns, it could be
> any of the filter columns.
>
> (select * from table1 where name = .. and filter1 = .. and filter5= .. ;)
>
>
>
> What is the best design for this in Cassandra/CQL?
>
>
>
> I tried the following:
>
> Create table tab1 (
>
> name text,
>
> flt1 text,
>
> flt2 text,
>
> flt3 text,
>
> ..
>
> flt30 text,
>
> data text,
>
> PRIMARY KEY (name, flt1, flt2, flt3, . flt30) );
>
>
>
> Is there any side effects of having 30 composite keys?
>
>
>
> Thanks
>
>
> *This message may contain confidential and privileged information. If it
> has been sent to you in error, please reply to advise the sender of the
> error and then immediately permanently delete it and all attachments to it
> from your systems. If you are not the intended recipient, do not read,
> copy, disclose or otherwise use this message or any attachments to it. The
> sender disclaims any liability for such unauthorized use. PLEASE NOTE that
> all incoming e-mails sent to PDF e-mail accounts will be archived and may
> be scanned by us and/or by external service providers to detect and prevent
> threats to our systems, investigate illegal or inappropriate behavior,
> and/or eliminate unsolicited promotional e-mails (“spam”). If you have any
> concerns about this process, please contact us at *
> *legal.departm...@pdf.com* *.*
>
> This message and any attachments (the "message") is
> intended solely for the intended addressees and is confidential.
> If you receive this message in error,or are not the intended recipient(s),
> please delete it and any copies from your systems and immediately notify
> the sender. Any unauthorized view, use that does not comply with its
> purpose,
> dissemination or disclosure, either whole or partial, is prohibited. Since
> the internet
> cannot guarantee the integrity of this message which may not be reliable,
> BNP PARIBAS
> (and its subsidiaries) shall not be liable for the message if modified,
> changed or falsified.
> Do not print this message unless it is necessary,consider the environment.
>
>
> --
>
> Ce message et toutes les pieces jointes (ci-apres le "message")
> sont etablis a l'intention exclusive de ses destinataires et sont
> confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
> merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
> immediatement l'expediteur. Toute lecture non autorisee, toute utilisation
> de
> ce message qui n'est pas conforme a sa destination, toute diffusion ou
> toute
> publication, totale ou partielle, est interdite. L'Internet ne permettant
> pas d'assurer
> l'integrite de ce message electronique susceptible d'alteration, BNP
> Paribas
> (et ses filiales) decline(nt) toute responsabilite au titre de ce message
> dans l'hypothese
> ou il aurait ete modifie, deforme ou falsifie.
> N'imprimez ce message que si necessaire, pensez a l'environnement.
>



-- 

Alaa Zubaidi
PDF Solutions, Inc.
333 West San Carlos Street, Suite 1000
San Jose, CA 95110  USA
Tel: 408-283-5639
fax: 408-938-6479
email: alaa.zuba...@pdf.com

-- 
*This message may contain confidential and privileged information. If it 
has been sent to you in error, please reply to advise the sender of the 
error and then immediately permanently delete it and all attachments to it 
from your systems. If you are not the intended recipient, do not read, 
copy, disclose or otherwise use this message or any attachments to it. The 
sender disclaims any liability for such unauthorized use. PLEASE NOTE that 
all incoming e-mails sent to PDF e-mail accounts will be archived and may 
be scanned by us and/

Re: LeveledCompactionStrategy

[Jean Tremblay]

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 both can be found here: 
http://docs.datastax.com/en/cql/3.1/cql/cql_reference/compactSubprop.html

As for monitoring tombstones, there is a "tombstoneScannedHistogram" on 
ColumnFamilyMetrics which measures how many tombstones were discarded during 
reads.

Also, you should take a couple of SSTables from production and use the 
sstablemetadata utility specifically looking at "Estimated droppable 
tombstones" and "Estimated tombstone drop times" output from such.

Spend some time experimenting with those settings incrementally. Finding the 
sweet spot is different for each workload will make a huge difference in 
overall performance.



On Thu, May 14, 2015 at 8:06 AM, Jean Tremblay 
mailto:jean.tremb...@zen-innovations.com>> 
wrote:
>
> 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.
>
> Jean




--
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com