[
https://issues.apache.org/jira/browse/HDFS-12506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177865#comment-16177865
]
Weiwei Yang commented on HDFS-12506:
------------------------------------
Found one more issue in this patch, it was not enough to fix this issue. I have
re-populated 3 million keys with the patch and listBucket is still slow. The
reason was because {{MetadataStore#getRangeKVs}} doesn't stop looking for
buckets even the keys with the bucket prefix are all iterated. I just uploaded
v6 patch to fix this.
v6 patch added another API in {{MetadataStore}}, see java doc
{code}
/**
* This method is very similar with
* {@link #getRangeKVs(byte[], int, MetadataKeyFilter...)}, the only
* different is this method is supposed to return a sequential range
* of elements based on the filters. While iterating the elements,
* if it met any entry that cannot pass the filter, the iterator will stop
* from this point without looking for next match. If no filter is given,
* this method behaves just like
* {@link #getRangeKVs(byte[], int, MetadataKeyFilter...)}.
*
* @param startKey
* @param count
* @param filters
* @return
* @throws IOException
* @throws IllegalArgumentException
*/
List<Map.Entry<byte[], byte[]>> getSequentialRangeKVs(byte[] startKey,
int count, MetadataKeyFilter... filters)
throws IOException, IllegalArgumentException;
{code}
Since buckets are sorted, it should be retrieved by this
{{getSequentialRangeKVs}} to avoid unnecessary look ups to improve the
performance. Tested on my cluster, with latest v6 patch, time consumed for the
listBucket call is around *950ms*.
Please help to review. Thanks!
> Ozone: ListBucket is too slow
> -----------------------------
>
> Key: HDFS-12506
> URL: https://issues.apache.org/jira/browse/HDFS-12506
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ozone
> Reporter: Weiwei Yang
> Assignee: Weiwei Yang
> Priority: Blocker
> Labels: ozoneMerge, performance
> Attachments: HDFS-12506-HDFS-7240.001.patch,
> HDFS-12506-HDFS-7240.002.patch, HDFS-12506-HDFS-7240.003.patch,
> HDFS-12506-HDFS-7240.004.patch, HDFS-12506-HDFS-7240.005.patch,
> HDFS-12506-HDFS-7240.006.patch
>
>
> Generated 3 million keys in ozone, and run {{listBucket}} command to get a
> list of buckets under a volume,
> {code}
> bin/hdfs oz -listBucket http://15oz1.fyre.ibm.com:9864/vol-0-15143 -user wwei
> {code}
> this call spent over *15 seconds* to finish. The problem was caused by the
> inflexible structure of KSM DB. Right now {{ksm.db}} stores keys like
> following
> {code}
> /v1/b1
> /v1/b1/k1
> /v1/b1/k2
> /v1/b1/k3
> /v1/b2
> /v1/b2/k1
> /v1/b2/k2
> /v1/b2/k3
> /v1/b3
> /v1/b4
> {code}
> keys are sorted in nature order so when we do list buckets under a volume e.g
> /v1, we need to seek to /v1 point and start to iterate and filter keys, this
> ends up with scanning all keys under volume /v1. The problem with this design
> is we don't have an efficient approach to locate all buckets without scanning
> the keys.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
