[
https://issues.apache.org/jira/browse/HBASE-11165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099529#comment-14099529
]
Matteo Bertozzi commented on HBASE-11165:
-----------------------------------------
{quote}I don't see why collocation is required to have the features you
mentioned. IMHO all you need is the mutations/locking/etc to be centrally
managed (ie all updates to meta is sent to the master), the meta itself can be
anywhere. So I'd argue that central management is needed, collocation is not
required. Please correct me if I'm missing something here.{quote}
meta is only modified by the master, and the master is mainly doing operations
on meta. so if meta is down you have a master up which is not useful at much.
Also since all writes to meta are controlled by the master having meta anywhere
else will not improve things since the master is the one processing requests
and you also have to go to another server to perform the operation.
if you are talking about the read side, I can understand why you want to split
it, but isn't having multiple copies even as cache simpler and you'll get the
same results?
> Scaling so cluster can host 1M regions and beyond (50M regions?)
> ----------------------------------------------------------------
>
> Key: HBASE-11165
> URL: https://issues.apache.org/jira/browse/HBASE-11165
> Project: HBase
> Issue Type: Brainstorming
> Reporter: stack
> Attachments: HBASE-11165.zip, Region Scalability test.pdf,
> zk_less_assignment_comparison_2.pdf
>
>
> This discussion issue comes out of "Co-locate Meta And Master HBASE-10569"
> and comments on the doc posted there.
> A user -- our Francis Liu -- needs to be able to scale a cluster to do 1M
> regions maybe even 50M later. This issue is about discussing how we will do
> that (or if not 50M on a cluster, how otherwise we can attain same end).
> More detail to follow.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
