HDDS-12582. TypedTable support using different codec

[sumitagrawl]

What changes were proposed in this pull request?

can create TypedTable with custom key and value Codec, this will be used for customized codec where it may be required to avoid some field for performance.

Also added TABLE_NO_CACHE type caching, so that TypedTable becomes light-weight in creation and operation; and complexity / threads present PARTIAL_TABLE_CACHE class can be avoided.

Sample:
1.

// Use basic type for value codec like ByteString, and no conversion to protobuf

Table<String, ByteString> tbl3 = store.getTable(FILE_TABLE, String.class, ByteString.class,
          StringCodec.get(), ByteStringCodec.get(), TableCache.CacheType.NO_CACHE);

// Use only conversion to protobuf type, but not Ozone object deserialization

Table<String, KeyInfo> tbl4 = store.getTable(FILE_TABLE, String.class, KeyInfo.class,
          StringCodec.get(), Proto2Codec.get(KeyInfo.getDefaultInstance()), TableCache.CacheType.NO_CACHE);

// custom deserialization, with conversion of KeyInfo protobuf to OmKeyInfo not having Acl as part of getFromProtobufNoAcl()

Codec<OmKeyInfo> customCodec = new DelegatedCodec<>(
        Proto2Codec.get(KeyInfo.getDefaultInstance()),
        OmKeyInfo::getFromProtobufNoAcl,
        k -> k.getProtobuf(ignorePipeline, ClientVersion.CURRENT_VERSION),
        OmKeyInfo.class);

Table<String, OmKeyInfo> tbl2 = store.getTable(FILE_TABLE, String.class, OmKeyInfo.class,
          StringCodec.get(), customCodec, TableCache.CacheType.NO_CACHE);

Based on different codec and usecase, performance can be achieved,

-- Time in nano second for de
Time taken: 500751424541, cnt: 38790291, one task: 12909, msg:defaultTable
Time taken: 351664795250, cnt: 38790291, one task: 9065, msg:skip acl in omObject
Time taken: 102017933083, cnt: 38790291, one task: 2629, msg:byteString
Time taken: 296334535250, cnt: 38790291, one task: 7639, msg:only KeyInfo

for byte[] of KeyInfo proto in rocksdb:
byteString value type: takes 2.6k ns
OMKeyInfo value type: takes 13k ns
OMKeyInfo value type (skip acl): takes 9k ns

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-12582

How was this patch tested?

• no impact of existing flow, will be covered impact by existing test

[szetszwo]

@sumitagrawl , if there is a more efficient codec, we should replace the existing codec with it instead adding this custom codec feature.

[sumitagrawl]

@sumitagrawl , if there is a more efficient codec, we should replace the existing codec with it instead adding this custom codec feature.

Efficiency here is based on usecase, Suppose for iteration, if Value is not required to be deserialized, can have codec of not doing anything. But default always deserialize.

Further, can have different target of deserialization, like,

• Existing, byte[] --> KeyInfo --> OMKeyInfo
• Can have others, byte[] --> KeyInfo --> OMLightKeyInfo

[szetszwo]

@sumitagrawl , thanks for working on this! This approach "different tables could use a different codec" is better than "custom ValueCodec". Please update also the title.

[szetszwo]

Please don't change threadNamePrefix; see HDDS-12590.

[szetszwo]

@sumitagrawl , #8076 is merged now. Please resolve the conflicts. Thanks.

[szetszwo]

@sumitagrawl , thanks a lot for the update! Please see the comments inlined.

[sumitagrawl]

@szetszwo to resolve conflict, reapply the changes is done on master with threadNamePrefix; see HDDS-12590 as merged

[szetszwo]

+1 the change looks good.

Just a very minor inlined. I am fine if we keep the code as-is.

[szetszwo]

Add also mapExist() method. The is the Collections.emptyList() trick.

static <T> CacheResult<T> mapExist() {
  return CacheResult<T> MAY_EXIST;
}

[swamirishi]

LGTM Thanks for the patch @sumitagrawl