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 amits@infolinks.com designates
 207.126.144.129 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9E20080B-CEE7-4F73-806C-FBFE8CB6BED1@gmail.com>
References: 
 <CALte62w4WjZntBsxBBexCG92hrW2OZGQgi_-pP_P3bPG=93rnw@mail.gmail.com>
	<1358994226.69218.YahooMailNeo@web140602.mail.bf1.yahoo.com>
	<CAAMYKhp0bKvVbZy2b9VgzDK5Y6VZx=1+tMBinUQz-t+CRsk=7A@mail.gmail.com>
	<CALte62zkMyE2G+L2rHwtOcDNewAfgs5F1wQnDzQq7G0ydYu02A@mail.gmail.com>
	<CAAMYKhqM+fgNGVnGc0QdnZy_4twx=DykWyTktWGSWM-qKwGfGg@mail.gmail.com>
	<3490608131839349829@unknownmsgid>
	<F6026E66-F8AD-414E-A574-4E2502C819FF@infolinks.com>
	<-3611561647206253620@unknownmsgid>
	<CAAMYKhoB74+W2jp0Wq7ccskxye7gGLRNfASL+Nh0dq1ORxZ5ng@mail.gmail.com>
	<9E20080B-CEE7-4F73-806C-FBFE8CB6BED1@gmail.com>
Date: Sat, 26 Jan 2013 20:40:15 +0200
Message-ID: 
 <CAAMYKhr85WXZnAg-Mpah2M=DzRqY2zu=JqObSzUkSsUrycMrCA@mail.gmail.com>
Subject: Re: HBASE-7114 Increment does not extend Mutation but probably should
From: Amit Sela <amits@infolinks.com>
To: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=bcaec554d84cf5f93104d4355f55

--bcaec554d84cf5f93104d4355f55
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sounds right ;)
I'll try that, thanks !
On Jan 26, 2013 8:30 PM, "Asaf Mesika" <asaf.mesika@gmail.com> wrote:

> Yep.
> I think it would be faster it you will change the Increment object in the
> preIncrement object and add the allCountries column to it.
>
> When you do it in the PostIncrement method, you will do another Increment
> call, thus another :rowLock, write to WAL, etc.
>
> You can benchmark it easily.
>
> On 26 =D7=91=D7=99=D7=A0=D7=95 2013, at 20:01, Amit Sela <amits@infolinks=
.com> wrote:
>
> > The increment has many columns: impressions_country, clicks_country, et=
c.
> > And these counters count events in our system. Since we don't have an
> "all
> > countries" event, I thought it would be best to do that with a
> > RegionObserver (each row has it's own counters so no risk in going
> outside
> > the region right ?) .
> > On Jan 26, 2013 7:15 PM, "Asaf Mesika" <asaf.mesika@gmail.com> wrote:
> >
> >> Why not have the Increment object have two columns: one for the countr=
y
> and
> >> one for the allCountries ?
> >>
> >> Sent from my iPhone
> >>
> >> On 26 =D7=91=D7=99=D7=A0=D7=95 2013, at 18:54, Infolinks <amits@infoli=
nks.com> wrote:
> >>
> >> Yes, of course. It's an all counter for the specific keyword.
> >>
> >> =D7=91-26 =D7=91=D7=99=D7=A0=D7=95 2013, =D7=91=D7=A9=D7=A2=D7=94 18:4=
0, Asaf Mesika <asaf.mesika@gmail.com> =D7=9B=D7=AA=D7=91/=D7=94:
> >>
> >> The all counters is on the same row?
> >>
> >>
> >> By the way, did you guys handle the hbase bug that when an increment i=
s
> >>
> >> sent to region server and fails it still does it but throws an
> exception to
> >>
> >> the client which causes it to do that increment again?
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >>
> >> On 26 =D7=91=D7=99=D7=A0=D7=95 2013, at 17:32, Amit Sela <amits@infoli=
nks.com> wrote:
> >>
> >>
> >> Well, I increment counters where the row key is a keyword and the
> qualifier
> >>
> >> is a country code, and in the post increment region observer I
> increment an
> >>
> >> "all countries" aggregative counter. These counters are divided to
> families
> >>
> >> such as daily, weekly, hourly etc.
> >>
> >> So I get the family map to know which aggregative counter should I
> >>
> >> increment, then I piggyback onto the Result the "all countries" curren=
t
> >>
> >> count.
> >>
> >> On Jan 26, 2013 2:39 AM, "Ted Yu" <yuzhihong@gmail.com> wrote:
> >>
> >>
> >> Amit:
> >>
> >>
> >> Can you tell us what operation you perform on the returned family map =
?
> >>
> >>
> >>
> >> Thanks
> >>
> >>
> >>
> >> On Thu, Jan 24, 2013 at 3:37 AM, Amit Sela <amits@infolinks.com> wrote=
:
> >>
> >>
> >>
> >> I'm using Increment.getFamilyMap in a postIncrement Observer.
> >>
> >>
> >> I'm running with HBase 0.94.2.
> >>
> >>
> >>
> >> Amit.
> >>
> >>
> >>
> >> On Thu, Jan 24, 2013 at 4:23 AM, lars hofhansl <larsh@apache.org>
> wrote:
> >>
> >>
> >>
> >> The reason was that Increment was serialized differently (compared to
> >>
> >>
> >> all
> >>
> >>
> >> other mutations).
> >>
> >>
> >> In trunk that is no longer an issue, since the serialization logic is
> >>
> >>
> >> no
> >>
> >>
> >> longer part of the object to be serialized.
> >>
> >>
> >>
> >>
> >> -- Lars
> >>
> >>
> >>
> >>
> >>
> >> ________________________________
> >>
> >>
> >> From: Ted Yu <yuzhihong@gmail.com>
> >>
> >>
> >> To: dev@hbase.apache.org; user@hbase.apache.org
> >>
> >>
> >> Sent: Wednesday, January 23, 2013 10:25 AM
> >>
> >>
> >> Subject: HBASE-7114 Increment does not extend Mutation but probably
> >>
> >>
> >> should
> >>
> >>
> >>
> >> Hi,
> >>
> >>
> >> I want to get opinion on whether we should proceed with HBASE-7114
> >>
> >>
> >> 'Increment does not extend Mutation but probably should' in trunk.
> >>
> >>
> >>
> >> Is anyone using Increment.setWriteToWAL or Increment.getFamilyMap ?
> >>
> >>
> >> For Increment.setWriteToWAL, are you using the Increment returned ?
> >>
> >>
> >>
> >> Your feedback would be appreciated.
> >>
>
>

--bcaec554d84cf5f93104d4355f55--