TTL rows with 2i

[Eduardo Alonso]

Hi,

We have been investigating how to include in our 2i implementation the
ability to index TTL expirable Cells in Cassandra 3.x.

Reading comments in o.a.c.index.Index.Indexer.removeRows it seems that this
method is called when a compaction detects that a cell has expired.

I dont know if this is correct, so the question is:

How does the non-columnFamily based 2i get notified when a row ttl has
expired?

I have checked the only two calls to Indexer.removeRows in
o.a.c.index.SecondaryIndexManager.IndexGCTransaction.commit in the
followings releases and it seems that has not changed at all.

Sam Tunnicliffe, any ideas about this??

Regards


Eduardo Alonso
Vía de las dos Castillas, 33, Ática 4, 3ª Planta
28224 Pozuelo de Alarcón, Madrid
Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
*

Re: TTL rows with 2i

[Sam Tunnicliffe]

The problem with row level ttls in this regard is that the scope of a
particular compaction may not include all versions of a given row. So just
because a primary key liveness denoting an expired row may be written to
the new SSTable, it doesn't necessarily mean that an index should purge its
entry/entries for that row. That said, it should probably be the
responsibility of the index implementation to manage that, but at the
moment the {{onPrimaryKeyLivenessInfo}} event during compaction doesn't
cause the registered indexes to be notified. I've opened
https://issues.apache.org/jira/browse/CASSANDRA-11329 for this.


On Wed, Mar 9, 2016 at 4:05 PM, Eduardo Alonso 
wrote:

> Hi,
>
> We have been investigating how to include in our 2i implementation the
> ability to index TTL expirable Cells in Cassandra 3.x.
>
> Reading comments in o.a.c.index.Index.Indexer.removeRows it seems that this
> method is called when a compaction detects that a cell has expired.
>
> I dont know if this is correct, so the question is:
>
> How does the non-columnFamily based 2i get notified when a row ttl has
> expired?
>
> I have checked the only two calls to Indexer.removeRows in
> o.a.c.index.SecondaryIndexManager.IndexGCTransaction.commit in the
> followings releases and it seems that has not changed at all.
>
> Sam Tunnicliffe, any ideas about this??
>
> Regards
>
>
> Eduardo Alonso
> Vía de las dos Castillas, 33, Ática 4, 3ª Planta
> 28224 Pozuelo de Alarcón, Madrid
> Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
> *
>

Able to reproduce JAVA-268

[Saurabh Sethi]

Hi,

I am able to reproduce the following Cassandra bug with version 3.3 and would 
like to add more info to Jira like stack trace and debug log:

https://datastax-oss.atlassian.net/browse/JAVA-268

Can someone gime me temporary access to upload them and add my comments?

Thanks,
Saurabh

Re: Able to reproduce JAVA-268

[Brandon Williams]

This doesn't really belong on dev@ but user@, however I believe you can
just create a jira account there and do what you want.

On Wed, Mar 9, 2016 at 7:50 PM, Saurabh Sethi 
wrote:

> Hi,
>
> I am able to reproduce the following Cassandra bug with version 3.3 and
> would like to add more info to Jira like stack trace and debug log:
>
> https://datastax-oss.atlassian.net/browse/JAVA-268
>
> Can someone gime me temporary access to upload them and add my comments?
>
> Thanks,
> Saurabh
>

Re: Cassandra-stress output

[Stefania Alborghetti]

On Tue, Mar 8, 2016 at 8:39 PM, Jean Carlo 
wrote:

> Hi guys,
>
> I use cassandra stress to populate the next table
>
> CREATE TABLE cf1 (
> kvalue text,
> ktype text,
> prov text,
> dname text,
> dattrib blob,
> dvalue text,
> PRIMARY KEY (kvalue, ktype, prov, dname)
>   ) WITH bloom_filter_fp_chance = 0.01
>  AND caching = '{"keys":"ALL", "rows_per_partition":"60"}'
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.SnappyCompressor'}
> AND dclocal_read_repair_chance = 0.02
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.01
> AND speculative_retry = '99.0PERCENTILE';
>
> And cassandra stress create the next string to the field kvalue of type
> text:
>
> "P*d,xY\x03m\x1b\x10\x0b$\x04pt-G\x08\n`7\x1fs\x15kH\x02i1\x16jf%YM"
>
> what bothers me is that kvalue has control characters like \x03. do you
> guys know any way to avoid creating this kind of characters while using
> cassandra-stress?
>
>
>
> Thank you very much
>
> Jean Carlo
>
> "The best way to predict the future is to invent it" Alan Kay
>


There is no way to avoid the control characters (<32 and ==127), other than
modifying the source code, which is located in
tools/stress/src/org/apache/cassandra/stress/generate/values/Strings.java.

Changing this line:

chars[i++] = (char) (((v & 127) + 32) & 127);

with this:

chars[i++] = (char) (((v & 127) % 95) + 32);

should work but I could not avoid the expensive modulo operation. You can
rebuild cassandra-stress with ant stress-build.

I wonder if the original intention was to avoid control characters however,
given the +32 in the original line. For this reason I've copied this
message to the dev mailing list.


-- 


[image: datastax_logo.png] 

Stefania Alborghetti

Apache Cassandra Software Engineer

|+852 6114 9265| stefania.alborghe...@datastax.com

How to measure the write amplification of C*?

[Dikang Gu]

Hello there,

I'm wondering is there a good way to measure the write amplification of
Cassandra?

I'm thinking it could be calculated by (size of mutations written to the
node)/(number of bytes written to the disk).

Do we already have the metrics of "size of mutations written to the node"?
I did not find it in jmx metrics.

Thanks

-- 
Dikang