[
https://issues.apache.org/jira/browse/HBASE-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13507160#comment-13507160
]
stack commented on HBASE-7236:
------------------------------
[~sershe] IIUC, you are expanding CompoundConfiguration to do table and
'overrides'?
pros:
1. You go one place to get your config., the 'Configuration' (which could be a
CompoundConfiguration w/ family or table specifics and overrides)?
2. Generalizes what Andrew did doing cache configuration over in hbase-6114?
How would this help us get to changing configuration on the fly? Looks like it
doesn't change our current story. CompoundConfiguration is setup in HRegion or
ColumnFamily setup still..
If we start to record metadata on a table, say column types, would we use this
mechanism?
How would 'overrides' be specified in the shell say? (Patch doesn't seem to
say) We have means of altering table and column descriptors. Where would
'overrides' go?
bq. however, making it explicit and separate from miscellaneous metadata would
be cleaner imho.
Can you say more on above?
HTableDescriptor and HColumnDescriptor dictionaries are key/value maps that get
persisted into the filesystem when changed. We read them them throughout the
codebase and we list them in master UIs, etc. Will they blow up under this new
use case? HTD and HCD are mostly schema with a little config. This direction
would seem to be using these descriptors to add table or column scoped configs.
Should we be working to undo schema and config conflation rather than compound
it?
> add per-table/per-cf compaction 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
>
>
> 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
