hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anoop John <anoop.hb...@gmail.com>
Subject Re: Cache invalidation in Blockcache
Date Sun, 30 Mar 2014 06:25:46 GMT
In block cache data is cached not as rows..  As u know when writing HFiles,
one HFile will logically split into blocks (With def size of 64K)  . During
reads data is read from files as blocks. (Even if u do a single row get)
from file HBase has to to read atleast one block.   The block cache caches
these blocks.  So during read if we find the requested block being in the
cache, we wont read again from HDFS.  This way the block cache helps.

So the 1st question answer is no.

During reading, it is not like 1st check in memstore and then in block
cache.  It is like a Heap of scanners on the memstore and on all HFiles.
KVs comes out of this scanner as per the result of KV comparator
comparison.  Compare  row, cf, family, TS  and finally a memstoreTS (which
is like increasing on every write)  So mostly a KV from memstore will
normally comes out 1st before those from files.  But during writes one can
always specify TS, if some one writes explicetly with TS and 1st write some
future TS cell and it got flushed to a file and later write a past TS kv
and it is in memstore , the above said normal case may not come
applicable.. Hope I make it clear for u..   Again when u read from Files,
files are read as block by block and during that time check in Cache. If
that block of this file is already read into cache, there wont be an IO.

-Anoop-
On Sun, Mar 30, 2014 at 11:44 AM, chandra kant <
chandralakshmikant90@gmail.com> wrote:

> Hi,
> I have Blockcache enabled on my table. So, I read a row and it's stored in
> Blockcache . Next, I do a write on that row and I read it again .
> My question is -  does writing that row invalidates the entry of that row
> in Blockcache ?
> Also, while reading , does RegionScanner first check memstore for any
> updates regrading that row or Blockcache ?
> It's quite confusing from what  I have read..
> Thanks
> Chandra
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message