[
https://issues.apache.org/jira/browse/HBASE-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232697#comment-13232697
]
Phabricator commented on HBASE-5335:
------------------------------------
nspiegelberg has commented on the revision "[jira] [HBASE-5335] Dynamic Schema
Config".
INLINE COMMENTS
src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:947 Important
notes:
1. CompoundConfiguration is a derived class from Configuration
2. there is a CompoundConfiguration.add(Configuration) function
HRegion.conf = CompoundConfiguration(BaseConf, HTD)
if you passed HRegion.conf to the daughter region constructor on a split, the
daughter region would have:
HRegion.conf
= CompoundConfiguration(CompoundConfiguration(BaseConf, HTD), HTD)
= CompoundConfiguration(BaseConf, HTD, HTD)
We need to dedupe the HTD.
src/main/java/org/apache/hadoop/hbase/util/CompoundConfiguration.java:1 I
guess the question is: do we want to refactor the existing API & both all conf
classes under a conf directory? I put this under util because I didn't want to
clutter the main folder with a class that was only supposed to be used
internally. I considered putting it under the regionserver folder. Maybe
that's a better fit?
src/test/java/org/apache/hadoop/hbase/HBaseTestCase.java:169 yeah. another
option is making a copy constructor
src/main/ruby/hbase/admin.rb:187 Basically, your schema would look like:
NAME => 'blah', BLOOMFILTER => ROWCOL,
ADVANCED => {"hbase.hstore.compaction.ratio" => "0.25"}
I don't want to explain the notion of "ADVANCED" too much beyond HBase
committers. Basically, it's only a toggle for people who know what they're
doing and aren't afraid to be power users and look at code. If we get really
common config patterns, we should pull them out to reserved keywords for common
users and then map. For example:
COMPACT_RATIO => 'hbase.hstore.compaction.ratio'
Why make a config option that most people won't play with? Because , as
power users, we can iterate on functionality & help users. There is now a
workaround for a specific user's problem without modifying code and we don't
have to have advanced deprecation strategies like we would with a reserved
keyword.
REVISION DETAIL
https://reviews.facebook.net/D2247
> Dynamic Schema Configurations
> -----------------------------
>
> Key: HBASE-5335
> URL: https://issues.apache.org/jira/browse/HBASE-5335
> Project: HBase
> Issue Type: New Feature
> Reporter: Nicolas Spiegelberg
> Assignee: Nicolas Spiegelberg
> Labels: configuration, schema
> Attachments: D2247.1.patch, D2247.2.patch
>
>
> Currently, the ability for a core developer to add per-table & per-CF
> configuration settings is very heavyweight. You need to add a reserved
> keyword all the way up the stack & you have to support this variable
> long-term if you're going to expose it explicitly to the user. This has
> ended up with using Configuration.get() a lot because it is lightweight and
> you can tweak settings while you're trying to understand system behavior
> [since there are many config params that may never need to be tuned]. We
> need to add the ability to put & read arbitrary KV settings in the HBase
> schema. Combined with online schema change, this will allow us to safely
> iterate on configuration settings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
