hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Spiegelberg (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5335) Dynamic Schema Configurations
Date Wed, 08 Feb 2012 05:02:59 GMT

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

Nicolas Spiegelberg commented on HBASE-5335:

@stack: I understand why some users might want this capability for 'important' toggles that
they make frequently.  I think that should be discussed as a separate JIRA.  At FB (and probably
other production companies), we have a chicken & egg problem where we don't know which
seemingly-obscure values might be useful because we don't have an easy way to toggle them
online (hence the JIRA).  Most of our use cases, we'd alter the table maybe every month or
two with a new, obscure config value that we want to change, so online schema change is acceptable
since we incur minimal latency and no downtime.

Basically, our ZK use case was a UserID->ClusterID mapping for every FB user (large # of
ZNodes).  This had horrible scaling problems, even when we employed batching.  I'm not a great
point of contact for this, but I can get you in contact with one.  As a rule of thumb, we've
been cautious about adding too many ZNodes in the same way that you'd have an HBase admin
be cautious about adding too many regions.
> 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
> 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


View raw message