hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zsongbo <zson...@gmail.com>
Subject Re: financial time series database
Date Sun, 05 Apr 2009 09:39:09 GMT
Wesleys suggestions may make sense.

Are there technical lim


On Sat, Apr 4, 2009 at 9:00 AM, Ryan Rawson <ryanobjc@gmail.com> wrote:

> Another reason to perhaps avoid tons of versions is there is no query
> mechanism, nor will there ever be.  The mechanism is limited to asking for
> either the last N versions, or all of them.  If you are querying a date
> range, this is obviously a problem.
>
> -ryan
>
> On Fri, Apr 3, 2009 at 7:25 AM, stack <stack@duboce.net> wrote:
>
> > On Thu, Apr 2, 2009 at 9:53 PM, Wesley Chow <wes.chow@s7labs.com> wrote:
> >
> > >
> > > Are there technical limitations to the number of different timestamps
> per
> > > cell? If it's the case that you're doing to be dealing with tens of
> > > thousands to millions of entries all at one cell, perhaps you should
> > check
> > > that to make sure it's a reasonable use case. The examples in the HBase
> > docs
> > > number the timestamps in single digits, and I don't recall any mention
> of
> > > very large numbers.
> >
> >
> >
> > Agreed.  I'd  imagine that tens of thousands of versions currently would
> > suffer in same manner as tens of thousands of columns -- hbase running
> > increasingly slower as count went up, at least until we address
> > HBASE-867<https://issues.apache.org/jira/browse/HBASE-867> "If
> > millions of columns in a column family, hbase scanner won't come
> > up<https://issues.apache.org/jira/browse/HBASE-867>
> > "
> >
> >
> > St.Ack
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message