guihecheng commented on code in PR #3420:
URL: https://github.com/apache/ozone/pull/3420#discussion_r876736262


##########
hadoop-hdds/container-service/src/main/java/org/apache/hadoop/ozone/container/metadata/DatanodeSchemaThreeDBDefinition.java:
##########
@@ -137,11 +143,16 @@ public DBColumnFamilyDefinition<String, Long> 
getMetadataColumnFamily() {
 
   public static String getContainerKeyPrefix(long containerID) {
     // NOTE: Rocksdb normally needs a fixed length prefix.
-    return FixedLengthStringUtils.bytes2String(Longs.toByteArray(containerID));
+    return FixedLengthStringUtils.bytes2String(Longs.toByteArray(containerID))

Review Comment:
   Ah, got it. I think if we follow the old way, the separator will be a part 
of the actual key, for example there is a blockKey, then this separator goes to 
the head of a blockKey(which is a localID), then things got messed up.
   With the new approach, the separator is part of the prefix, even we got 1 
byte more to compare, it is fine.
   
   I think the ideal effect in my mind is that, the separator should below to 
neither the prefix nor the actual key.
   Then, even we got the separator changed, we are still likely to parse the 
keys, for example:
   change from '|' -> '#', if we parse the key like:
   1. seek with 8bytes prefix
   2. skip 1 byte for separator
   3. parse the left bytes for blockKey.
   
   Then we could make the separator isolated and independent, of course if you 
have a separator with different length, then it will not be possible.
   
   So let's just go with this approach and see if we could do better in the 
future.
   
   
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to