Thanks, Lars This JIRA is worth looking at. This hint will improve all reads: simple gets, increments and appends.
-Vladimir On Mon, Apr 14, 2014 at 1:46 PM, lars hofhansl <[email protected]> wrote: > The jira would be this one: HBASE-10247. > > If the client promises not muck with timestamps we first look into the > memstore. If we find a version there, we know it is the right one, only > otherwise do we need to check the HFiles. > (This is not possible if the client can set timestamps, because the latest > value added to the memstore might be a backdated Put, or there might be a > futuredated Delete in some of the HFiles.) > > -- Lars > > > ----- Original Message ----- > From: Vladimir Rodionov <[email protected]> > To: "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Monday, April 14, 2014 1:22 PM > Subject: RE: HBase atomic append functionality (not just client) > > Ted, > > The general idea of improving read-modify-write performance is to always > read data from closest and fastest store only: either from MemStore or from > block cache. > The read pipeline in HBase will always read data from HFile as well to > compare versions. This should be optimized with a read hint, for example. > I remember Lars has mentioned some related JIRA? Not sure, though. > > Best regards, > Vladimir Rodionov > Principal Platform Engineer > Carrier IQ, www.carrieriq.com > e-mail: [email protected] > > ________________________________________ > From: Ted Yu [[email protected]] > Sent: Monday, April 14, 2014 12:46 PM > To: [email protected] > Cc: [email protected] > Subject: Re: HBase atomic append functionality (not just client) > > There was discussion on speeding up Append operation by only doing Put at > write time. > When reading, the Puts would be consolidated to produce the correct result. > > Let me try to find the JIRA related to the discussion. > > Cheers > > > On Mon, Apr 14, 2014 at 10:41 AM, Vladimir Rodionov < > [email protected] > > wrote: > > > From HRegion.java: > > > > "Appends performed are done under row lock but reads do not take locks > out > > so this can be seen partially complete by gets and scans." > > > > Appends are partially atomic (you can get partial reads but you will > never > > get corrupted writes) and they are implemented on the server side. > > > > Best regards, > > Vladimir Rodionov > > Principal Platform Engineer > > Carrier IQ, www.carrieriq.com > > e-mail: [email protected] > > > > ________________________________________ > > From: GSK Chaitanya [[email protected]] > > Sent: Monday, April 14, 2014 10:05 AM > > To: [email protected]; [email protected] > > Subject: HBase atomic append functionality (not just client) > > > > Mighty Hbase users and developers, > > > > I have few questions and I'd really appreciate it if someone can clarify > > them. > > > > 1) I want to know if Hbase inherently supports *atomic > > append*functionality like > > *get* and *put*. For my work, I would be using OpenTSDB which is a layer > on > > top of AsynchHBase and AsynchHBase doesnt work with HBase client (which > > supports *atomic append*). > > > > 2) If I understand correctly, atomic append of HBase client internally > does > > a get and put instead of actually appending to the end of the cell. If > > that's the case, I wonder how does this functionality is of much use in > > terms of performance. In our case, we would like a very light weight > append > > functionality. I'd like to know if there are any plans of adding this > > feature to HBase main in the near future. > > > > Thanks, > > Chaitanya > > > > Confidentiality Notice: The information contained in this message, > > including any attachments hereto, may be confidential and is intended to > be > > read only by the individual or entity to whom this message is addressed. > If > > the reader of this message is not the intended recipient or an agent or > > designee of the intended recipient, please note that any review, use, > > disclosure or distribution of this message or its attachments, in any > form, > > is strictly prohibited. If you have received this message in error, > please > > immediately notify the sender and/or [email protected] and > > delete or destroy any copy of this message and its attachments. > > > > > Confidentiality Notice: The information contained in this message, > including any attachments hereto, may be confidential and is intended to be > read only by the individual or entity to whom this message is addressed. If > the reader of this message is not the intended recipient or an agent or > designee of the intended recipient, please note that any review, use, > disclosure or distribution of this message or its attachments, in any form, > is strictly prohibited. If you have received this message in error, please > immediately notify the sender and/or [email protected] and > delete or destroy any copy of this message and its attachments. >
