[
https://issues.apache.org/jira/browse/HBASE-26969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17536589#comment-17536589
]
Szabolcs Bukros commented on HBASE-26969:
-----------------------------------------
[~zhangduo] thank you for taking time and reading this!
As far as I understand when a storeFile has data that is stored in a mob file
then that storeFile's metadata will have a reference to these mob files. So
when a scan request tries to read the data it knows which mob file to check.
This is the only tracking we have.
{code:java}
storeFile.getMetadataValue(HStoreFile.MOB_FILE_REFS); {code}
For cleanup the chore have to know which mob files are currently actively
referenced. To get this lit, the chore check's the metadata of every single
storeFile hbase have in a mob enabled CF, and collects the references from
them. It just iterates through the /data folder table by table.
> Eliminate MOB renames when SFT is enabled
> -----------------------------------------
>
> Key: HBASE-26969
> URL: https://issues.apache.org/jira/browse/HBASE-26969
> Project: HBase
> Issue Type: Sub-task
> Components: mob
> Affects Versions: 2.5.0, 3.0.0-alpha-3
> Reporter: Szabolcs Bukros
> Assignee: Szabolcs Bukros
> Priority: Major
> Fix For: 2.6.0, 3.0.0-alpha-3
>
>
> MOB file compaction and flush still relies on renames even when SFT is
> enabled.
> My proposed changes are:
> * when requireWritingToTmpDirFirst is false during mob flush/compact instead
> of using the temp writer we should create a different writer using a
> {color:#000000}StoreFileWriterCreationTracker that writes directly to the mob
> store folder{color}
> * {color:#000000}these StoreFileWriterCreationTracker should be stored in
> the MobStore. This would requires us to extend MobStore with a createWriter
> and a finalizeWriter method to handle this{color}
> * {color:#000000}refactor {color}MobFileCleanerChore to run on the RS
> instead on Master to allow access to the
> {color:#000000}StoreFileWriterCreationTracker{color}s to make sure the
> currently written files are not cleaned up
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
