Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of lars.george@gmail.com
 designates 209.85.212.179 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
Subject: Re: how client location a region/tablet?
From: Lars George <lars.george@gmail.com>
In-Reply-To: 
 <CADcMMgG93=iDnx7K0Mc8b01vhcavsFW3J6kRYMryYspY4CLmqg@mail.gmail.com>
Date: Sun, 19 Aug 2012 10:46:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <531086F4-4BF3-4BB2-9B28-CCAA5B5049D6@gmail.com>
References: 
 <CAK_MoStrAVrSYa=Bs5Nae3ZOh7MdZH4eecVupEOtzv_7QfGx7Q@mail.gmail.com>
 <CADcMMgG93=iDnx7K0Mc8b01vhcavsFW3J6kRYMryYspY4CLmqg@mail.gmail.com>
To: user@hbase.apache.org

That is spot on Stack, it is the worst case scenario as you describe, =
i.e. all cached information is stale.

Lars

On Aug 19, 2012, at 6:40 AM, Stack <stack@duboce.net> wrote:

> On Sat, Aug 18, 2012 at 2:13 AM, Lin Ma <linlma@gmail.com> wrote:
>> Hello guys,
>>=20
>> I am referencing the Big Table paper about how a client locates a =
tablet.
>> In section 5.1 Tablet location, it is mentioned that client will =
cache all
>> tablet locations, I think it means client will cache root tablet in
>> METADATA table, and all other tablets in METADATA table (which means =
client
>> cache the whole METADATA table?). My question is, whether HBase =
implements
>> in the same or similar way? My concern or confusion is, supposing =
each
>> tablet or region file is 128M bytes, it will be very huge space (i.e.
>> memory footprint) for each client to cache all tablets or region =
files of
>> METADATA table. Is it doable or feasible in real HBase clusters? =
Thanks.
>>=20
>=20
> Yeah, we client cache's locations, not the data.
>=20
>=20
>> BTW: another confusion from me is in the paper of Big Table section =
5.1
>> Tablet location, it is mentioned that "If the client=92s cache is =
stale, the
>> location algorithm could take up to six round-trips, because stale =
cache
>> entries are only discovered upon misses (assuming that METADATA =
tablets do
>> not move very frequently).", I do not know how the 6 times round trip =
time
>> is calculated, if anyone could answer this puzzle, it will be great. =
:-)
>>=20
>=20
> I'm not sure what the 6 is about either.  Here is a guesstimate:
>=20
> 1. Go to cached location for a server for a particular user region,
> but server says that it does not have a region, the client location is
> stale
> 2. Go back to client cached meta region that holds user region w/ row
> we want, but its location is stale.
> 3. Go to root location, to find new location of meta, but the root
> location has moved.... what the client has is stale
> 4. Find new root location and do lookup of meta region location
> 5. Go to meta region location to find new user region
> 6. Go to server w/ user region
>=20
> St.Ack