[
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17112269#comment-17112269
]
Duo Zhang commented on HBASE-11288:
-----------------------------------
{quote}
True but they are both tables. Operationally that makes things more intuitive.
Eg load balancing across servers etc.
{quote}
How do you plan to load balancing across servers with only a single region?
Let me explain more here. HBase developers are easy to only focus on HBase
itself and want to solve everything in HBase, but maybe sometimes it is not the
best solution in real production.
For example, I'm not impressed by HBASE-18095 while lots of other committers
really love it. As in our deployments, we can also control how we deploy
zookeeper, not only HBase. Zookeeper supports a feature called observer node,
which can be considered as a cache of the zk cluster. So in our company, we
just deploy zk behind a lvs, which has a hostname, for example, zk.mi.com, and
all hbase nodes will use this hostname to communicate with zk. And we also
deploy several observer nodes, behind lvs, which has a hostname, for example,
zk-observer.mi.com, and all the hbase clients will use this hostname to
communiate with zk thus hbase. As you can deploy as many as observer node as
you like, you can easily spread loads across multiple observer nodes, and since
we have a lvs in front, you even do not need to tell users to change their
configuration, while in HBASE-18095, you still need to tell users to change
their configurations when master nodes have been changed.
But anyway, the ConnectionRegsitry is pluggable, so for users who can not
control things other than HBase, they could use the new registry implementation
in HBASE-18095 to reduce the load of zookeeper, and for the users like us, we
could still change back to use the ZKConnectionRegistry. We are both happy.
And for the 'local root region' vs 'root region on rs', my point is that, if we
store the data in master, then we could just expose a very simple API to client
for locating meta, for example
RegionLocations locateMeta(byte[] row);
Then for me, it is also very easy to just implement a simple cache server, to
pull all the content in root from the active master and cache it in memory,
then to serve clients as the 'master' for locating meta. And I could also make
use of lvs, to spread load across multiple cache servers. And for users who can
not control things other than HBase, we could implement something like
HBASE-18095, to let backup masters to serve the locating meta requests.
But if you use a hbase:root table, then you will expose the whole region API to
users. The API is powerful, but hard to simulate, so it will be really hard to
spread the load across multiple servers. Enable read replicas on root table?
Seems a bit overkill and read replicas itself is still not stable enough I
suppose...
Thanks.
> Splittable Meta
> ---------------
>
> Key: HBASE-11288
> URL: https://issues.apache.org/jira/browse/HBASE-11288
> Project: HBase
> Issue Type: Umbrella
> Components: meta
> Reporter: Francis Christopher Liu
> Assignee: Francis Christopher Liu
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
