hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: Allowed upper limit to HColumnDescriptor.setMaxVersion(..)?
Date Wed, 05 Oct 2011 03:52:39 GMT
MaxVersions and MinVersions are different features.
MaxVersion identifies the max number of versions you want to keep (just to state the obvious).
MinVersion is used together with TTL (and soon with deletes - see HBASE-4536), to indicate
the minimum number of version you want keep around even when they should be expired or were
deleted.


There is no way to disable MaxVersions, just set it to a very large number.

MinVersions is by default disabled (setting is 0), which means rows past their TTL and deleted
rows will be removed during compaction.


I am thinking about how to state that more clearly in the documentation.


-- Lars



________________________________
From: Doug Meil <doug.meil@explorysmedical.com>
To: "user@hbase.apache.org" <user@hbase.apache.org>
Sent: Tuesday, October 4, 2011 4:32 PM
Subject: Re: Allowed upper limit to HColumnDescriptor.setMaxVersion(..)?


The default for versioning is 3, unfortunately the sub-section also cites
(incorrectly) that the min is 0.  That sub-section is trying to indicate
the minimum legal value.  I am working on clearing that entry up with
another developer.





On 10/4/11 6:04 PM, "Micah Whitacre" <mkwhitacre@gmail.com> wrote:

>Are you surmising that from the description of setting a minimum version?
>
>On Tue, Oct 4, 2011 at 2:31 PM, Doug Meil <doug.meil@explorysmedical.com>
>wrote:
>>
>> http://hbase.apache.org/book.html#schema.versions
>>
>>
>> I believe if you set that to 0 it should disable the versioning.
>>
>>
>>
>> On 10/4/11 2:21 PM, "Micah Whitacre" <mkwhitacre@gmail.com> wrote:
>>
>>>I guess what I'm asking is there a way to set "infinite" or no max
>>>bounds on versions (e.g. setMaxVersion(-1) possibly)?  Or do I have to
>>>call setMaxVersion(Integer.MAX_VALUE) or setMaxVersion(<some large
>>>guess>)?  If a large guess is the way to go, what sort of overhead
>>>costs might we need to consider when finding the right balance point
>>>between room to grow and the maintenance support cost of needing to
>>>expand later?
>>>
>>>We plan on building MapReduce jobs to clean up versions based on some
>>>conditions so the value shouldn't get that large but the conditions
>>>for cleaning up those versions might be decided by other consumers of
>>>the service.  So having room to grow is ideal.
>>>
>>>On Tue, Oct 4, 2011 at 11:36 AM, Doug Meil
>>><doug.meil@explorysmedical.com> wrote:
>>>>
>>>> Hi there-
>>>>
>>>> re:  "i don't care store them all"
>>>>
>>>>
>>>> What do you mean?
>>>>
>>>>
>>>>
>>>> On 10/4/11 12:20 PM, "Micah Whitacre" <mkwhitacre@gmail.com> wrote:
>>>>
>>>>>In reading the documentation all I've seen suggestions on how to set
>>>>>the value and the default value.  However I haven't seen any
>>>>>indication how to set the value to "i don't care store them all" or if
>>>>>there is a maximum bounds aside from Integer.MAX_VALUE.  Does anyone
>>>>>know?
>>>>>
>>>>>Thanks,
>>>>>Micah
>>>>>
>>>>>[1] -
>>>>>http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/HColumnDescrip
>>>>>to
>>>>>r.
>>>>>html#setMaxVersions(int)
>>>>
>>>>
>>
>>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message