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 msegel_hadoop@hotmail.com
 designates 65.55.111.87 as permitted sender)
Message-ID: <BLU0-SMTP1294A39BA30F509AEC3B38298010@phx.gbl>
From: Michael Segel <msegel_hadoop@hotmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_93B28025-5D99-434B-8618-280B6F9313BD";
	protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: row filter - binary comparator at certain range
Date: Mon, 21 Oct 2013 15:05:18 -0500
References: 
 <CAJLyKy2UDxV=Rb6-Yo+a5EZvjSqO8oftURBRr5ebF7RaeLbbsg@mail.gmail.com>
 <1328812425.45012.YahooMailNeo@web121703.mail.ne1.yahoo.com>
 <CAJLyKy2-PYZa=9NVaqrLdUhENs_d8+HeaDaPZ6vKJ+HNrzoZ3A@mail.gmail.com>
 <1328814206.80929.YahooMailNeo@web121704.mail.ne1.yahoo.com>
 <CAJLyKy0POoYZdp=fASbE+OPsGZj5PBKVJ-JGR=Qs1B-YVqbm7A@mail.gmail.com>
 <loom.20131021T060128-995@post.gmane.org>
 <CAH72Ak_ZLS70xiECe8kWpcxW6DYUHXR4ZsqaC4caY1jC4FwPkQ@mail.gmail.com>
 <DC5EBE7F3610EB4CA5C7E92D76873E15180DD42AEC@exchange2007.carrieriq.com>
 <CAG_TOPDUzEc7u=u94L2CWUosVqvbFHuShbt-F6410-k5PPQ-Wg@mail.gmail.com>
To: user@hbase.apache.org
In-Reply-To: 
 <CAG_TOPDUzEc7u=u94L2CWUosVqvbFHuShbt-F6410-k5PPQ-Wg@mail.gmail.com>

--Apple-Mail=_93B28025-5D99-434B-8618-280B6F9313BD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Then its not a SALT. And please don't use the term 'salt' because it has =
specific meaning outside to what you want it to mean.  Just like saying =
HBase has ACID because you write the entire row as an atomic element.  =
But I digress=85.

Ok so to your point=85=20

1 byte =3D=3D 255 possible values.=20

So which will be faster.

creating a list of the 1 byte truncated hash of each possible timestamp =
in your range, or doing 255 separate range scans with the start and stop =
range key set?=20

That will give you the results you want, however=85 I'd go back and have =
them possibly rethink the row key if they can =85 assuming this is the =
base access pattern.

HTH

-Mike


On Oct 21, 2013, at 11:37 AM, James Taylor <jtaylor@salesforce.com> =
wrote:

> Phoenix restricts salting to a single byte.
> Salting perhaps is misnamed, as the salt byte is a stable hash based =
on the
> row key.
> Phoenix's skip scan supports sub-key ranges.
> We've found salting in general to be faster (though there are cases =
where
> it's not), as it ensures better parallelization.
>=20
> Regards,
> James
>=20
>=20
>=20
> On Mon, Oct 21, 2013 at 9:14 AM, Vladimir Rodionov
> <vrodionov@carrieriq.com>wrote:
>=20
>> FuzzyRowFilter does not work on sub-key ranges.
>> Salting is bad for any scan operation, unfortunately. When salt =
prefix
>> cardinality is small (1-2 bytes),
>> one can try something similar to FuzzyRowFilter but with additional
>> sub-key range support.
>> If salt prefix cardinality is high (> 2 bytes) - do a full scan with =
your
>> own Filter (for timestamp ranges).
>>=20
>> Best regards,
>> Vladimir Rodionov
>> Principal Platform Engineer
>> Carrier IQ, www.carrieriq.com
>> e-mail: vrodionov@carrieriq.com
>>=20
>> ________________________________________
>> From: Premal Shah [premal.j.shah@gmail.com]
>> Sent: Sunday, October 20, 2013 10:42 PM
>> To: user
>> Subject: Re: row filter - binary comparator at certain range
>>=20
>> Have you looked at FuzzyRowFilter? Seems to me that it might satisfy =
your
>> use-case.
>>=20
>> =
http://blog.sematext.com/2012/08/09/consider-using-fuzzyrowfilter-when-in-=
need-for-secondary-indexes-in-hbase/
>>=20
>>=20
>> On Sun, Oct 20, 2013 at 9:31 PM, Tony Duan <duanjianmin@126.com> =
wrote:
>>=20
>>> Alex Vasilenko <aa.vasilenko@...> writes:
>>>=20
>>>>=20
>>>> Lars,
>>>>=20
>>>> But how it will behave, when I have salt at the beginning of the =
key to
>>>> properly shard table across regions? Imagine row key of format
>>>> salt:timestamp and rows goes like this:
>>>> ...
>>>> 1:15
>>>> 1:16
>>>> 1:17
>>>> 1:23
>>>> 2:3
>>>> 2:5
>>>> 2:12
>>>> 2:15
>>>> 2:19
>>>> 2:25
>>>> ...
>>>>=20
>>>> And I want to find all rows, that has second part (timestamp) in =
range
>>>> 15-25. What startKey and endKey should be used?
>>>>=20
>>>> Alexandr Vasilenko
>>>> Web Developer
>>>> Skype:menterr
>>>> mob: +38097-611-45-99
>>>>=20
>>>> 2012/2/9 lars hofhansl <lhofhansl@...>
>>> Hi,
>>> Alexandr Vasilenko
>>> Have you ever resolved this issue?i am also facing this iusse.
>>> i also want implement this functionality.
>>> Imagine row key of format
>>> salt:timestamp and rows goes like this:
>>> ...
>>> 1:15
>>> 1:16
>>> 1:17
>>> 1:23
>>> 2:3
>>> 2:5
>>> 2:12
>>> 2:15
>>> 2:19
>>> 2:25
>>> ...
>>>=20
>>> And I want to find all rows, that has second part (timestamp) in =
range
>>> 15-25.
>>>=20
>>> Could you please tell me how you resolve this ?
>>> thanks  in advance.
>>>=20
>>>=20
>>> Tony duan
>>>=20
>>>=20
>>=20
>>=20
>> --
>> Regards,
>> Premal Shah.
>>=20
>> Confidentiality Notice:  The information contained in this message,
>> including any attachments hereto, may be confidential and is intended =
to be
>> read only by the individual or entity to whom this message is =
addressed. If
>> the reader of this message is not the intended recipient or an agent =
or
>> designee of the intended recipient, please note that any review, use,
>> disclosure or distribution of this message or its attachments, in any =
form,
>> is strictly prohibited.  If you have received this message in error, =
please
>> immediately notify the sender and/or Notifications@carrieriq.com and
>> delete or destroy any copy of this message and its attachments.
>>=20


