Re: Hi-Rez of Apache Cassandra logo??

[Nate McCall]

Super cool. Thanks folks!

On Fri, May 18, 2018, 5:57 PM Michael Shuler  wrote:

> Nice, thanks!
>
> I went ahead and committed the files to SVN. I hope that was OK, Scott :)
>
> https://svn.apache.org/repos/asf/cassandra/logo/
>
> 
> r1831825 | mshuler | 2018-05-18 00:53:54 -0500 (Fri, 18 May 2018) | 5 lines
>
> Add Apache Cassandra logos provided by Scott Andreas
>
> Since Scott uploaded them to a temporary location, let's add them here.
>
> https://lists.apache.org/thread.html/981adf13e8d483d9de41bf5ab30328aafe8544da6b36036e64744046@%3Cdev.cassandra.apache.org%3E
>
> --
> Kind regards,
> Michael
>
> On 05/18/2018 12:23 AM, Scott Andreas wrote:
> > Hi Nate,
> >
> > Here are vectorized versions of the logo reading "Apache Cassandra":
> > – http://paradoxica.net/img/cassandra/apache-cassandra.pdf
> > – http://paradoxica.net/img/cassandra/apache-cassandra.eps
> >
> > This is not an official graphic, but for the sake of provenance:
> >
> > – The image is sourced from:
> https://svn.apache.org/repos/asf/cassandra/logo/cassandra.svg
> > – I've replaced "cassandra" with "apache cassandra" set in Cronos Pro
> Bold Italic (which I believe is the original typeface).
> > – And exported as a vector PDF and EPS, which should be scalable to any
> size you need.
> >
> > The above URLs are not permanent; since the list allows max-1MB
> attachments, I've uploaded them to a temporary location.
> >
> > Happy to make changes or to share in another format if that works better.
> >
> > – Scott
> >
> > 
> > From: Nate McCall 
> > Sent: Thursday, May 17, 2018 9:45:18 PM
> > To: dev
> > Subject: Hi-Rez of Apache Cassandra logo??
> >
> > I'm looking for a hi-rez source of 'the eye' with "Apache Cassandra"
> > (that last part is important) basically what we have on the website.
> > I'm gonna run off some laptop stickers on sticker mule.
> >
> > Provided I can track that down, you can have one if you show up here:
> > https://www.meetup.com/Apache-Cassandra-Bay-Area/events/250901453/
> >
> > Once I get this squared away, i'll create a template and share it
> > somewhere (maybe check it in?) so anyone can print "Apache Cassandra"
> > stuff provided they follow the merchandising guidelines:
> > https://www.apache.org/foundation/marks/merchandise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

secondary index table - tombstones surviving compactions

[Roman Bielik]

Hi,

I have a Cassandra 3.11 table (with compact storage) and using secondary
indices with rather unique data stored in the indexed columns. There are
many inserts and deletes, so in order to avoid tombstones piling up I'm
re-using primary keys from a pool (which works fine).
I'm aware that this design pattern is not ideal, but for now I can not
change it easily.

The problem is, the size of 2nd index tables keeps growing (filled with
tombstones) no matter what.

I tried some aggressive configuration (just for testing) in order to
expedite the tombstone removal but with little-to-zero effect:
COMPACTION = { 'class':
'LeveledCompactionStrategy', 'unchecked_tombstone_compaction': 'true',
'tombstone_compaction_interval': 600 }
gc_grace_seconds = 600

I'm aware that perhaps Materialized views could provide a solution to this,
but I'm bind to the Thrift interface, so can not use them.

Questions:
1. Is there something I'm missing? How come compaction does not remove the
obsolete indices/tombstones from 2nd index tables? Can I trigger the
cleanup manually somehow?
I have tried nodetool flush, compact, rebuild_index on both data table and
internal Index table, but with no result.

2. When deleting a record I'm deleting the whole row at once - which would
create one tombstone for the whole record if I'm correct. Would it help to
delete the indexed columns separately creating extra tombstone for each
cell?
As I understand the underlying mechanism, the indexed column value must be
read in order a proper tombstone for the index is created for it.

3. Could the fact that I'm reusing the primary key of a deleted record
shortly for a new insert interact with the secondary index tombstone
removal?

Will be grateful for any advice.

Regards,
Roman

-- 
 
  
  
  

Review needed: Resume compresed hints delivery broken in Cassandra 3.0

[Tommy Stendahl]

Hi,

If someone have the time to review CASSANDRA-14419: Resume compresed 
hints delivery broken 
 it would be much 
appreciated.


Resume hint delivery is broken in the 3.0 branch, the same problem 
existed in 3.x but was fixed by CASSANDRA-11960. This patch is very 
similar to CASSANDRA-11960.


/Tommy

Re: secondary index table - tombstones surviving compactions

[Eric Stevens]

The answer to Question 3 is "yes."  One of the more subtle points about
tombstones is that Cassandra won't remove them during compaction if there
is a bloom filter on any SSTable on that replica indicating that it
contains the same partition (not primary) key.  Even if it is older than
gc_grace, and would otherwise be a candidate for cleanup.

If you're recycling partition keys, your tombstones may never be able to be
cleaned up, because in this scenario there is a high probability that an
SSTable not involved in that compaction also contains the same partition
key, and so compaction cannot have confidence that it's safe to remove the
tombstone (it would have to fully materialize every record in the
compaction, which is too expensive).

In general it is an antipattern in Cassandra to write to a given partition
indefinitely for this and other reasons.

On Fri, May 18, 2018 at 2:37 AM Roman Bielik <
roman.bie...@openmindnetworks.com> wrote:

