cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9673) Improve batchlog write path
Date Sun, 23 Aug 2015 15:08:46 GMT

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

Aleksey Yeschenko commented on CASSANDRA-9673:
----------------------------------------------

Rebased against most recent trunk and made some minor changes, here: https://github.com/iamaleksey/cassandra/tree/9673-3.0.
Didn't go very far. Removed {{BATCHLOG_MUTATION}} Stage that Carl and I think is no longer
needed (but we'll bring it back if that's a mistake), and did some renames and minor cleanup
of unused methods.

Good work. There is only one real issue so far, with that fixed, we could commit as is, but
I have a bunch of nits that'd be nice to address: we are not properly handling old-format
batchlog mutations sent live from 2.1/2.2 nodes, during live upgrades.

You need to modify {{MutationVerbHandler}} and add special treatment to mutations for the
old batchlog table.

Nits:
1. I would prefer {{BatchStoreMessage}} and {{BatchRemoveMessage}} to be dumb and only be
concerned about serialization/deserialization. This means no {{getMutation()}} in either.
For {{BatchRemoveMessage}}, the actual logic should be in {{BatchRemoveVerbHandler}}.
2. I would like to separate {{Batch}} and {{BatchStoreMessage}} and put actual saving to batchlog
logic into a new {{Batch}} class - to be used both for local (MV) writes and proper BL remote
writes.
3. If moved to {{Batch}} (and if not, too), I would prefer the mutation collections in them
to only be set in the constructor.
4. Somehow we are calling {{LegacyBatchMigrator.convertBatchEntries()}} on every replay, reverting
Branimir's changes, instead of explicitly only doing it once, upon first replay. I'm presuming
that this is done as a workaround for the live upgrade issue. I would prefer that we moved
the migration to {{CassandraDaemon.setup()}}, where legacy schema and hints migration already
get called.

> Improve batchlog write path
> ---------------------------
>
>                 Key: CASSANDRA-9673
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9673
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Aleksey Yeschenko
>            Assignee: Stefania
>              Labels: performance
>             Fix For: 3.0 beta 2
>
>         Attachments: 9673_001.tar.gz, 9673_004.tar.gz, gc_times_first_node_patched_004.png,
gc_times_first_node_trunk_004.png
>
>
> Currently we allocate an on-heap {{ByteBuffer}} to serialize the batched mutations into,
before sending it to a distant node, generating unnecessary garbage (potentially a lot of
it).
> With materialized views using the batchlog, it would be nice to optimise the write path:
> - introduce a new verb ({{Batch}})
> - introduce a new message ({{BatchMessage}}) that would encapsulate the mutations, expiration,
and creation time (similar to {{HintMessage}} in CASSANDRA-6230)
> - have MS serialize it directly instead of relying on an intermediate buffer
> To avoid merely shifting the temp buffer to the receiving side(s) we should change the
structure of the batchlog table to use a list or a map of individual mutations.



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

Mime
View raw message