Dheeraj Khanna created OAK-4492:
-----------------------------------
Summary: FileDataStore with configurable path based structure
Key: OAK-4492
URL: https://issues.apache.org/jira/browse/OAK-4492
Project: Jackrabbit Oak
Issue Type: New Feature
Components: blob
Environment: external File Data Store
Reporter: Dheeraj Khanna
Configuration for path based structure in the FDS so that we can have more
granular control over FDS growth and cleanup operations. We can have a
datastore root under which level 1 can be configurable on basis of number of
paths needed (index, application1, application2 etc) and rest of the management
of blobs under each asset can be done in the way they are done today.
Something like:
datastoreroot
|
|___path1 (indexes)
| |__aa
| | |__a1
| | |__a2
| |
| |__bb
| |__b1
| |__b2
|
|___path2 (app1)
| |__aa
| | |__a1
| | |__a2
| |
| |__bb
| |__b1
| |__b2
|___path2 (archived blobs)
| |__aa
| | |__a1
| | |__a2
| |
| |__bb
| |__b1
| |__b2
|
For example:
1. datastoreroot/path1 (indexes)- folder for index binaries - so that DSGC for
previous lucene index binaries can be contained in a separate area and can be
run independent of application blob DSGC.
2. datastoreroot/path2 (app1)- in case there are multiple applications on the
same instance. This could help with backups etc.
3. datastoreroot/path3 - folder for archival use case - Eg: In case of archival
of older blobs the binaries can be moved to this location. Again helps with
bringing efficiency to the 'current' data set as only current data set needs to
be backed up on regular basis. Use case also requires to be able to restore a
archived blob into current data set, if required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
