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 <[email protected]> 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" <[email protected]> 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 >>
