[
https://issues.apache.org/jira/browse/HBASE-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118590#comment-13118590
]
Todd Lipcon commented on HBASE-4524:
------------------------------------
I've spoken to some Bigtable engineers who said that the two-layer ROOT/META
thing turned out to be a bit of a mistake given today's machines. The reason
being that today's servers, if you put only META on a single server, easily
have enough RAM and CPU horsepower to handle a several-GB meta region and
hundreds of thousands of requests/second, since all the requests can hit cache.
The recovery argument makes some sense, but I think if you deploy META alone on
a server and configure it to flush often, the log recovery should be
near-instantaneous and failover would be fast. If META is split across many
regions, then it's likely to be intermingled on the same servers as user data,
and hence would be slow to split logs.
So I'm not against doing this, but another alternate path might be:
- add a feature so that the load balancer can be configured to keep META
"alone" with no other regions on the server. This would be used on big clusters.
- remove ROOT, and just store META directly in ZK (ROOT is essentially
vestigial these days)
Any thoughts on this? I'd just like to consider the option of simplifying the
META/ROOT situation rather than complicating it.
> support for more than one region in .META. table
> ------------------------------------------------
>
> Key: HBASE-4524
> URL: https://issues.apache.org/jira/browse/HBASE-4524
> Project: HBase
> Issue Type: Improvement
> Reporter: Ming Ma
> Assignee: Ming Ma
>
> It seems there are some assumptions in the code that .META. table only has
> one region FIRST_META_REGIONINFO in the following areas:
> 1) .META. table update with user region info.
> 2) .META. regions assignment.
> 3) .META. table split handling.
> Perhaps we don't have such requirement until we scale to really large number
> of regions like 1M.
--
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
