hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Rodionov <vrodio...@carrieriq.com>
Subject RE: Practical Upper Limit on Number of Version Stored?
Date Fri, 06 Dec 2013 03:50:21 GMT
Version is just a timestamp (event time) => naturally fits time-series (event) types of
Besides this, events are immutable objects, if they are not, not than they are not events.

Best regards,
Vladimir Rodionov
Principal Platform Engineer
Carrier IQ, www.carrieriq.com
e-mail: vrodionov@carrieriq.com

From: Michael Segel [michael_segel@hotmail.com]
Sent: Thursday, December 05, 2013 5:10 PM
To: user@hbase.apache.org
Subject: Re: Practical Upper Limit on Number of Version Stored?

You really don't want to do this.
Its not what the versioning was meant for and it has a couple of serious flaws.

The biggest flaw... what happens when you want to delete a version? ...

There are other options... depending on your use case and how you use the events.

Truly using versioning beyond versions of the same data.. not a good idea.

On Dec 5, 2013, at 4:47 PM, Shawn Hermans <shawnhermans@gmail.com> wrote:

> 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

The opinions expressed here are mine, while they may reflect a cognitive thought, that is
purely accidental.
Use at your own risk.
Michael Segel
michael_segel (AT) hotmail.com

Confidentiality Notice:  The information contained in this message, including any attachments
hereto, may be confidential and is intended to be read only by the individual or entity to
whom this message is addressed. If the reader of this message is not the intended recipient
or an agent or designee of the intended recipient, please note that any review, use, disclosure
or distribution of this message or its attachments, in any form, is strictly prohibited. 
If you have received this message in error, please immediately notify the sender and/or Notifications@carrieriq.com
and delete or destroy any copy of this message and its attachments.

View raw message