[
https://issues.apache.org/jira/browse/HBASE-22938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16917901#comment-16917901
]
stack edited comment on HBASE-22938 at 8/28/19 7:59 PM:
--------------------------------------------------------
Which system tables? What schema does each system table need?
* Namespace table has been integrated already
* ACL table
* Replication Peers (and history)
What else?
Should make note of loadings -- e.g. updating offsets per RS for peers will
mean lots of writing -- and then too, in any new design, should try and spread
loading so when split, load is distributed not lumped.
was (Author: stack):
Which system tables? What schema does each system table need?
* Namespace table has been integrated already
* ACL table
* Replication Peers (and history)
What else?
> Fold all the system tables to hbase:meta
> ----------------------------------------
>
> Key: HBASE-22938
> URL: https://issues.apache.org/jira/browse/HBASE-22938
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Duo Zhang
> Priority: Major
>
> Quote my post on HBASE-15867 here, on how to deal with the dead lock when we
> want to store replication queues to hbase:replication table.
> {quote}
> We could add a special prefix in the row key for different system tables, and
> make a special family for it. For example, for all the records in hbase:acl,
> we could introduce a prefix like ':::acl:::', since we do not allow ':' in
> either namespace or table name, so it will not conflict with the existing
> table related records. And the family could be namd as 'acl'.
> And we could make a special split policy that only splits at these special
> prefixs, so it will not break any assumptions so far, as all the records for
> the 'system table' are in the same region.
> {quote}
> And I think there are also other advantages, for example the start up logic
> can be greatly simplified.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
