I think you misunderstand concept of "memstore". That's just the name of
the temporary in-memory storage. Each region has its own memstore, and thus
it's located on the regionserver itself.
On Wed, Sep 12, 2012 at 11:24 PM, Jason Huang <[EMAIL PROTECTED]> wrote:
> So - I guess at the time of the query we don't know if the data is in
> Memstore or in the RegionServer. In order to ensure we get the most
> recent version of data, every Hbase Read query will first go to
> Memstore and see if the data is there, and then go to RegionServers if
> it couldn't find that data in Memstore?
> On Wed, Sep 12, 2012 at 5:19 PM, Adrien Mogenet
> <[EMAIL PROTECTED]> wrote:
> > WAL is just there for recover. Reads will meet the Memstore on their read
> > path, that's how LSM Trees are working.
> > On Wed, Sep 12, 2012 at 11:15 PM, Jason Huang <[EMAIL PROTECTED]>
> >> This might be a naive question but I am not able to find a good answer
> >> from searching online.
> >> The online guide mentioned that "Puts and Deletes are collected into
> >> an in-memory structure called the MemStore. Before the MemStore is
> >> update the changes are written to a Write Ahead Log (WAL) to enable
> >> recovery in case a server crashes. When it reaches a certain size the
> >> MemStore is flushed to disk into StoreFile."
> >> So, if an application tried to query a certain piece of data that
> >> hasn't been flushed to disk into StoreFile yet, where is HBase
> >> designed to get that piece of data? Is it going to the Region servers
> >> and tried to get the previous version of this data, or is it smart
> >> enough to go to the MemStore or WAL to get the most recent version of
> >> data?
> >> thanks!
> >> Jason
> > --
> > Adrien Mogenet
> > 06.59.16.64.22
> > http://www.mogenet.me