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 < [email protected]> 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 >
