[
https://issues.apache.org/jira/browse/KUDU-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854190#comment-16854190
]
ZhangYao commented on KUDU-749:
-------------------------------
Hi, Todd:). In order to accelerate the time spending on
DeltaMemStore::CheckRowDeleted, I wonder why we don't use the same sturct as
MemRowSet. MemRowSet use row_key + mutationlist as B+ tree leftnode but
DeltaMemStore use ((row_idx + timestamp) + changelist) as leftnode.
So if a lot of updates access DMS the B+ tree will be very large, and the
traverse in CheckRowDeleted will cost a lot of time. If we use the same
structure as MRS, we can use mutation head and mutation tail to record the
updates of the same key. At the same time, the struct of redo file and undo
file can keep intact. Then it will not only accelerate the CheckRowDeleted but
also the updates on DMS. Do you have any advice? If you agree with this I can
do POC at first to get the performance.
> Improve performance for zipfian update
> --------------------------------------
>
> Key: KUDU-749
> URL: https://issues.apache.org/jira/browse/KUDU-749
> Project: Kudu
> Issue Type: Improvement
> Components: perf, tablet
> Affects Versions: Private Beta
> Reporter: Todd Lipcon
> Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> A zipfian 50/50 update/read workload on YCSB gets slower and slower until
> it's pretty intolerable (random reads taking 100+ms of CPU). It seems like
> all the CPU is spent in DMSIterator::PrepareBatch. We're probably doing
> something dumb here - let's look for some low hanging fruit to fix this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
