[
https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911190#comment-13911190
]
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.
http://mechanical-sympathy.blogspot.com/2011/10/smart-batching.html?m=1
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
there.
> Using Batch commitlog_sync is slow and doesn't actually batch writes
> --------------------------------------------------------------------
>
> Key: CASSANDRA-6764
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6764
> 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
(v6.1.5#6160)
