hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Shelukhin <ser...@hortonworks.com>
Subject Re: HBase atomic append functionality (not just client)
Date Tue, 15 Apr 2014 18:13:37 GMT
Hmm... Wouldn't mvcc prevent seeing partial append?
Append is just put in the end, the way it is currently implemented.

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.

NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

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