[
https://issues.apache.org/jira/browse/IGNITE-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814850#comment-16814850
]
Semen Boikov commented on IGNITE-11722:
---------------------------------------
Batch operations on BPlusTree were implemented by sergi.vladykin
(invokeAll/putAll), for batch updates on BPlusTree it is necessary to sort keys
in advance. To integrate it in cache updates it is necessary first group keys
by partition, and then prepare sorted batches for each partition. Initial
integration for ATOMIC cache batch operations is implemented in branch
ignite-invokeAll:
* changed method GridCacheMapEntry.innerUpdate, now tree closure is passed as
parameter, it makes code little bit more clear
* updates are sorted by partition/key on client
(GridNearAtomicAbstractUpdateRequest.sort), so there is no need to group/sort
updates on serves. As a side effect this also resolves issue with potential
deadlocks in ATOMIC cache when user does not sort keys.
* on primary nodes all entries are already locked before BPlusTree updates
and it is safe to call BPlusTree.invokeAll
* keys are added in backups update requests in sorted orders, so it is not
necessary group/sort updates on backups. But on backups it is necessary to lock
all entries before updating BPlusTree and cache data store, this was
implemented.
With these changes we got strange results in putAll benchmark with various
batch sizes (IgnitePutAllBenchmark, 4 servers / 8 clients, 64 threads). There
was performance boost only with batchSize=10, with others batch sizes there was
performance drop. Need find out reason of performance drop, possible reasons:
* added overhead for keys sorting
* added overhead to prepare batches for BPlusTree.invokeAll, now for each
batch collection of closures is created. This is necessary since we need update
result for each key and currently result is stored in closure itself
* batches are created per-partition, with default partition number and small
servers number batches can be too small, so фввув overhead is bigger than
BPlusTree.invokeAll benefit
* maybe IgnitePutAllBenchmark is not really fair, it does not generate random
keys for each iteration, but pre-generates 256 random maps in advance
(all changes in branch ignite-invokeAll)
> Batch BPlustTree updates for cache batch operations
> ---------------------------------------------------
>
> Key: IGNITE-11722
> URL: https://issues.apache.org/jira/browse/IGNITE-11722
> Project: Ignite
> Issue Type: Improvement
> Components: cache
> Reporter: Semen Boikov
> Priority: Major
> Fix For: 2.8
>
>
> Now cache batch operations (putAll, invokeAll, removeAll) update BPlustTree
> entries one by one. It makes sense to support batch updates in BPlustTree
> and use it for cache batch operations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
