Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of lhofhansl@yahoo.com designates
 216.109.114.64 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=z9+aSaMiIm4+71oxCCzmGRAiTdsCc6Wcm0tvzl9nd0rHrLaX45/jcrhKMIOL/eQcIM8faSsdj9NEl0KSIfGevE8nj55mGrvrAf27N5Als0p0AiEdYj0GW1TtBc9cTYsqjbgj3mD+N1dwtWHhcJm6yBWsTPKVcCiBy8LNxHxWyPc=;
References: 
 <CAK+VKuMQfum=nSfWBeCqDxrzU+jrG=nZhZ=DyaRj4gORPstrXA@mail.gmail.com>
	<DC5EBE7F3610EB4CA5C7E92D76873E1518629B593E@exchange2007.carrieriq.com>
	<CALte62x7ERuH3B0vdF_JW73+ye_fCTf7L_OQ5zXAa1vu96FwEg@mail.gmail.com>
	<DC5EBE7F3610EB4CA5C7E92D76873E1518629B5940@exchange2007.carrieriq.com>
	<1397508389.60110.YahooMailNeo@web140602.mail.bf1.yahoo.com>
 <CAAg3a2qH6nY-_PzTcHhLLP9_mTkspkM781JEgni-PUBt4M=bGQ@mail.gmail.com>
Message-ID: <1397509443.64627.YahooMailNeo@web140606.mail.bf1.yahoo.com>
Date: Mon, 14 Apr 2014 14:04:03 -0700 (PDT)
From: lars hofhansl <larsh@apache.org>
Reply-To: lars hofhansl <larsh@apache.org>
Subject: Re: HBase atomic append functionality (not just client)
To: "user@hbase.apache.org" <user@hbase.apache.org>,
  "dev@hbase.apache.org" <dev@hbase.apache.org>
In-Reply-To: 
 <CAAg3a2qH6nY-_PzTcHhLLP9_mTkspkM781JEgni-PUBt4M=bGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Yep. And even further, imagine how we could improve scanning.=0AIf we only =
look for the latest version, we can scan memstore/HFiles in order of file a=
ge, if we find a version we're done, no need to even seek the other HFiles.=
=0A=0A-- Lars=0A=0A=0A----- Original Message -----=0AFrom: Vladimir Rodiono=
v <vladrodionov@gmail.com>=0ATo: "dev@hbase.apache.org" <dev@hbase.apache.o=
rg>; lars hofhansl <larsh@apache.org>=0ACc: "user@hbase.apache.org" <user@h=
base.apache.org>=0ASent: Monday, April 14, 2014 1:51 PM=0ASubject: Re: HBas=
e atomic append functionality (not just client)=0A=0AThanks, Lars=0AThis JI=
RA is worth looking at. This hint will improve all reads: simple=0Agets, in=
crements and appends.=0A=0A-Vladimir=0A=0A=0A=0AOn Mon, Apr 14, 2014 at 1:4=
6 PM, lars hofhansl <larsh@apache.org> wrote:=0A=0A> The jira would be this=
 one: HBASE-10247.=0A>=0A> If the client promises not muck with timestamps =
we first look into the=0A> memstore. If we find a version there, we know it=
 is the right one, only=0A> otherwise do we need to check the HFiles.=0A> (=
This is not possible if the client can set timestamps, because the latest=
=0A> value added to the memstore might be a backdated Put, or there might b=
e a=0A> futuredated Delete in some of the HFiles.)=0A>=0A> -- Lars=0A>=0A>=
=0A> ----- Original Message -----=0A> From: Vladimir Rodionov <vrodionov@ca=
rrieriq.com>=0A> To: "dev@hbase.apache.org" <dev@hbase.apache.org>=0A> Cc: =
"user@hbase.apache.org" <user@hbase.apache.org>=0A> Sent: Monday, April 14,=
 2014 1:22 PM=0A> Subject: RE: HBase atomic append functionality (not just =
client)=0A>=0A> Ted,=0A>=0A> The general idea of improving read-modify-writ=
e performance is to always=0A> read data from closest and fastest store onl=
y: either from MemStore or from=0A> block cache.=0A> The=A0 read pipeline i=
n HBase will always read data from HFile as well to=0A> compare versions. T=
his should be optimized with a read hint, for example.=0A> I remember Lars =
has mentioned some related JIRA? Not sure, though.=0A>=0A> Best regards,=0A=
> Vladimir Rodionov=0A> Principal Platform Engineer=0A> Carrier IQ, www.car=
rieriq.com=0A> e-mail: vrodionov@carrieriq.com=0A>=0A> ____________________=
____________________=0A> From: Ted Yu [yuzhihong@gmail.com]=0A> Sent: Monda=
y, April 14, 2014 12:46 PM=0A> To: dev@hbase.apache.org=0A> Cc: user@hbase.=
apache.org=0A> Subject: Re: HBase atomic append functionality (not just cli=
ent)=0A>=0A> There was discussion on speeding up Append operation by only d=
oing Put at=0A> write time.=0A> When reading, the Puts would be consolidate=
d to produce the correct result.=0A>=0A> Let me try to find the JIRA relate=
d to the discussion.=0A>=0A> Cheers=0A>=0A>=0A> On Mon, Apr 14, 2014 at 10:=
41 AM, Vladimir Rodionov <=0A> vrodionov@carrieriq.com=0A> > wrote:=0A>=0A>=
 > From HRegion.java:=0A> >=0A> > "Appends performed are done under row loc=
