Return-Path: Delivered-To: apmail-hadoop-hbase-dev-archive@locus.apache.org Received: (qmail 65715 invoked from network); 5 Apr 2008 21:10:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Apr 2008 21:10:00 -0000 Received: (qmail 23591 invoked by uid 500); 5 Apr 2008 21:10:01 -0000 Delivered-To: apmail-hadoop-hbase-dev-archive@hadoop.apache.org Received: (qmail 23581 invoked by uid 500); 5 Apr 2008 21:10:00 -0000 Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hbase-dev@hadoop.apache.org Delivered-To: mailing list hbase-dev@hadoop.apache.org Received: (qmail 23572 invoked by uid 99); 5 Apr 2008 21:10:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Apr 2008 14:10:00 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Apr 2008 21:09:27 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 64705234C0BB for ; Sat, 5 Apr 2008 14:07:24 -0700 (PDT) Message-ID: <1177732869.1207429644410.JavaMail.jira@brutus> Date: Sat, 5 Apr 2008 14:07:24 -0700 (PDT) From: "stack (JIRA)" To: hbase-dev@hadoop.apache.org Subject: [jira] Created: (HBASE-565) Move Table Schema out of HRegionInfo MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 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.