[compat][server][controller][admin-tool] Add store-level BlobDB configuration with cluster-level fallback #2444
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem Statement
Currently, the RocksDB BlobDB feature can only be configured at the cluster level via
RocksDBServerConfig.isBlobFilesEnabled(). This means all stores on a host must use the same BlobDB setting, which limits flexibility when different stores have different requirements for large value storage optimization.There is no way to:
Solution
This PR adds store-level (version-level) BlobDB configuration that allows fine-grained control over BlobDB enablement per store, with automatic fallback to cluster-level configuration when not specified.
Configuration Hierarchy
ENABLEDorDISABLEDNOT_SPECIFIEDImplementation Details
blobDbEnabledfield to Version and Store interfaces usingActivationStateenum (NOT_SPECIFIED,ENABLED,DISABLED)StoragePartitionConfigto carry the BlobDB setting from version configRocksDBStoragePartition.getStoreOptions()to check store-level config with fallback to cluster-levelUpdateStoreQueryParams--blob-db-enabledfor theupdate-storecommandStoreMetaValuev40 andAdminOperationv95Code changes
blob_db_enabledwith default valueNOT_SPECIFIED(falls back to cluster-level config).Concurrency-Specific Checks
Both reviewer and PR author to verify
synchronized,RWLock) are used where needed. (N/A - no new synchronization needed)ConcurrentHashMap,CopyOnWriteArrayList). (N/A - no new collections)How was this PR tested?
TestStoreInfo.testBlobDbEnabledConfig()- Tests getter/setter for BlobDB enabled flagRocksDBStoragePartitionTest.testStoreLevelBlobDbConfigOverridesClusterLevel()- Tests all three scenarios (ENABLED, DISABLED, NOT_SPECIFIED with fallback)ReadOnlyStoreTest.testCloneStoreProperties()- Added verification for blobDbEnabled field cloningNOT_SPECIFIEDpreserves existing behavior by falling back to cluster-level config.Does this PR introduce any user-facing or breaking changes?
The default value
NOT_SPECIFIEDensures existing stores continue to use the cluster-level BlobDB configuration, maintaining backward compatibility. Users can opt-in to store-level control via the new admin-tool argument.Files Changed (22 files)
Core Implementation
internal/venice-common/src/main/java/com/linkedin/venice/meta/Version.java- Added interface methodsinternal/venice-common/src/main/java/com/linkedin/venice/meta/VersionImpl.java- Implemented getter/setterinternal/venice-common/src/main/java/com/linkedin/venice/meta/Store.java- Added interface methodsinternal/venice-common/src/main/java/com/linkedin/venice/meta/ZKStore.java- Implemented getter/setterinternal/venice-common/src/main/java/com/linkedin/venice/meta/AbstractStore.java- Added to setupNewVersionWithStoreLevelConfiginternal/venice-common/src/main/java/com/linkedin/venice/meta/ReadOnlyStore.java- Added delegationinternal/venice-common/src/main/java/com/linkedin/venice/meta/SystemStore.java- Added delegationinternal/venice-common/src/main/java/com/linkedin/venice/meta/StoreInfo.java- Added field and getter/setterStorage Layer
clients/da-vinci-client/src/main/java/com/linkedin/davinci/config/StoragePartitionConfig.java- Added blobDbEnabled fieldclients/da-vinci-client/src/main/java/com/linkedin/davinci/store/rocksdb/RocksDBStoragePartition.java- Updated getStoreOptions() with fallback logicclients/da-vinci-client/src/main/java/com/linkedin/davinci/kafka/consumer/StoreIngestionTask.java- Set blobDbEnabled from version configController
internal/venice-common/src/main/java/com/linkedin/venice/controllerapi/ControllerApiConstants.java- Added constantinternal/venice-common/src/main/java/com/linkedin/venice/controllerapi/UpdateStoreQueryParams.java- Added getter/setterservices/venice-controller/src/main/java/com/linkedin/venice/controller/VeniceHelixAdmin.java- Added parameter handlingservices/venice-controller/src/main/java/com/linkedin/venice/controller/VeniceParentHelixAdmin.java- Added UpdateStore handlingservices/venice-controller/src/main/java/com/linkedin/venice/controller/kafka/consumer/AdminExecutionTask.java- Added message deserializationAdmin Tool
clients/venice-admin-tool/src/main/java/com/linkedin/venice/Arg.java- Added CLI argumentclients/venice-admin-tool/src/main/java/com/linkedin/venice/AdminTool.java- Added parameter parsingSchema & Build
build.gradle- Updated to use StoreMetaValue v40 and AdminOperation v95Tests
internal/venice-common/src/test/java/com/linkedin/venice/meta/TestStoreInfo.java- Added testBlobDbEnabledConfiginternal/venice-common/src/test/java/com/linkedin/venice/meta/ReadOnlyStoreTest.java- Added blobDbEnabled verificationclients/da-vinci-client/src/test/java/com/linkedin/davinci/store/rocksdb/RocksDBStoragePartitionTest.java- Added comprehensive test