Thanks Ted, for the suggestions.
On 02/04/2011, at 3:58 PM, Ted Dunning wrote:
> Depending on the speed requirements associated with retrieving bunches of
> messages, hbase may have a real edge here. This is a special problem in
> that there are common query patterns that allow contiguous reads
Depending on the speed requirements associated with retrieving bunches of
messages, hbase may have a real edge here. This is a special problem in
that there are common query patterns that allow contiguous reads of lots of
data. That gives a huge advantage to systems like hbase that store data
org
Not original with me, I have to admit.
Some of the ideas are best described in the OpenTSDB descriptions.
On Fri, Apr 1, 2011 at 8:01 PM, M. C. Srivas wrote:
> Ted, this is a pretty clever idea.
>
>
> On Thu, Mar 31, 2011 at 9:27 PM, Ted Dunning wrote:
>
>> Solr/Elastic search is a fine solutio
Have you considered using Cassandra?
Kevin
On Fri, Apr 1, 2011 at 11:01 PM, M. C. Srivas wrote:
> Ted, this is a pretty clever idea.
>
> On Thu, Mar 31, 2011 at 9:27 PM, Ted Dunning
> wrote:
>
> > Solr/Elastic search is a fine solution, but probably won't be quite as
> fast
> > as a well-tune
Ted, this is a pretty clever idea.
On Thu, Mar 31, 2011 at 9:27 PM, Ted Dunning wrote:
> Solr/Elastic search is a fine solution, but probably won't be quite as fast
> as a well-tuned hbase solution.
>
> One key assumption you seem to be making is that you will store messages
> only once. If you
Solr/Elastic search is a fine solution, but probably won't be quite as fast
as a well-tuned hbase solution.
One key assumption you seem to be making is that you will store messages
only once. If you are willing to make multiple updates to tables, then you
can arrange the natural ordering of the t
