HDDS-11476. Implement lesser/greater operation for --filter option of ldb scan command

[Tejaskriya]

What changes were proposed in this pull request?

A --filter option was added recently which selects records that have a given value for a particular field will make debugging easier. (as a part of #7167)
Adding support for lesser/greater than operations will be useful while debugging
For example, if a value has many fields like [name, location->[address, DN, IP], version, lastUpdateTime],

• using the option "--filter={version:equals:1}" will display records that have the value 1 for version.
• using the option "–filter={lastUpdateTime:greater:1000}" will display the record with lastUpdateTime>1000
• using the option "–filter={lastUpdateTime:lesser:1000}" will display the record with lastUpdateTime<1000

A list of fields along with the value it should be compared to is given to the command, and only those records passing the condition it will be shown.

eg.) ozone debug ldb --db=/data/metadata/om.db scan --cf=volumeTable --filter="usedNamespace:greater:2,adminName:equals:impala"

In this PR, apart from adding the support for these 2 operations, some code refactoring is also done.

What is the link to the Apache JIRA

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

How was this patch tested?

Added tests in TestLDBCli
Tested locally with a local DB:

$ ozone debug ldb --db=/Users/tejaskriya.madhan/ZDump/bigDB/omMBdb/om.db scan --cf=keyTable  -l=3  --filter=dataSize:greater:2 --fields="objectID,updateID,volumeName,bucketName,keyName,dataSize"

{ "/55406660-10tb/ozone-legacy-ec-1st-bucket-55406660/10T-1-terasort-input/part-m-00000": {
  "updateID" : 2363922,
  "bucketName" : "ozone-legacy-ec-1st-bucket-55406660",
  "volumeName" : "55406660-10tb",
  "keyName" : "10T-1-terasort-input/part-m-00000",
  "dataSize" : 108695652200,
  "objectID" : -9223372036253037824
}
, "/55406660-10tb/ozone-legacy-ec-1st-bucket-55406660/10T-1-terasort-input/part-m-00001": {
  "updateID" : 2363776,
  "bucketName" : "ozone-legacy-ec-1st-bucket-55406660",
  "volumeName" : "55406660-10tb",
  "keyName" : "10T-1-terasort-input/part-m-00001",
  "dataSize" : 108695652200,
  "objectID" : -9223372036253027072
}
, "/55406660-10tb/ozone-legacy-ec-1st-bucket-55406660/10T-1-terasort-input/part-m-00002": {
  "updateID" : 2363418,
  "bucketName" : "ozone-legacy-ec-1st-bucket-55406660",
  "volumeName" : "55406660-10tb",
  "keyName" : "10T-1-terasort-input/part-m-00002",
  "dataSize" : 108695652200,
  "objectID" : -9223372036253021440
}
 }


$ ozone debug ldb --db=/Users/tejaskriya.madhan/ZDump/bigDB/omMBdb/om.db scan --cf=keyTable  -l=3  --filter=dataSize:lesser:2 --fields="objectID,updateID,volumeName,bucketName,keyName,dataSize"

{ "/55406660-10tb/ozone-legacy-ec-1st-bucket-55406660/10T-1-terasort-input/": {
  "updateID" : 2350475,
  "bucketName" : "ozone-legacy-ec-1st-bucket-55406660",
  "volumeName" : "55406660-10tb",
  "keyName" : "10T-1-terasort-input/",
  "dataSize" : 0,
  "objectID" : -9223372036253054206
}
, "/55406660-10tb/ozone-legacy-ec-1st-bucket-55406660/10T-1-terasort-input/_SUCCESS": {
  "updateID" : 2364036,
  "bucketName" : "ozone-legacy-ec-1st-bucket-55406660",
  "volumeName" : "55406660-10tb",
  "keyName" : "10T-1-terasort-input/_SUCCESS",
  "dataSize" : 0,
  "objectID" : -9223372036249583104
}
, "/55406660-10tb/ozone-legacy-ec-1st-bucket-55406660/10T-1-terasort-output/": {
  "updateID" : 2365898,
  "bucketName" : "ozone-legacy-ec-1st-bucket-55406660",
  "volumeName" : "55406660-10tb",
  "keyName" : "10T-1-terasort-output/",
  "dataSize" : 0,
  "objectID" : -9223372036249105919
}
 }


$ ozone debug ldb --db=/Users/tejaskriya.madhan/ZDump/bigDB/omMBdb/om.db scan --cf=keyTable  -l=3  --filter=keyName:lesser:2 --fields="objectID,updateID,volumeName,bucketName,keyName,dataSize"

LESSER or GREATER operation can be performed only on numeric values.
ERROR: field: keyName=(LESSER,2,null), ex: java.io.IOException: Invalid filter passed
{  }
Exit code is non-zero. Check the error message above

[ayushtkn]

Why are removing MAX & MIN operators? that too in the scope of introducing 2 new operators?

[Tejaskriya]

In order to implement MAX and MIN, some code refactoring would be required. We would not be able to do batch processing as max/min cannot be calculated in batches. This could severely affect the performance. So having lesser/greater than operators could perform as a substitute for min/max.

[sumitagrawl]

Since MIN/MAX operation do not match doing parallel processing of records in batches and generating output, so dropping this. But having alternative with < , > can be tuned to provide similar functionality of matching.

[Tejaskriya]

@ayushtkn thank you for the review. I have addressed the comments. Could you please review the updated patch?
@sumitagrawl could you please review my patch when you have some time?

[sumitagrawl]

@Tejaskriya LGTM

[sumitagrawl]

Since MIN/MAX operation do not match doing parallel processing of records in batches and generating output, so dropping this. But having alternative with < , > can be tuned to provide similar functionality of matching.