cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Lerer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8603) Cut tombstone memory footprint in half for cql deletes
Date Wed, 15 Apr 2015 09:19:59 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495910#comment-14495910
] 

Benjamin Lerer commented on CASSANDRA-8603:
-------------------------------------------

When the {{RangeTombstone}} is initially created the 2 {{Composites}} effectively reuse, when
needed, the same {{ByteBuffer}}. The problem appear as soon as the {{RangeTombstone}} is serialized.
Each {{Composite}} is serialized separatly and by consequence each composite will be deserialized
as an independent object. 
If I am not mistaken the serialization will happen: 
# when the range tombstone is transfered to another node (e.g. from the coordinator to the
node where the data are stored)
# when the data are written to the SSTable

I did a kick test using {{Jamm}} on 2.1 and it seems that in your test scenario we could save
120 bytes per {{RangeTombstone}}.

[~slebresne] could you confirm my analysis?

Regarding the patch:
* I do not think that the patch modify the code at the right place. The fix should be applied
within the {{deserializeBody}} method instead of in the constructor.
* In the 2.1 version the code create 2 {{BoundedComposites}}. One for checking and one for
the assignment.

> Cut tombstone memory footprint in half for cql deletes
> ------------------------------------------------------
>
>                 Key: CASSANDRA-8603
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8603
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Dominic Letz
>            Assignee: Dominic Letz
>              Labels: tombstone
>         Attachments: cassandra-2.0.11-8603.txt, cassandra-2.1-8603.txt, cassandra-2.1-8603_v2.txt,
system.log
>
>
> As CQL does not yet support range deletes every delete from CQL results in a "Semi-RangeTombstone"
which actually has the same start and end values - but until today they are copies. Effectively
doubling the required heap memory to store the RangeTombstone.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message