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 Troy.Bryant@telus.com
 designates 208.38.59.78 as permitted sender)
DomainKey-Signature: s=orkaan.nssi; d=telus.com; c=nofws; q=dns;
  h=X-IronPort-Anti-Spam-Filtered:
   X-IronPort-Anti-Spam-Result:X-IronPort-AV:Received:
   Received:From:To:Date:Subject:Thread-Topic:Thread-Index:
   Message-ID:Accept-Language:Content-Language:
   X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage:
   Content-Type:MIME-Version;
  b=XPVswGl6KdYuMLeefoe4+CzyiApeEJq6e6xYotznXNsPgaosBTxMYT4K
   HUAjtO+Tp+voaJYYCBP4Kn0mP3uDu+WysQTNlOOvBdw92pxSjlaByk+es
   u5wn24haEo5rNSaHnI8v59sJi9ecBgfF4zliRPBpT9fOCoCkFxkKchfxR
   E=;
From: Troy Bryant <Troy.Bryant@telus.com>
To: "user@hbase.apache.org" <user@hbase.apache.org>
Date: Thu, 27 Feb 2014 09:37:05 -0700
Subject: Row Deletion by Column Value
Thread-Topic: Row Deletion by Column Value
Thread-Index: Ac8z2iLL2BY2P+WqTueadEvS6wFNPQ==
Message-ID: <5B153F3C89024C4AAD13F8A6D2CAC0B02AB47883B7@WP41072.corp.ads>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_5B153F3C89024C4AAD13F8A6D2CAC0B02AB47883B7WP41072corpad_"
MIME-Version: 1.0

--_000_5B153F3C89024C4AAD13F8A6D2CAC0B02AB47883B7WP41072corpad_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Using 0.92.2

We're looking into custom garbage collection methods.  Due to some business=
 logic, we'd like to be able to delete rows based on the value of one of th=
e columns, these deletes can be eventual rather than immediate.  We have wr=
itten a Map Reduce job that works, but we aren't sure if it's fast enough i=
n the long run.

I have two questions:
Would it be possible to implement a coprocessor that would essentially do t=
he column value check during a major compaction, and only write rows that p=
ass the check?  I'm not sure this is feasible because based on what I under=
stand, the reads occur at the key-value level and not the row level.

Since our deletes can be eventual, would it be possible/faster to just tomb=
stone the rows rather than delete them during our map reduce job, and let t=
he major compaction handle the actual deletion?  If I'm not mistaken addDel=
eteMarker would be the method for this.

Thanks for your time.

Troy Bryant


--_000_5B153F3C89024C4AAD13F8A6D2CAC0B02AB47883B7WP41072corpad_--