pdated on during a time range.
>I was hoping that I could to time range scan.
>
>Regards,
>Srikanth
>
>
>
>-Original Message-
>From: Stuti Awasthi [mailto:stutiawas...@hcl.com]
>Sent: Monday, October 10, 2011 3:44 PM
>To: user@hbase.apache.org
>Subject: RE
hoping that I could to time range scan.
Regards,
Srikanth
-Original Message-
From: Stuti Awasthi [mailto:stutiawas...@hcl.com]
Sent: Monday, October 10, 2011 3:44 PM
To: user@hbase.apache.org
Subject: RE: Performance characteristics of scans using timestamp as the filter
Yes its true
homas [mailto:thomas.steinmau...@scch.at]
Sent: Monday, October 10, 2011 2:32 PM
To: user@hbase.apache.org
Subject: RE: Performance characteristics of scans using timestamp as the filter
Hello,
others have stated that one shouldn't try to use timestamps, although I haven't
figured out why? If it's reli
ch.at]
Sent: Monday, October 10, 2011 2:32 PM
To: user@hbase.apache.org
Subject: RE: Performance characteristics of scans using timestamp as the
filter
Hello,
others have stated that one shouldn't try to use timestamps, although I
haven't figured out why? If it's reliability, w
:32 PM
To: user@hbase.apache.org
Subject: RE: Performance characteristics of scans using timestamp as the filter
Hello,
others have stated that one shouldn't try to use timestamps, although I haven't
figured out why? If it's reliability, which means, rows are omitted, even if
timestamp AFAIK changes when you update a row even
cell values didn't change.
Regards,
Thomas
-Original Message-
From: Stuti Awasthi [mailto:stutiawas...@hcl.com]
Sent: Montag, 10. Oktober 2011 10:07
To: user@hbase.apache.org
Subject: RE: Performance characteristics of scans using tim
: Monday, October 10, 2011 1:20 PM
To: user@hbase.apache.org
Subject: Re: Performance characteristics of scans using timestamp as the filter
Is it possible to do incremental processing without putting the timestamp in
the leading part of the row key in a more efficient manner i.e. process data
Is it possible to do incremental processing without putting the timestamp in
the leading part of the row key in a more efficient manner i.e. process
data that came within the last hour/ 2 hour etc ? I can't seem to find a
good answer to this question myself.
On Mon, Oct 10, 2011 at 12:09 AM, Stei
Leif,
we are pretty much in the same boat with a custom timestamp at the end of a
three-part rowkey, so basically we end up with reading all data when processing
daily batches. Beside performance aspects, have you seen that using internals
timestamps for scans etc... work reliable?
Or did you
(super late answer, I'm cleaning up my old unread emails)
This sort of sounds like what Mozilla did for the crash reports.
The issue with your solution is when you're looking to get only a
small portion of your whole dataset you still have to go over the rest
of the data to reach it. So if you ju
10 matches
Mail list logo
