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 n
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)
>
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 J
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
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
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
