hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Hermans" <shawnherm...@gmail.com>
Subject Re: Practical Upper Limit on Number of Version Stored?
Date Fri, 06 Dec 2013 00:52:14 GMT
My guess is 50 to 200 versions.  Row size is around 300KB of data. 

—
Sent from Mailbox for iPhone

On Thu, Dec 5, 2013 at 6:41 PM, Jean-Marc Spaggiari
<jean-marc@spaggiari.org> wrote:

> Hi Shawn,
> I personnaly like and often suggest this approach. However you need to be
> aware that there is an issue in the current pagination over the versions.
> Except that, your approach will allow you to get the current state by
> looking at the last version,  and the history by looking at all the
> versions. ..
> How big is an event in your system?  How many versions are you planning to
> keep?
> JM
> Le 2013-12-05 17:47, "Shawn Hermans" <shawnhermans@gmail.com> a écrit :
>> All,
>> I am working on an HBase application where we store user events in an HBase
>> table.  The row key is the a user identifier and each column is an event
>> identifier.  Most users only have a handful of events (10 or less), but
>> some users have a few hundred thousand events or more and this causes
>> issues when an HBase client tries to retrieve all those events.
>>
>> We are looking at different ways of limiting then number events returned.
>>  One idea is to store each event using its own column qualifier, but
>> instead use HBase's versioning capability to store the last 100 to 200
>> events. It doesn't seem like we would run into issues with this approach,
>> but I want to see if anyone has had any practical experience in this area.
>>  The advice given in http://hbase.apache.org/book/schema.versions.html is
>> a
>> little ambiguous.
>>
>> Thanks,
>> Shawn
>>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message