Wesleys suggestions may make sense. Are there technical lim
On Sat, Apr 4, 2009 at 9:00 AM, Ryan Rawson <[email protected]> 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 <[email protected]> wrote: > > > On Thu, Apr 2, 2009 at 9:53 PM, Wesley Chow <[email protected]> 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 > > >
