hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10247) Client promises about timestamps
Date Fri, 27 Dec 2013 19:57:50 GMT

    [ https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13857684#comment-13857684
] 

Lars Hofhansl commented on HBASE-10247:
---------------------------------------

Yep. Log replay is another issue where this will help. W.r.t. cheap upserts into the memstore,
would still need to be careful when to update in place, because or the SLAB storage (that
is why upsert is not using the SLAB, for example).

Maybe we could first agree upon how a user indicates these promises. Would it be per CF? Or
per table? Per table makes more sense (IMHO - why would a user want to supply timestamps for
some columns for not for others in the same row?), but per CF would fit better with how we
handling other config options.

Something like CLIENT_TIMESTAMPS, SERVER_TIMESTAMPS? These are easy to verify. Might also
want CLIENT_MONOTONIC_TIMESTAMPS (thinking of something like Phoenix here, which does its
own TS management, or transaction libraries that use the TS to implement SI), which would
be hard/expensive to validate, so we'd have to trust the client.


> Client promises about timestamps
> --------------------------------
>
>                 Key: HBASE-10247
>                 URL: https://issues.apache.org/jira/browse/HBASE-10247
>             Project: HBase
>          Issue Type: Brainstorming
>            Reporter: Lars Hofhansl
>            Priority: Minor
>
> This is to start a discussion about timestamp promises declared per table of CF.
> For example if a client promises only monotonically increasing timestamps (or no custom
set timestamps) and VERSIONS=1, we can aggressively and easily remove old versions of the
same row/fam/col from the memstore before we flush, just by supplying a comparator that ignores
the timestamp (i.e. two KV just differing by TS would be considered equal).
> That would increase the performance of counters significantly.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message