CfP HBaseCon2017 Asia, August 4th, 2017 in Shenzhen, China

2017-04-12 Thread Duo Zhang
HBaseCon is the community event for Apache HBase, the Hadoop database, a distributed, scalable, big data store that provides random real time read/write access to your big data. All HBase contributors, developers, operators, and users of all skill levels are welcome to swap stories and learn from

Re: Efficient time based queries - TIMERANGE or STARTROW/STOPROW?

2017-04-12 Thread Josh Elser
If it's helpful to state it in generic terms: specifying a range of HBase timestamps is *only* a post-filter (server-side) and *never* a primary search criteria. In other words, searching by the HBase timestamp is a full-table scan (exhaustive search). While the timestamp can be nice for certain

Re: Scan returns incomplete results

2017-04-12 Thread Kohki Nishio
As far as I can see, the change is in ClientScanner class, which is a part of Hbase-client, does this work inside Server (region server?) ? Thanks -Kohki > On Apr 12, 2017, at 6:03 PM, Ted Yu wrote: > > Does the release (deployed on servers) contain HBASE-15378 ? > >

Scan returns incomplete results

2017-04-12 Thread Kohki Nishio
Hello HBase users ! I’m seeing very strange behavior with HBase (1.1.2) and I’d like to ask some help here. I’m scanning rows but sometimes it returns incomplete results. Let’s say I’m expecting 60 rows to come back, most of times I get all of them. However sometimes (1 in 50), I get only 1 or

Re: Efficient time based queries - TIMERANGE or STARTROW/STOPROW?

2017-04-12 Thread Ted Yu
Since STARTROW is specified (with uuid) in both of your examples, I think their efficiency should be tantamount. Cheers On Wed, Apr 12, 2017 at 10:33 AM, Josh wrote: > Hi, > > I am just getting started with HBase, and have a question about the > efficiency of timestamp based

Efficient time based queries - TIMERANGE or STARTROW/STOPROW?

2017-04-12 Thread Josh
Hi, I am just getting started with HBase, and have a question about the efficiency of timestamp based scans. My table's row key has structure `uuid#reverse_timestamp` where reverse_timestamp is (java.lang.Long.MAX_VALUE - time in millis when the row was written). For a given uuid I want to be