Hi James,
Great to hear that Phoenix supports this kind of table schema. Seems like
i'll go ahead with Bucketing for timeseries data.
Thanks,
Anil
On Tue, Sep 24, 2013 at 9:36 AM, James Taylor jtay...@salesforce.comwrote:
Hey Anil,
The solution you've described is the best we've found for
Inline
On Mon, Sep 23, 2013 at 6:15 PM, Shahab Yunus shahab.yu...@gmail.comwrote:
Yeah, I saw that. In fact that is why I recommended that to you as I
couldn't infer from your email that whether you have already gone through
that source or not.
Yes, i was aware of that article. But my read
I'm only know of the links already embedded in the blog page that I sent
you or you have this.
https://groups.google.com/forum/#!forum/hbasewd
Regards,
Shahab
On Tue, Sep 24, 2013 at 11:12 AM, anil gupta anilgupt...@gmail.com wrote:
Inline
On Mon, Sep 23, 2013 at 6:15 PM, Shahab Yunus
Hey Anil,
The solution you've described is the best we've found for Phoenix (inspired
by the work of Alex at Sematext).
You can do all of this in a few lines of SQL:
CREATE TABLE event_data(
who VARCHAR, type SMALLINT, id BIGINT, when DATE, payload VARBINARY
CONSTRAINT pk PRIMARY KEY
Hi All,
I have a secondary index(inverted index) table with a rowkey on the basis
of Timestamp of an event. Assume the rowkey as TimeStamp in Epoch.
I also store some extra(apart from main_table rowkey) columns in that table
for doing filtering.
The requirement is to do range-based scan on the
http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
Here you can find the discussion, trade-offs and working code/API (even for
M/R) about this and the approach you are trying out.
Regards,
Shahab
On Mon, Sep 23, 2013 at 5:41
Hi Shahab,
If you read my solution carefully. I am already doing that.
Thanks,
Anil Gupta
On Mon, Sep 23, 2013 at 3:51 PM, Shahab Yunus shahab.yu...@gmail.comwrote:
http://blog.sematext.com/2012/04/09/hbasewd-avoid-regionserver-hotspotting-despite-writing-records-with-sequential-keys/
Yeah, I saw that. In fact that is why I recommended that to you as I
couldn't infer from your email that whether you have already gone through
that source or not. A source, who did the exact same thing and discuss it
in much more detail and concerns aligning with yours (in fact I think some
of the
