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

Jonathan Ellis commented on CASSANDRA-6764:
-------------------------------------------

I hate to be That Guy after you've put this much effort into a patch, but I 
have some concerns.  First and most obviously,

# 1.2 and 2.0 are for bug fixes only at this point, not optimizations, and 
especially not optimizations touching something as crucial to data safety as 
CommitLog.  Not at all comfortable slipping this into a minor update and 
crossing my fingers.
# CommitLog has been modified substantially for 2.1 (CASSANDRA-3578)

Now, it could still make sense to aggregate rows from the same (request) batch 
into the same (fsync) batch, however, 
- using batching for unrelated rows (i.e. rows that don't need to be updated 
atomically) is a performance antipattern, so optimizing for that seems wrong, 
and
- I'm skeptical that you can't achieve your goals without the extra complexity 
by simply increasing {{concurrent_writes}} 


> 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)

Reply via email to