hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Marc Spaggiari <jean-m...@spaggiari.org>
Subject Re: Practical Upper Limit on Number of Version Stored?
Date Fri, 06 Dec 2013 00:41:05 GMT
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

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

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