[
https://issues.apache.org/jira/browse/CASSANDRA-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905891#comment-13905891
]
Aleksey Yeschenko commented on CASSANDRA-6134:
----------------------------------------------
For the record, several of those improvements have already made it into C*. If
we don't do the partitioning, then only two are left to implement:
1. Don't do full scans, but limit the range to (nothing could be written
earlier than that, batches not ready to replay yet) - the uuids are timeuuids
there now, so it's a simple change, on my todo list
2.Replay several batches simultaneously, async - this is slightly more work,
but only slightly
Stuff that made it recently, thanks to rbranson: CASSANDRA-6569,
CASSANDRA-6550, CASSANDRA-6488, CASSANDRA-6481
Stuff that's still waiting (aside from 1. and 2.) : CASSANDRA-6551
> More efficient BatchlogManager
> ------------------------------
>
> Key: CASSANDRA-6134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6134
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Oleg Anastasyev
> Assignee: Oleg Anastasyev
> Priority: Minor
> Attachments: BatchlogManager.txt
>
>
> As we discussed earlier in CASSANDRA-6079 this is the new BatchManager.
> It stores batch records in
> {code}
> CREATE TABLE batchlog (
> id_partition int,
> id timeuuid,
> data blob,
> PRIMARY KEY (id_partition, id)
> ) WITH COMPACT STORAGE AND
> CLUSTERING ORDER BY (id DESC)
> {code}
> where id_partition is minute-since-epoch of id uuid.
> So when it scans for batches to replay ot scans within a single partition for
> a slice of ids since last processed date till now minus write timeout.
> So no full batchlog CF scan and lot of randrom reads are made on normal
> cycle.
> Other improvements:
> 1. It runs every 1/2 of write timeout and replays all batches written within
> 0.9 * write timeout from now. This way we ensure, that batched updates will
> be replayed to th moment client times out from coordinator.
> 2. It submits all mutations from single batch in parallel (Like StorageProxy
> do). Old implementation played them one-by-one, so client can see half
> applied batches in CF for a long time (depending on size of batch).
> 3. It fixes a subtle racing bug with incorrect hint ttl calculation
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
