Return-Path: X-Original-To: apmail-hbase-user-archive@www.apache.org Delivered-To: apmail-hbase-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F19AB9D04 for ; Wed, 15 Aug 2012 11:50:22 +0000 (UTC) Received: (qmail 86633 invoked by uid 500); 15 Aug 2012 11:48:42 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 86002 invoked by uid 500); 15 Aug 2012 11:48:35 -0000 Mailing-List: contact user-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hbase.apache.org Delivered-To: mailing list user@hbase.apache.org Received: (qmail 85948 invoked by uid 99); 15 Aug 2012 11:48:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 11:48:32 +0000 X-ASF-Spam-Status: No, hits=-0.5 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of yongyong313@gmail.com designates 209.85.160.169 as permitted sender) Received: from [209.85.160.169] (HELO mail-gh0-f169.google.com) (209.85.160.169) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 11:48:27 +0000 Received: by ghrr18 with SMTP id r18so2013067ghr.14 for ; Wed, 15 Aug 2012 04:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dh643hL1yvvM3Vv7xSLaxDWbwZ45wdf9PiM4IJ7GrTU=; b=AUdHm3WQMdhhKUeUH62i3eRLayWL3EcCUercjD0CJgiZmsAkj+GPn4EoORPaax/dnO Dxtsj/7DJ8+6exMzZDNG1yW43wSj88xkpMz26qA9DJsi6gHKl/T50XLlWc6wIWGEnKTS ezl/dD3i4Fz+jZn/ZDAQTybDrsL12tTOnKbc9A3Oweqqpc5CBcH2ibF1QN53snNW+LIR MFewE5Nok93E6LWg/iWeL0JV13FLfdRpMkzPm0ZJSKrrqiw3PZQC1sKdhJUogahpRu3i GIRgTy6/B92XVPCQQm4TSN9txzDGbu0X3c46djswyoTAXV+rEzuzG93zlND3t+9p8obU xR5Q== MIME-Version: 1.0 Received: by 10.68.231.132 with SMTP id tg4mr26145195pbc.159.1345031286700; Wed, 15 Aug 2012 04:48:06 -0700 (PDT) Received: by 10.68.222.104 with HTTP; Wed, 15 Aug 2012 04:48:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Aug 2012 13:48:06 +0200 Message-ID: Subject: Re: Put w/ timestamp -> Deleteall -> Put w/ timestamp fails From: yonghu To: user@hbase.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi Harsh, I have a question of your description. The deleted tag masks the new inserted value with old timestamp, that's why the new inserted data can'be seen. But after major compaction, this new value will be seen again. So, the question is that how the deletion really executes. In my understanding, the deletion will delete all the data values which TSs are less equal than the TS of the deleted tag. So, if you insert a value with old TS after you insert a deleted tag, it should also be deleted at the compaction time. For example, if I first insert (k1,t1), and then delete (k1,t1) with deleted tag which TS is greater than t1, then reinsert (k1,t1) again. So, at the compaction time, two (k1,t1) should be deleted. wish your response! Yong On Wed, Aug 15, 2012 at 7:53 AM, Takahiko Kawasaki wrote: > Dear Harsh, > > Thank you very much for your detailed explanation. I could understand > what had been going on during my put/scan/delete operations. I'll modify > my application and test programs taking the timestamp implementation > into consideration. > > Best Regards, > Takahiko Kawasaki > > 2012/8/15 Harsh J > >> When a Delete occurs, an insert is made with the timestamp being the >> current time (to indicate it is the latest version). Hence, when you >> insert a value after this with an _older_ timestamp, it is not taken >> in as the latest version, and is hence ignored when scanning. This is >> why you do not see the data. >> >> If you instead insert this after a compaction has fully run on this >> store file, then your value will indeed get shown after insert, cause >> at that moment there wouldn't exist such a row with a latest timestamp >> at all. >> >> hbase(main):060:0> flush 'test-table' >> 0 row(s) in 0.1020 seconds >> >> hbase(main):061:0> major_compact 'test-table' >> 0 row(s) in 0.0400 seconds >> >> hbase(main):062:0> put 'test-table', 'row4', 'test-family', 'value', 10 >> 0 row(s) in 0.0230 seconds >> >> hbase(main):063:0> scan 'test-table' >> ROW COLUMN+CELL >> row4 column=test-family:, timestamp=10, value=value >> 1 row(s) in 0.0060 seconds >> >> I suppose this is why it is recommended not to mess with the >> timestamps manually, and instead just rely on versions. >> >> On Tue, Aug 14, 2012 at 8:24 PM, Takahiko Kawasaki >> wrote: >> > Hello, >> > >> > I have a problem where 'put' with timestamp does not succeed. >> > I did the following at the HBase shell. >> > >> > (1) Do 'put' with timestamp. >> > # 'scan' shows 1 row. >> > >> > (2) Delete the row by 'deleteall'. >> > # 'scan' says "0 row(s)". >> > >> > (3) Do 'put' again by the same command line as (1). >> > # 'scan' says "0 row(s)" ! Why? >> > >> > (4) Increment the timestamp value by 1 and try 'put' again. >> > # 'scan' still says "0 row(s)"! Why? >> > >> > The command lines I actually typed are as follows and the attached >> > file is the output from the command lines. >> > >> > scan 'test-table' >> > put 'test-table', 'row3', 'test-family', 'value' >> > scan 'test-table' >> > deleteall 'test-table', 'row3' >> > scan 'test-table' >> > put 'test-table', 'row3', 'test-family', 'value' >> > scan 'test-table' >> > deleteall 'test-table', 'row3' >> > scan 'test-table' >> > put 'test-table', 'row4', 'test-family', 'value', 10 >> > scan 'test-table' >> > deleteall 'test-table', 'row4' >> > scan 'test-table' >> > put 'test-table', 'row4', 'test-family', 'value', 10 >> > scan 'test-table' >> > put 'test-table', 'row4', 'test-family', 'value', 10 >> > scan 'test-table' >> > quit >> > >> > Is this behavior the HBase specification? >> > >> > My cluster is built using CDH4 and the HBase version is 0.92.1-cdh4.0.0. >> > >> > Could anyone give me any insight, please? >> > >> > Best Regards, >> > Takahiko Kawasaki >> >> >> >> -- >> Harsh J >>