hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (HBASE-565) Move Table Schema out of HRegionInfo
Date Wed, 23 Apr 2008 22:41:22 GMT

     [ https://issues.apache.org/jira/browse/HBASE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

stack resolved HBASE-565.

    Resolution: Duplicate

Marking as duplicate of HBASE-451

> Move Table Schema out of HRegionInfo
> ------------------------------------
>                 Key: HBASE-565
>                 URL: https://issues.apache.org/jira/browse/HBASE-565
>             Project: Hadoop HBase
>          Issue Type: Improvement
>            Reporter: stack
>            Assignee: stack
>             Fix For: 0.2.0
> Every HRI carries a HTableDescriptor instance.  When a Region context needs a table descriptor,
doesn't have far to go.  Move the HTD out of HRI and when wanted, go elsewhere to go get it.
> In Bigtable paper, Schema is stored over in Chubby.  Could run a Zookeeper instance easy-enough
and store it there.  Would run on master.  ZooKeeper snapshots its in-memory database to local
director on disk -- not DFS.  If a ZooKeeper cluster, then that should protect against loss.
 Master could tell regionservers the address of the zookeeper instance to use (as it does
other vitals currently).  Later we could add the indirection so zookeeper is where regionservers
register themselves on startup and master could watch here for the coming and going of servers.
> Or, we could store the schema in DFS.  Good thing would be replication of critical data
and an hbasck tool could read the file to learn table schema (Would be awkward having to read
zookeeper format out on local filesystem).  Downside would be that any change in schema would
require offlining unless we develop a message that the master could send regionservers to
notify them of of minor schema changes -- e.g. flip to being memory-based or to being compressed
or that two column families are now of a single locality group (Zookeeper has the watcher
mechanism where regionservers could 'notice' schema changes).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message