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 A64381026F for ; Sun, 21 Apr 2013 00:26:06 +0000 (UTC) Received: (qmail 7602 invoked by uid 500); 21 Apr 2013 00:26:04 -0000 Delivered-To: apmail-hbase-user-archive@hbase.apache.org Received: (qmail 7549 invoked by uid 500); 21 Apr 2013 00:26:04 -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 7539 invoked by uid 99); 21 Apr 2013 00:26:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Apr 2013 00:26:04 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of yuzhihong@gmail.com designates 209.85.215.41 as permitted sender) Received: from [209.85.215.41] (HELO mail-la0-f41.google.com) (209.85.215.41) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Apr 2013 00:25:58 +0000 Received: by mail-la0-f41.google.com with SMTP id ee20so669096lab.14 for ; Sat, 20 Apr 2013 17:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=C12CnGEL34O24QdvZzAxqL8TO62c70F9X1+5ryiAPrc=; b=hD+ilzgMK0vXAAONF4phCcv5OWB54DgKYvFTBbCoXMD4OaPXYq+jGo5G/1AFsrBDwY 0xcKncL9dek+LU89yyDoki/p7qR4jc/n197qXRg/5aiwVNjvVPLU4azm6etDvjo23wyq 46slCz6kKvFzyMJBN3SNyKt3e26MfjaHo0kfd/Qu9Rlj8AIWlR7cqhkSfBMS6YrXBp4k 697N44V60ZJPxcAI5vtciqAVAg3zUDIwo+j+ilXWz0+CLdcnsL1KSLHlzBfoqSLr2al3 Pch969DVTrI0UqqdsJZm4U5gJ2Wx+n0yjPh4s6XmCygnMjrluE22xaZT3QrFAIGekYcM wZfA== MIME-Version: 1.0 X-Received: by 10.112.132.227 with SMTP id ox3mr10688039lbb.108.1366503937358; Sat, 20 Apr 2013 17:25:37 -0700 (PDT) Received: by 10.112.5.101 with HTTP; Sat, 20 Apr 2013 17:25:37 -0700 (PDT) In-Reply-To: References:

