hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7236) add per-table/per-cf configuration via metadata
Date Thu, 13 Dec 2012 06:25:21 GMT

    [ 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

Mime
View raw message