> -----Original Message----- > From: Bin YANG [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 01, 2007 6:59 PM > To: hadoop-user@lucene.apache.org > Subject: Re: HBase question on HRegions server > > Thank you very much Michael and Jim! > > That means the master does not maintain the mapping from > HRegion to HRegionServer. And the mapping from HRegion to > HRegionServer is in the META and ROOT. Is it right?
Not quite. The master does maintain a mapping of the ROOT and META regions to which region servers are serving them, but not for regions which are part of a user table. There are a couple of reasons for this: - Unlike Bigtable which stores the ROOT location in Chubby, HBase keeps the ROOT location in the Master so that the clients know how to find the ROOT region. - In order for the master to perform administration functions such as table creation, it must know where the META regions are so it can determine whether the table already exists. Further, if a region server dies, the master must scan the META regions to determine which regions the dead server was serving. > So if a client want to read a tablet, it should first find > the ROOT, find corresponding META, and the client will know > which tablet server is serving the tablet. Is it right? Correct. And that is exactly what HConnectionManager does for HTable (which is the client API) > The master just maintains the active RegionServer list. And the master is responsible for assigning regions to region servers. > If the client want to create a new tablet, how would a client > to find a HRegionServer? Any active HRegionServer in master's > list is a candidate? A client should use an HBaseAdmin object which provides the administrative API for the client. > Does the HRgionServer write a new tablet row in the META > directly or ask the Master to write a new tablet row in the META? It depends on the circumstances. Sometimes the region server does, sometimes the master does. > thanks. > > On 11/2/07, Jim Kellerman <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > > > From: Bin YANG [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, November 01, 2007 3:06 AM > > > To: hadoop-user@lucene.apache.org > > > Subject: HBase question on HRegions server > > > > > > Hi, > > > > > > I am confused with some thing in HBase. > > > > > > 1. All data is stored in HDFS. Data is served to clients by > > > HRegionServers. Is it allowed that the tablet T is on > machine A, and > > > served by a HRegionServers running on machine B? > > > > Yes, it is possible. Depending how how many replicas of the > data there > > are in HDFS, it is possible that the data is on machines A, > B, C and > > the region server is running on machine D. > > > > In the future, we will be investigating how to assign regions to a > > region server based on where the data is located. > > > > > What information does the META table maintain? > > > The map from T to the physical address in machine A, or > the map from > > > T to which machine serves it, for example, machine B? > > > > There are three pieces of data stored in the ROOT and META table: > > 1. The HRegionInfo object that describes the region. It includes > > the startKey, endKey, regionId, regionName and the > HTableDescriptor > > 2. The host:port of the region server currently serving the > region 3. > > A sequence number so that we can tell if the host:port is a > > current region assignment or if it is a stale assignment > > > > > 2. Similar to Bigtable paper, what does the tablet > location(section > > > 5.1) stand for? Is it the map from the tablet id to physical > > > address, or the map from the tablet to which machine serves it? > > > > I don't know exactly what Google stores in their meta table. What > > HBase stores is the data above. From it we can contact a > region server > > directly and the region server can locate the region's > files in HDFS. > > > > > thanks > > > > > > > > > -- > > > Bin YANG > > > Department of Computer Science and Engineering Fudan University > > > Shanghai, P. R. China > > > EMail: [EMAIL PROTECTED] > > > > > > > > -- > Bin YANG > Department of Computer Science and Engineering Fudan > University Shanghai, P. R. China > EMail: [EMAIL PROTECTED] >
