cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Carrino (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6764) Using Batch commitlog_sync is slow and doesn't actually batch writes
Date Tue, 25 Feb 2014 03:27:19 GMT


John Carrino commented on CASSANDRA-6764:

All is not lost as we will use this in production as a patch on 1.2.

I disagree using smart batching is an anti pattern.

I think going 4000 threads wide just to achieve batched commits is
excessive especially considering what a common workflow it is. Do people
run with concurrent writes in the thousands?

It's good to hear this was reworked in 2.1. I hope that batching is in

> Using Batch commitlog_sync is slow and doesn't actually batch writes
> --------------------------------------------------------------------
>                 Key: CASSANDRA-6764
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: John Carrino
>             Fix For: 1.2.16
>         Attachments: cassandra_6764_v2.patch
> The assumption behind batch commit mode is that the client does it's own batching and
wants to wait until the write is durable before returning.  The problem is that the queue
that cassandra uses under the covers only allows for a single ROW (RowMutation) per thread
(concurrent_writes).  This means that commitlog_sync_batch_window_in_ms should really be called
sleep_between each_concurrent_writes_rows_in_ms.
> I assume the reason this slipped by for so long is that no one uses batch mode, probably
because people say "it's slow".  We need durability so this isn't an option.
> However it doesn't need to be this slow.
> Also, if you write a row that is larger than the commit log size it silently (warn) fails
to put it in the commit log.  This is not ideal for batch mode.

This message was sent by Atlassian JIRA

View raw message