[
https://issues.apache.org/jira/browse/HDFS-11918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039668#comment-16039668
]
Anu Engineer commented on HDFS-11918:
-------------------------------------
[~cheersyang] At high level it seems like an interesting idea. However, the
Rest API needs to parse these keys as they come in and route the calls
appropriately. Do I am not sure if we can avoid the heavy parsing part. Perhaps
in the database part this has some advantage. Now that we have KSM almost build
out, if we you can quickly review some of the places where the parsing is used
and compare and contrast this approach, it will be helpful in deciding how much
cleaner this approach is.
>From reading this patch, it looks like a clean approach, but plain strings
>also have some advantages, including not needing a tool understand what the
>value of a key is.
> Ozone: Encapsulate KSM metadata key into protobuf messages for better
> (de)serialization
> ---------------------------------------------------------------------------------------
>
> Key: HDFS-11918
> URL: https://issues.apache.org/jira/browse/HDFS-11918
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ozone
> Reporter: Weiwei Yang
> Assignee: Weiwei Yang
> Priority: Critical
> Attachments: HDFS-11918-HDFS-7240.001.patch
>
>
> There are multiple type of keys stored in KSM database
> # Volume Key
> # Bucket Key
> # Object Key
> # User Key
> Currently they are represented as plain string with some conventions, such as
> # /volume
> # /volume/bucket
> # /volume/bucket/key
> # $user
> this approach makes it so difficult to parse volume/bucket/keys from KSM
> database. Propose to encapsulate these types of keys into protobuf messages,
> and take advantage of protobuf to serialize(deserialize) classes to byte
> arrays (and vice versa).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
