ConcatenatedLists should have unit test.
Should this define be in the Interface or do you think it implementation specific?
+ public static final String BLOCKING_STOREFILES_KEY = "hbase.hstore.blockingStoreFiles";
Not certain, having things in HStore seems to be the convention. Store isn't a "real" interface that invites different implementation
On StripeStoreFileManager, do we know if this approach has merit? Have we run models or actual test runs and can see it saves i/o? Would be interesting to know. Do we have to commit it to figure this out? I can see committing all the refactorings which allow different compaction policies but would think a compaction engine would need to have proven merit before it goes in? What you think Sergey?
I have an integration test in
HBASE-8000, but have only run it for correctness now.
I plan to make a bigger test for perf, and move to commit after having some numbers.
Do we have to have a L0? Can we not flush multiple files when we flush, one per boundary in the region? Was that thought just too much work flushing?
I was concerned about many small files, and scope creep into memstore, as discussed.
Let me do a write-up on this (probably useful anyway), and discuss on dev list.
After integration tests on tiny files (not a target scenario for this, but still), I wonder if impact of L0 files on # of files to be read for gets is indeed worth it.
On the other hand for scans, and for overall situation large number of small files is not good.