You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (JIRA)" <ji...@apache.org> on 2015/09/02 00:11:46 UTC
[jira] [Commented] (CASSANDRA-9673) Improve batchlog write path
[ https://issues.apache.org/jira/browse/CASSANDRA-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14726299#comment-14726299 ]
Aleksey Yeschenko commented on CASSANDRA-9673:
----------------------------------------------
I meant checking for table emptiness at the beginning of startup migration, and logging once if not empty. Logging on each conversion is obviously an overkill.
Also, the logic in conversion for != 1 uuids seems a bit weird. It will never be the case that we'll get a mutation on upgrade with a random uuid. Made it just use the counter unconditionally at all times.
There was a bug in {{SP::syncWriteToBatchlog}} that is as old as is batchlog itself. We are using CL.ONE unconditionally, even when we have two endpoints. And both legacy/modern writes should be sharing the same callback, so I switched back to using {{WriteResponseHandler}} for both.
Rebased against most recent cassandra-3.0 and force-pushed. I think I broke some replay tests. Could you have a look and fix, if necessary? And, if you are overall +1, I'll commit.
Thank you.
> 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)