cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9673) Improve batchlog write path
Date Tue, 25 Aug 2015 06:16:46 GMT


Stefania commented on CASSANDRA-9673:

Here are the CI results (build #5 still pending).

Failing utests:

Build #4
* {{org.apache.cassandra.db.RecoveryManagerTest.testRecoverPITUnordered}} - timed out also
on 3.0 (build #105)

Build #3:
* {{}}
- timed out due to a compaction, seems unrelated

* {{org.apache.cassandra.cql3.MaterializedViewLongTest.testConflictResolution}} - this does
worry me, sometimes it passes and sometimes it fails, it seems to always pass on 3.0. However
it doesn't go through {{SP.mutateMV()}} so I don't see how we could have broken it, perhaps
because we've removed  the dedicated stage? Sample failure [here|].

The failing dtests seem inline with 3.0. Note that I have a fix for the two failing tests
in [here|].

I also added a function ({{nanoSince()}}) to distinguish legacy mutations with clashing timestamps
but it's very slow - do you think we need this?

    UUID newId = id;
    if (id.version() != 1 || timestamp != UUIDGen.unixTimestamp(id))
        newId = UUIDGen.getTimeUUID(timestamp, nanoSince(id, timestamp));

As far as I understand only 1.2 mutations would have non-time UUIDs, {{id.version() != 1}},
however strictly speaking time uuids would not necessarily match {{written_at}}, which is
the current time in micros divided 1000, whereas the uuid would have been created a little
earlier, so if we crossed the millisecond boundary we would have {{timestamp != UUIDGen.unixTimestamp(id)}}.
The code I am talking about is in {{LegacyBatchMigrator.apply}} and it is called when applying
legacy mutations. WDYT?

> Improve batchlog write path
> ---------------------------
>                 Key: CASSANDRA-9673
>                 URL:
>             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,
> 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
> 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

View raw message