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 michael_segel@hotmail.com
 designates 65.55.111.109 as permitted sender)
Message-ID: <BLU0-SMTP198FC33A20169C2548B622A8F540@phx.gbl>
Content-Type: text/plain; charset="GB2312"
MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: delete rows without writing HLog may be appear in the future?
From: Michael Segel <michael_segel@hotmail.com>
In-Reply-To: 
 <CAMPNBf4ENBn+4-X7arZV+wVQJ+7j=E7LBQZYekt3YVq-kVFG_Q@mail.gmail.com>
Date: Wed, 21 Nov 2012 10:18:13 -0600
Content-Transfer-Encoding: quoted-printable
References: 
 <CAMPNBf5RpVD1=hiw3Pci-5GHK5q8RQCaGy0eYP6k51g8V3NE5g@mail.gmail.com>
 <BLU0-SMTP32122BA8EB2CD04C3600E618F540@phx.gbl>
 <CAMPNBf6GPM_77HqTXmjSqkknEc0OBcFYBmKCcU9yHDzQJJZg7Q@mail.gmail.com>
 <CAGngS9eGcqq+ak7tVefzRBYHjyet18J38drXMew08ZxcqUBgWQ@mail.gmail.com>
 <CAMPNBf4ENBn+4-X7arZV+wVQJ+7j=E7LBQZYekt3YVq-kVFG_Q@mail.gmail.com>
To: user@hbase.apache.org

Ok,=20

First, I am a firm believer of not bypassing the WAL period.

I'm not sure why you would be seeing the data after a delete. If what =
you said is true, then either the delete got lost or the delete happened =
before the insert (which doesn't make sense because the delete should =
have thrown an exception...)

I am also confused by what you mean that the delete has to be low =
latency.=20
What's the timing difference between writing a delete to the WAL or =
bypassing the WAL.=20

Also I am concerned by your statement that you do the delete, it looks =
like it was deleted, only a week or two later, its back.=20
That doesn't make sense because the data written to the WAL would have =
long since been flushed and then if you delete, then the flag should =
have still remained.=20
Can you check the timestamp of the cell?=20

Something isn't right.=20

On Nov 21, 2012, at 9:37 AM, Bing Jiang <jiangbinglover@gmail.com> =
wrote:

> In our apps, deletes will be frequent, and it occurs to each records =
every
> time, if write hlog, the performance and response will be low. In =
fact,we
> can bear with some records with delete fail, but recently I have found =
more
> records delete some time ago, for example, one week , they reappear
> again.Then, that makes me curious about what should do next., delete =
with
> writing hlog, or put without hlog....
> On Nov 21, 2012 11:19 PM, "Kevin O'dell" <kevin.odell@cloudera.com> =
wrote:
>=20
>> Bing,
>>=20
>>  I am curious to hear more about Mike's question.  Why are you not =
using
>> the WAL for your deletes?
>>=20
>> On Wed, Nov 21, 2012 at 10:17 AM, Bing Jiang =
<jiangbinglover@gmail.com
>>> wrote:
>>=20
>>> yes,hbase has made a compaction between batch-put and deletes. any =
ideas?
>>>=20
>>> On Nov 21, 2012 11:10 PM, "Michael Segel" =
<michael_segel@hotmail.com>
>>> wrote:
>>>>=20
>>>> Some time later?
>>>>=20
>>>> Time of course is relative, so I have to ask what occurred between =
the
>>> write and the delete?
>>>> How much time? Did you have any compactions in between the write =
and
>> the
>>> delete?
>>>>=20
>>>> Why are you not consistent in your use of the WAL ?
>>>>=20
>>>>=20
>>>> On Nov 21, 2012, at 6:37 AM, Bing Jiang <jiangbinglover@gmail.com>
>>> wrote:
>>>>=20
>>>>> hi=A3=ACall.
>>>>> I want to describe a phenomenon that happens to our hbase cluster.
>>>>> I use puts(List<Put>) to insert many records with writing hlog
>> enable,
>>>>> and some time later I delete all of these records with writing =
hlog
>>> disable.
>>>>> When one week later, i scan the table, I found some records I have
>>> delete
>>>>> reappear again.
>>>>> It is an interesting case. In my opinion, if we delete data =
without
>>> enable
>>>>> writing hlog, when regionserver fails, the log will replay in =
another
>>>>> regionserver.
>>>>> Can anyone tell me if I persist on deleting records without enable
>>> writing
>>>>> hlog, is there a way to prevent these records from reappearing =
again
>>> some
>>>>> time later?
>>>>>=20
>>>>> Cheers!
>>>>> --
>>>>> Bing Jiang
>>>>> weibo: http://weibo.com/jiangbinglover
>>>>> BLOG: http://blog.sina.com.cn/jiangbinglover
>>>>> BLOG: http://www.binospace.com
>>>>> National Research Center for Intelligent Computing Systems
>>>>> Institute of Computing technology
>>>>> Graduate University of Chinese Academy of Science
>>>>=20
>>>=20
>>=20
>>=20
>>=20
>> --
>> Kevin O'Dell
>> Customer Operations Engineer, Cloudera
>>=20