> Hi,
>
> I have a Cassandra 3.11 table (with compact storage) and using secondary
> indices with rather unique data stored in the indexed columns. There are
> many inserts and deletes, so in order to avoid tombstones piling up I'm
> re-using primary keys from a pool (which works fine).
> I'm aware that this design pattern is not ideal, but for now I can not
> change it easily.
>
> The problem is, the size of 2nd index tables keeps growing (filled with
> tombstones) no matter what.
>
> I tried some aggressive configuration (just for testing) in order to
> expedite the tombstone removal but with little-to-zero effect:
> COMPACTION = { 'class':
> 'LeveledCompactionStrategy', 'unchecked_tombstone_compaction': 'true',
> 'tombstone_compaction_interval': 600 }
> gc_grace_seconds = 600
>
> I'm aware that perhaps Materialized views could provide a solution to this,
> but I'm bind to the Thrift interface, so can not use them.
>
> Questions:
> 1. Is there something I'm missing? How come compaction does not remove the
> obsolete indices/tombstones from 2nd index tables? Can I trigger the
> cleanup manually somehow?
> I have tried nodetool flush, compact, rebuild_index on both data table and
> internal Index table, but with no result.
>
> 2. When deleting a record I'm deleting the whole row at once - which would
> create one tombstone for the whole record if I'm correct. Would it help to
> delete the indexed columns separately creating extra tombstone for each
> cell?
> As I understand the underlying mechanism, the indexed column value must be
> read in order a proper tombstone for the index is created for it.
>
> 3. Could the fact that I'm reusing the primary key of a deleted record
> shortly for a new insert interact with the secondary index tombstone
> removal?
>
> Will be grateful for any advice.
>
> Regards,
> Roman
>
> --
>  
>  
> 
>   
>

Re: secondary index table - tombstones surviving compactions

[Jeff Jirsa]

This would matter for the base table, but would be less likely for the 
secondary index, where the partition key is the value of the base row

Roman: there’s a config option related to only purging repaired tombstones - do 
you have that enabled ? If so, are you running repairs?

-- 
Jeff Jirsa


> On May 18, 2018, at 6:41 AM, Eric Stevens  wrote:
> 
> The answer to Question 3 is "yes."  One of the more subtle points about
> tombstones is that Cassandra won't remove them during compaction if there
> is a bloom filter on any SSTable on that replica indicating that it
> contains the same partition (not primary) key.  Even if it is older than
> gc_grace, and would otherwise be a candidate for cleanup.
> 
> If you're recycling partition keys, your tombstones may never be able to be
> cleaned up, because in this scenario there is a high probability that an
> SSTable not involved in that compaction also contains the same partition
> key, and so compaction cannot have confidence that it's safe to remove the
> tombstone (it would have to fully materialize every record in the
> compaction, which is too expensive).
> 
> In general it is an antipattern in Cassandra to write to a given partition
> indefinitely for this and other reasons.
> 
> On Fri, May 18, 2018 at 2:37 AM Roman Bielik <
> roman.bie...@openmindnetworks.com> wrote:
> 
>> Hi,
>> 
>> I have a Cassandra 3.11 table (with compact storage) and using secondary
>> indices with rather unique data stored in the indexed columns. There are
>> many inserts and deletes, so in order to avoid tombstones piling up I'm
>> re-using primary keys from a pool (which works fine).
>> I'm aware that this design pattern is not ideal, but for now I can not
>> change it easily.
>> 
>> The problem is, the size of 2nd index tables keeps growing (filled with
>> tombstones) no matter what.
>> 
>> I tried some aggressive configuration (just for testing) in order to
>> expedite the tombstone removal but with little-to-zero effect:
>> COMPACTION = { 'class':
>> 'LeveledCompactionStrategy', 'unchecked_tombstone_compaction': 'true',
>> 'tombstone_compaction_interval': 600 }
>> gc_grace_seconds = 600
>> 
>> I'm aware that perhaps Materialized views could provide a solution to this,
>> but I'm bind to the Thrift interface, so can not use them.
>> 
>> Questions:
>> 1. Is there something I'm missing? How come compaction does not remove the
>> obsolete indices/tombstones from 2nd index tables? Can I trigger the
>> cleanup manually somehow?
>> I have tried nodetool flush, compact, rebuild_index on both data table and
>> internal Index table, but with no result.
>> 
>> 2. When deleting a record I'm deleting the whole row at once - which would
>> create one tombstone for the whole record if I'm correct. Would it help to
>> delete the indexed columns separately creating extra tombstone for each
>> cell?
>> As I understand the underlying mechanism, the indexed column value must be
>> read in order a proper tombstone for the index is created for it.
>> 
>> 3. Could the fact that I'm reusing the primary key of a deleted record
>> shortly for a new insert interact with the secondary index tombstone
>> removal?
>> 
>> Will be grateful for any advice.
>> 
>> Regards,
>> Roman
>> 
>> --
>> 
>> 
>> 
>>   
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Hi-Rez of Apache Cassandra logo??

[Gary Dusbabek]

If you need any modifications (color, vector conversions, etc.) hit me up.

Gary.


On Thu, May 17, 2018 at 11:45 PM Nate McCall  wrote:

> I'm looking for a hi-rez source of 'the eye' with "Apache Cassandra"
> (that last part is important) basically what we have on the website.
> I'm gonna run off some laptop stickers on sticker mule.
>
> Provided I can track that down, you can have one if you show up here:
> https://www.meetup.com/Apache-Cassandra-Bay-Area/events/250901453/
>
> Once I get this squared away, i'll create a template and share it
> somewhere (maybe check it in?) so anyone can print "Apache Cassandra"
> stuff provided they follow the merchandising guidelines:
> https://www.apache.org/foundation/marks/merchandise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>