Date: Sat, 20 Apr 2013 17:25:37 -0700 Message-ID: Subject: Re: Overwrite a row From: Ted Yu To: user@hbase.apache.org Content-Type: multipart/alternative; boundary=047d7b343a1ac5430704dad3fda5 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b343a1ac5430704dad3fda5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here is code from 0.94 code base: public void mutateRow(final RowMutations rm) throws IOException { new ServerCallable(connection, tableName, rm.getRow(), operationTimeout) { public Void call() throws IOException { server.mutateRow(location.getRegionInfo().getRegionName(), rm); return null; where RowMutations has the following check: private void internalAdd(Mutation m) throws IOException { int res =3D Bytes.compareTo(this.row, m.getRow()); if(res !=3D 0) { throw new IOException("The row in the recently added Put/Delete " + Bytes.toStringBinary(m.getRow()) + " doesn't match the original one " + Bytes.toStringBinary(this.row)); This means you need to issue multiple mutateRow() calls for different rows. I think you should consider the potential impact on performance due to this limitation. For advanced usage, take a look at MultiRowMutationEndpoint: * This class demonstrates how to implement atomic multi row transactions using * {@link HRegion#mutateRowsWithLocks(java.util.Collection, java.util.Collection)} * and Coprocessor endpoints. Cheers On Sat, Apr 20, 2013 at 10:11 AM, Kristoffer Sj=F6gren wr= ote: > Just to absolutely be clear, is this also true for a batch that span > multiple rows? > > > On Sat, Apr 20, 2013 at 2:42 PM, Ted Yu wrote: > > > Operations within each batch are atomic. > > They would either all succeed or all fail. > > > > Time stamps would all refer to the latest cell (KeyVal). > > > > Cheers > > > > On Apr 20, 2013, at 12:17 AM, Kristoffer Sj=F6gren > wrote: > > > > > The schema is known beforehand so this is exactly what I need. Great! > > > > > > One more question. What guarantees does the batch operation have? Are > the > > > operations contained within each batch atomic? I.e. all mutations wil= l > be > > > given the same timestamp? If something fails, all operation fail or c= an > > it > > > fail partially? > > > > > > Thanks for your help, much appreciated. > > > > > > Cheers, > > > -Kristoffer > > > > > > > > > On Sat, Apr 20, 2013 at 4:47 AM, Ted Yu wrote: > > > > > >> I don't know details about Kristoffer's schema. > > >> If all the column qualifiers are known a priori, mutateRow() should > > serve > > >> his needs. > > >> > > >> HBase allows arbitrary number of columns in a column family. If the > > schema > > >> is dynamic, mutateRow() wouldn't suffice. > > >> If the column qualifiers are known but the row is very wide (and a f= ew > > >> columns are updated per call), performance would degrade. > > >> > > >> Just some factors to consider. > > >> > > >> Cheers > > >> > > >> On Fri, Apr 19, 2013 at 1:41 PM, Mohamed Ibrahim < > mibrahim@mibrahim.net > > >>> wrote: > > >> > > >>> Actually I do see it in the 0.94 JavaDocs ( > > >> > > > http://hbase.apache.org/0.94/apidocs/org/apache/hadoop/hbase/client/HTabl= e.html#mutateRow(org.apache.hadoop.hbase.client.RowMutations) > > >>> ), > > >>> so may be it was added in 0.94.6 even though the jira says fixed in > > 0.95 > > >> . > > >>> I haven't used it though, but it seems that's what you're looking > for. > > >>> > > >>> Sorry for confusion. > > >>> > > >>> Mohamed > > >>> > > >>> > > >>> On Fri, Apr 19, 2013 at 4:35 PM, Mohamed Ibrahim < > > mibrahim@mibrahim.net > > >>>> wrote: > > >>> > > >>>> It seems that 0.95 is not released yet, mutateRow won't be a > solution > > >> for > > >>>> now. I saw it in the downloads and I thought it was released. > > >>>> > > >>>> > > >>>> On Fri, Apr 19, 2013 at 4:18 PM, Mohamed Ibrahim < > > >> mibrahim@mibrahim.net > > >>>> wrote: > > >>>> > > >>>>> Just noticed you want to delete as well. I think that's supported > > >> since > > >>>>> 0.95 in mutateRow ( > > >> > > > http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.htm= l#mutateRow(org.apache.hadoop.hbase.client.RowMutations) > > >> ). > > >>>>> You can do multiple puts and deletes and they will be performed > > >>> atomically. > > >>>>> So you can remove qualifiers and put new ones. > > >>>>> > > >>>>> Mohamed > > >>>>> > > >>>>> > > >>>>> On Fri, Apr 19, 2013 at 3:44 PM, Kristoffer Sj=F6gren < > > stoffe@gmail.com > > >>>> wrote: > > >>>>> > > >>>>>> What would you suggest? I want the operation to be atomic. > > >>>>>> > > >>>>>> > > >>>>>> On Fri, Apr 19, 2013 at 8:32 PM, Ted Yu > > wrote: > > >>>>>> > > >>>>>>> What is the maximum number of versions do you allow for the > > >>> underlying > > >>>>>>> table ? > > >>>>>>> > > >>>>>>> Thanks > > >>>>>>> > > >>>>>>> On Fri, Apr 19, 2013 at 10:53 AM, Kristoffer Sj=F6gren < > > >>> stoffe@gmail.com > > >>>>>>>> wrote: > > >>>>>>> > > >>>>>>>> Hi > > >>>>>>>> > > >>>>>>>> Is it possible to completely overwrite/replace a row in a sing= le > > >>>>>> _atomic_ > > >>>>>>>> action? Already existing columns and qualifiers should be > removed > > >>> if > > >>>>>> they > > >>>>>>>> do not exist in the data inserted into the row. > > >>>>>>>> > > >>>>>>>> The only way to do this is to first delete the row then insert > > >> new > > >>>>>> data > > >>>>>>> in > > >>>>>>>> its place, correct? Or is there an operation to do this? > > >>>>>>>> > > >>>>>>>> Cheers, > > >>>>>>>> -Kristoffer > > >> > > > --047d7b343a1ac5430704dad3fda5--