Package org.apache.hadoop.hbase.regionserver

Class StoreEngine<SF extends StoreFlusher,CP extends CompactionPolicy,C extends Compactor<?>,SFM extends StoreFileManager>

java.lang.Object
org.apache.hadoop.hbase.regionserver.StoreEngine<SF,CP,C,SFM>
Direct Known Subclasses:
DateTieredStoreEngine, DefaultStoreEngine, StripeStoreEngine
@Private public abstract class StoreEngine<SF extends StoreFlusher,CP extends CompactionPolicy,C extends Compactor<?>,SFM extends StoreFileManager> extends Object
StoreEngine is a factory that can create the objects necessary for HStore to operate. Since not all compaction policies, compactors and store file managers are compatible, they are tied together and replaced together via StoreEngine-s.

We expose read write lock methods to upper layer for store operations:

  • Locked in shared mode when the list of component stores is looked at:
    • all reads/writes to table data
    • checking for split
  • Locked in exclusive mode when the list of component stores is modified:
    • closing
    • completing a compaction

It is a bit confusing that we have a StoreFileManager(SFM) and then a StoreFileTracker(SFT). As its name says, SFT is used to track the store files list. The reason why we have a SFT beside SFM is that, when introducing stripe compaction, we introduced the StoreEngine and also the SFM, but actually, the SFM here is not a general 'Manager', it is only designed to manage the in memory 'stripes', so we can select different store files when scanning or compacting. The 'tracking' of store files is actually done in HRegionFileSystem and HStore before we have SFT. And since SFM is designed to only holds in memory states, we will hold write lock when updating it, the lock is also used to protect the normal read/write requests. This means we'd better not add IO operations to SFM. And also, no matter what the in memory state is, stripe or not, it does not effect how we track the store files. So consider all these facts, here we introduce a separated SFT to track the store files.

Here, since we always need to update SFM and SFT almost at the same time, we introduce methods in StoreEngine directly to update them both, so upper layer just need to update StoreEngine once, to reduce the possible misuse.