hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Rodionov <vladrodio...@gmail.com>
Subject Re: HBase atomic append functionality (not just client)
Date Mon, 14 Apr 2014 20:51:45 GMT
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 <larsh@apache.org> 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 <vrodionov@carrieriq.com>
> To: "dev@hbase.apache.org" <dev@hbase.apache.org>
> Cc: "user@hbase.apache.org" <user@hbase.apache.org>
> 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: vrodionov@carrieriq.com
>
> ________________________________________
> From: Ted Yu [yuzhihong@gmail.com]
> Sent: Monday, April 14, 2014 12:46 PM
> To: dev@hbase.apache.org
> Cc: user@hbase.apache.org
> 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 <
> vrodionov@carrieriq.com
> > 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: vrodionov@carrieriq.com
> >
> > ________________________________________
> > From: GSK Chaitanya [gskchaitanya12@gmail.com]
> > Sent: Monday, April 14, 2014 10:05 AM
> > To: user@hbase.apache.org; dev@hbase.apache.org
> > 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 Notifications@carrieriq.com 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 Notifications@carrieriq.com and
> delete or destroy any copy of this message and its attachments.
>

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