--Apple-Mail=_93B28025-5D99-434B-8618-280B6F9313BD
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIICujCCArYw
ggIfoAMCAQICCQCqTy7yM7wDDTANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQGEwJVUzERMA8GA1UE
CAwISWxsaW5vaXMxEDAOBgNVBAcMB0NoaWNhZ28xDTALBgNVBAoMBE1TQ0MxEDAOBgNVBAMMB3Nl
Z2VsMDIxHzAdBgkqhkiG9w0BCQEWEG1zZWdlbEBzZWdlbC5jb20wHhcNMTMwOTA4MDYxMzA2WhcN
MjMwOTA2MDYxMzA2WjB0MQswCQYDVQQGEwJVUzERMA8GA1UECAwISWxsaW5vaXMxEDAOBgNVBAcM
B0NoaWNhZ28xDTALBgNVBAoMBE1TQ0MxEDAOBgNVBAMMB3NlZ2VsMDIxHzAdBgkqhkiG9w0BCQEW
EG1zZWdlbEBzZWdlbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANbFWB63Zy/IoPTu
4yvE2CU3ePSWb0jvSWlJRWeVRZtXDlIooFY9f1gtDPhtSW/2b67lKOfTfP0o72keQQbZSqU0S1OE
Aw3NpTzvG2rRLF8Fex7bcRtdeW2ZCys8dQJIopB/nr15RAzcEM6aNFs8nUPDw1lKNRoqZTIe9ZW3
VHpBAgMBAAGjUDBOMB0GA1UdDgQWBBTpEjxThxqqZHnWTRn+xfboLLlaIzAfBgNVHSMEGDAWgBTp
EjxThxqqZHnWTRn+xfboLLlaIzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4GBAGWVijpU
r12w+g5q/HlXUQjoCMoHphyWgbGK0PvucVBfyi3GnC7PqxFNQVfMOn9dBTYvK6FcFTZd77RTvniY
K3F7YdzM2fObId90X1xTm9M7RsYWqY4r8v5ObmAyQl9WkcKgs7KFAPgsroKR3ghlayyZy3EyAVpk
zL1QsPKCEA5AMYICtTCCArECAQEwgYEwdDELMAkGA1UEBhMCVVMxETAPBgNVBAgMCElsbGlub2lz
MRAwDgYDVQQHDAdDaGljYWdvMQ0wCwYDVQQKDARNU0NDMRAwDgYDVQQDDAdzZWdlbDAyMR8wHQYJ
KoZIhvcNAQkBFhBtc2VnZWxAc2VnZWwuY29tAgkAqk8u8jO8Aw0wCQYFKw4DAhoFAKCCAYkwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDIxMjAwNTE5WjAjBgkq
hkiG9w0BCQQxFgQUkP1v2LTMwiD44nEDf1mo7tkDWQMwgZIGCSsGAQQBgjcQBDGBhDCBgTB0MQsw
CQYDVQQGEwJVUzERMA8GA1UECAwISWxsaW5vaXMxEDAOBgNVBAcMB0NoaWNhZ28xDTALBgNVBAoM
BE1TQ0MxEDAOBgNVBAMMB3NlZ2VsMDIxHzAdBgkqhkiG9w0BCQEWEG1zZWdlbEBzZWdlbC5jb20C
CQCqTy7yM7wDDTCBlAYLKoZIhvcNAQkQAgsxgYSggYEwdDELMAkGA1UEBhMCVVMxETAPBgNVBAgM
CElsbGlub2lzMRAwDgYDVQQHDAdDaGljYWdvMQ0wCwYDVQQKDARNU0NDMRAwDgYDVQQDDAdzZWdl
bDAyMR8wHQYJKoZIhvcNAQkBFhBtc2VnZWxAc2VnZWwuY29tAgkAqk8u8jO8Aw0wDQYJKoZIhvcN
AQEBBQAEgYC4edPwodgK/5iQ/AAihfH/6S27Sd2ug2sY4lgisn8vA56H6IU9HdhyOJCJpToL7Aoq
9rvUKEVjNLrG1wXRv7iWX19LHxVT03afs9SJ717OLwif4sKYqbdvjKfq7G4F6XZKPmeQUEni7PQn
v41h5KXWIq9o0jCPXaTe027QdhkdEwAAAAAAAA==

--Apple-Mail=_93B28025-5D99-434B-8618-280B6F9313BD--