[ 
https://issues.apache.org/jira/browse/HBASE-6428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481118#comment-13481118
 ] 

Lars Hofhansl commented on HBASE-6428:
--------------------------------------

I would like to revive this issue. If Store.createWriterInTmp and 
Store.completeCompaction were public and Store.completeCompaction would allow 
also a list of new writers to be passed in, it would be possible a "poor man's 
tiered compaction" like this:

RegionObserver.preCompact(Store, Scanner) would traverse through the scanner, 
and write the (say) 3 newest version of each KV into a writer and all others 
into another writer, (or one could tier based on multiple ranges of timestamp 
and hence keep historical data separate from current data).
Upon completion it would call completeCompaction passing all created writers.

RegionObserver.preCompact would probably also need to know the compaction type 
(so that this tiering could be different between major and minor compactions).

Does this make sense? I have a need to store historical data life in HBase for 
occasional historical queries, but would like to avoid a big impact to scanners 
who only care for the newest KVs.

                
> Pluggable Compaction policies
> -----------------------------
>
>                 Key: HBASE-6428
>                 URL: https://issues.apache.org/jira/browse/HBASE-6428
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Lars Hofhansl
>
> For some usecases is useful to allow more control over how KVs get compacted.
> For example one could envision storing old versions of a KV separate HFiles, 
> which then rarely have to be touched/cached by queries querying for new data.
> In addition these date ranged HFile can be easily used for backups while 
> maintaining historical data.
> This would be a major change, allowing compactions to provide multiple 
> targets (not just a filter).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to