hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Daniel Cryans" <jdcry...@gmail.com>
Subject Re: Insertion and timestamps test
Date Mon, 11 Aug 2008 18:42:02 GMT
Jean-Adrien,

I wrote a patch that fixes what you saw, care to give it a look?
https://issues.apache.org/jira/browse/HBASE-808

If that works for you, we'll close the issue.

J-D

On Fri, Aug 8, 2008 at 11:15 PM, stack <stack@duboce.net> wrote:

> Jean-Adrien wrote:
>
>> ...
>> Despite the VERSIONS parameter of the columns (3) it seems that all
>> versions
>> are stored.
>>
>>
> Yeah.  I just confirmed that VERSIONS is not respected doing basic puts in
> shell.  I made HBASE-808 to cover its fixing.
>
>  Question: is there some garbage collector process that removes the old
>> versions ? if yes, when does it take place ?
>>
>>
>>
> Yes. At compaction time, versions beyond MAX_VERSIONS (and older than
> configured TTL) are removed.
>
> ...
>
>> It seems that the row are not inserted. Querying from shell:
>>
>>
>> # SHELL
>> hbase(main):004:0> scan 'proxy-0.2'
>> ROW                          COLUMN+CELL
>> 0 row(s) in 0.2030 seconds
>>
>>
>>
> Playing in the shell, I did not see this behavior; the new insert showed
> up.  Maybe its something to do w/ the number of inserts you've done.  Let me
> try and reproduce on my side (Made issue to cover the work: HBASE-809).
>
> ...
>
>> I tried other tests, replacing only one column, using an existing
>> timestamp
>> to modify one single value, inserting past values, and so on... My
>> conclusion is either I don't understand the general behaviour of that, or
>> I
>> make a bad usage of the API.
>>
>
> Your use of the API looks proper.  Looks like hbase bugs around
> timestamping.
>
>> Thanks for your work, and if someone has more information about timestamps
>> and designed behaviour, I'm very interested in it.
>>
>>
>
> Thank you for taking the time to write up the problem in so much helpful
> detail.
>
> St.Ack
>

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