k but reads do not take locks=0A> out=0A> > so this can be seen partially c=
omplete by gets and scans."=0A> >=0A> > Appends are partially atomic (you c=
an get partial reads but you will=0A> never=0A> > get corrupted writes) and=
 they are implemented on the server side.=0A> >=0A> > Best regards,=0A> > V=
ladimir Rodionov=0A> > Principal Platform Engineer=0A> > Carrier IQ, www.ca=
rrieriq.com=0A> > e-mail: vrodionov@carrieriq.com=0A> >=0A> > _____________=
___________________________=0A> > From: GSK Chaitanya [gskchaitanya12@gmail=
.com]=0A> > Sent: Monday, April 14, 2014 10:05 AM=0A> > To: user@hbase.apac=
he.org; dev@hbase.apache.org=0A> > Subject: HBase atomic append functionali=
ty (not just client)=0A> >=0A> > Mighty Hbase users and developers,=0A> >=
=0A> > I have few questions and I'd really appreciate it if someone can cla=
rify=0A> > them.=0A> >=0A> > 1) I want to know if Hbase inherently supports=
 *atomic=0A> > append*functionality like=0A> > *get* and *put*. For my work=
, I would be using OpenTSDB which is a layer=0A> on=0A> > top of AsynchHBas=
e and AsynchHBase doesnt work with HBase client (which=0A> > supports *atom=
ic append*).=0A> >=0A> > 2) If I understand correctly, atomic append of HBa=
se client internally=0A> does=0A> > a get and put instead of actually appen=
ding to the end of the cell. If=0A> > that's the case, I wonder how does th=
is functionality is of much use in=0A> > terms of performance. In our case,=
 we would like a very light weight=0A> append=0A> > functionality. I'd like=
 to know if there are any plans of adding this=0A> > feature to HBase main =
in the near future.=0A> >=0A> > Thanks,=0A> > Chaitanya=0A> >=0A> > Confide=
ntiality Notice:=A0 The information contained in this message,=0A> > includ=
ing any attachments hereto, may be confidential and is intended to=0A> be=
=0A> > read only by the individual or entity to whom this message is addres=
sed.=0A> If=0A> > the reader of this message is not the intended recipient =
or an agent or=0A> > designee of the intended recipient, please note that a=
ny review, use,=0A> > disclosure or distribution of this message or its att=
achments, in any=0A> form,=0A> > is strictly prohibited.=A0 If you have rec=
eived this message in error,=0A> please=0A> > immediately notify the sender=
 and/or Notifications@carrieriq.com and=0A> > delete or destroy any copy of=
 this message and its attachments.=0A>=0A> >=0A>=0A> Confidentiality Notice=
:=A0 The information contained in this message,=0A> including any attachmen=
ts hereto, may be confidential and is intended to be=0A> read only by the i=
ndividual or entity to whom this message is addressed. If=0A> the reader of=
 this message is not the intended recipient or an agent or=0A> designee of =
the intended recipient, please note that any review, use,=0A> disclosure or=
 distribution of this message or its attachments, in any form,=0A> is stric=
tly prohibited.=A0 If you have received this message in error, please=0A> i=
mmediately notify the sender and/or Notifications@carrieriq.com and=0A> del=
ete or destroy any copy of this message and its attachments.=0A>=0A