[
https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362830#comment-14362830
]
Elliott Clark commented on HBASE-6721:
--------------------------------------
I still don't see the need for the added complexity for most users. HBase is
running the risk of being too big and too complex for what most users will use
it for.
The real answer to get large clusters is to get multi-tenancy to just work.
The best answer is not to add a more different admin tools, config options, and
things that add more operational overheard. As you add more and more machine to
HBase the answer is not to make more and more special cases. It's instead to
make the base case better. Get QOS, quotas, tiered storage, and better load
balancing to work well and the whole idea of group based assignment is then
useless. That's what should be solution for users of HBase. Not more things
that need to be explained in the book for the default config/install. Things
like:
* does locality based load balancing work with groups?
* What should hbck return when there's a region that can't be assigned due to
groups?
* Does hbck know about groups? If it does then what's the message there when I
haven't used that feature? If not then will it break things when I use hbck ?
* How does the open region command work with the groups ?
* Are the commands listed if the balancer isn't the group based balancer ?
* What's the default group?
* Is meta/namespace/acl in the default group?
* I had zookeeper get deleted/go corrupt/ get restored from backup why are all
of my regions moving around?
All of those are added complexities that real users will run into, and in
return only a very few will get any added benefit.
HBase can't provide the great qos and multi-tenancy right now, so the group
based assignment might work well for a specific use case. However it adds
complexity and layers of abstraction that hurt most users, while making the
ideal solution harder. For that reason I'm against anything that's built into
the the default install.
HBase should be more like nginx and less like apache in this regard. If you
need an added feature and it's not what most users want then compile/package it
in. It should not be a kitchen sink with 10 million different xml configs
needed. The first question asked on every posting to user@ mailing list
shouldn't always be "can you post your configs?"
With all that said I do not want this to seem like I dislike the feature, the
code, or the contribution. I really want to say thanks to [~toffer]. I would be
a +1 if the code was a co-proc and a different module, something that was much
less invasive on the main assignment, and master code.
> RegionServer Group based Assignment
> -----------------------------------
>
> Key: HBASE-6721
> URL: https://issues.apache.org/jira/browse/HBASE-6721
> Project: HBase
> Issue Type: New Feature
> Reporter: Francis Liu
> Assignee: Vandana Ayyalasomayajula
> Attachments: 6721-master-webUI.patch, HBASE-6721-DesigDoc.pdf,
> HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf,
> HBASE-6721_10.patch, HBASE-6721_8.patch, HBASE-6721_9.patch,
> HBASE-6721_9.patch, HBASE-6721_94.patch, HBASE-6721_94.patch,
> HBASE-6721_94_2.patch, HBASE-6721_94_3.patch, HBASE-6721_94_3.patch,
> HBASE-6721_94_4.patch, HBASE-6721_94_5.patch, HBASE-6721_94_6.patch,
> HBASE-6721_94_7.patch, HBASE-6721_trunk.patch, HBASE-6721_trunk.patch,
> HBASE-6721_trunk.patch, HBASE-6721_trunk1.patch, HBASE-6721_trunk2.patch
>
>
> In multi-tenant deployments of HBase, it is likely that a RegionServer will
> be serving out regions from a number of different tables owned by various
> client applications. Being able to group a subset of running RegionServers
> and assign specific tables to it, provides a client application a level of
> isolation and resource allocation.
> The proposal essentially is to have an AssignmentManager which is aware of
> RegionServer groups and assigns tables to region servers based on groupings.
> Load balancing will occur on a per group basis as well.
> This is essentially a simplification of the approach taken in HBASE-4120. See
> attached document.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
