hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yiqun Lin (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HDFS-12506) Ozone: ListBucket is too slow
Date Thu, 21 Sep 2017 09:01:01 GMT

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

Yiqun Lin edited comment on HDFS-12506 at 9/21/17 9:00 AM:
-----------------------------------------------------------

Thanks for working on this improvement, [~cheersyang]!
One comment for your patch:
{noformat}
   public boolean isVolumeEmpty(String volume) throws IOException {
-    String dbVolumeRootName = OzoneConsts.KSM_VOLUME_PREFIX + volume;
+    String dbVolumeRootName = OzoneConsts.KSM_VOLUME_PREFIX + volume
+        + OzoneConsts.KSM_BUCKET_PREFIX;
     byte[] dbVolumeRootKey = DFSUtil.string2Bytes(dbVolumeRootName);
-    // Seek to the root of the volume and look for the next key
-    ImmutablePair<byte[], byte[]> volumeRoot =
-        store.peekAround(1, dbVolumeRootKey);
-    if (volumeRoot != null) {
-      String firstBucketKey = DFSUtil.bytes2String(volumeRoot.getKey());
-      return !firstBucketKey.startsWith(dbVolumeRootName
-          + OzoneConsts.KSM_BUCKET_PREFIX);
+    ImmutablePair<byte[], byte[]>
+        firstBucket = store.peekAround(0, dbVolumeRootKey);
+    if (firstBucket != null) {
+      String firstBucketKey = DFSUtil.bytes2String(firstBucket.getKey());
+      return !firstBucketKey.startsWith(dbVolumeRootName);
     }
{noformat}
Why here is {{store.peekAround(0, dbVolumeRootKey);}}? Actually we should find the right key
of dbVolumeRootKey(/#vol/#) and use {{store.peekAround(1, dbVolumeRootKey)}}, right?
In addition, the following failed UT seem related.
 org.apache.hadoop.ozone.ksm.TestKeySpaceManager.testDeleteNonEmptyBucket
 org.apache.hadoop.ozone.web.client.TestKeys.testDeleteKey

bq. we will need to avoid user from adding volumes with name like "#volumeName", bucket with
name like "#bucketName". That will cause problems...
I'm +1 on this. The volume/bucket name with "/#" prefix str will cause problems, because keys
are stored as they are stored now. There is a chance the we will get incorrect volumes/buckets
in list* function.



was (Author: linyiqun):
Thanks for working on this improvement, [~cheersyang]!
One comment for your patch:
{noformat}
   public boolean isVolumeEmpty(String volume) throws IOException {
-    String dbVolumeRootName = OzoneConsts.KSM_VOLUME_PREFIX + volume;
+    String dbVolumeRootName = OzoneConsts.KSM_VOLUME_PREFIX + volume
+        + OzoneConsts.KSM_BUCKET_PREFIX;
     byte[] dbVolumeRootKey = DFSUtil.string2Bytes(dbVolumeRootName);
-    // Seek to the root of the volume and look for the next key
-    ImmutablePair<byte[], byte[]> volumeRoot =
-        store.peekAround(1, dbVolumeRootKey);
-    if (volumeRoot != null) {
-      String firstBucketKey = DFSUtil.bytes2String(volumeRoot.getKey());
-      return !firstBucketKey.startsWith(dbVolumeRootName
-          + OzoneConsts.KSM_BUCKET_PREFIX);
+    ImmutablePair<byte[], byte[]>
+        firstBucket = store.peekAround(0, dbVolumeRootKey);
+    if (firstBucket != null) {
+      String firstBucketKey = DFSUtil.bytes2String(firstBucket.getKey());
+      return !firstBucketKey.startsWith(dbVolumeRootName);
     }
{noformat}
Why here is {{store.peekAround(0, dbVolumeRootKey);}}? Actually we should find the right key
of dbVolumeRootKey(/#vol/#) and use {{store.peekAround(1, dbVolumeRootKey)}}, right?
In addition, the following failed UT seem related.
 org.apache.hadoop.ozone.ksm.TestKeySpaceManager.testDeleteNonEmptyBucket
 org.apache.hadoop.ozone.web.client.TestKeys.testDeleteKey

> 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
>
>
> 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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org


Mime
View raw message