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

Enis Soztutar commented on HBASE-7236:
--------------------------------------

I think some of the confusion comes from differentiating between schema / 
attributes / config. 
 - Schema as in what is the name of column
 - Attributes as in TTL, MIN_VERSIONS, which are part of the hbase data model
 - Config as in data block encoding per column family
As it is right now, HTable/ColumnDescriptors contain all three, and there is a 
very thin line for differentiating what is an attribute and what is a config 
setting (is compression an attribute or a config?)

I think it still makes sense to keep these three together in the descriptors, 
since although there in an increasing number of new configs coming up, they are 
still not that much to cause any significant load.

Is putting arbitrary byte[]'s into the table/column descriptors a valid use 
case for the clients. From the code base, it seems that it is only used for 
putting configuration per table/column. If not, should we deprecate that?
Also to keep the compatibility with the xml-based config, I think we should 
make the config map as String -> String, rather than byte[]->byte[]. 
                
> add per-table/per-cf configuration via metadata
> -----------------------------------------------
>
>                 Key: HBASE-7236
>                 URL: https://issues.apache.org/jira/browse/HBASE-7236
>             Project: HBase
>          Issue Type: New Feature
>          Components: Compaction
>    Affects Versions: 0.96.0
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>         Attachments: HBASE-7236-PROTOTYPE.patch, HBASE-7236-PROTOTYPE.patch, 
> HBASE-7236-PROTOTYPE-v1.patch, HBASE-7236-v0.patch, HBASE-7236-v1.patch, 
> HBASE-7236-v2.patch, HBASE-7236-v3.patch
>
>
> Regardless of the compaction policy, it makes sense to have separate 
> configuration for compactions for different tables and column families, as 
> their access patterns and workloads can be different. In particular, for 
> tiered compactions that are being ported from 0.89-fb branch it is necessary 
> to have, to use it properly.
> We might want to add support for compaction configuration via metadata on 
> table/cf.

--
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