What Anoop said is in 0.94.0

For trunk, HBASE-4676 provides trie data block encoding.
It suits write-once read-many use case very well.

Cheers

On Thu, May 24, 2012 at 5:57 PM, Anoop Sam John <[email protected]> wrote:

> Hi Anil,
>           There is no way you can avoid the timestamp with KVs. In your
> case you can think of using data block encoding? You can see
> FastDiffDeltaEncoder and DiffKeyDeltaEncoder. This includes way of avoiding
> writing the 8 bytes into each KV for timestamp. Still some bytes will be
> written though and this will be done at the block level. Also pls note that
> these encoders will do much more things than the timestamp space
> optimization. Also you need to make sure to pass some timestamp in your
> Puts. May be better make as 0L. Else in RS side HBase will assign the cur
> time as the timestamp.  Hope when u read the javadoc for these encoder
> classes, u will be more clear.
>
> The one you are telling abt having a feature to fully avoid the timestamp
> is a topic to discuss
>
> Hope I make it clear to you
>
> -Anoop-
> ________________________________________
> From: anil gupta [[email protected]]
> Sent: Friday, May 25, 2012 3:21 AM
> To: [email protected]
> Subject: Disable timestamp in HBase Table a.k.a Disable Versioning in
> HBase Table
>
> Hi All,
>
> We are planning to store data in HBase. Currently, in one of our use case
> once a row is written into HBase Table we wont be modifying the data of
> that row. Since, for every cell(right?) in HBase a timestamp(long value) is
> stored; this would take up extra 8 bytes. I was thinking is there a way to
> disable timestamp on HBase table when versioning is not required. I went
> through the documentation and searched mailing list for same but could not
> find anything relevant. Since we are talking about billions of cells, this
> would add up to significant amount of space.(around 7.45 GigaBytes for 1
> billion cells). Does this sounds like a feature HBase is missing?
>
> Please share your thoughts.
>
> --
> Thanks & Regards,
> Anil Gupta
>

Reply via email to