accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-803) Add Reverse Logical Time as a Time Type
Date Tue, 16 Oct 2012 14:23:03 GMT

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

Keith Turner commented on ACCUMULO-803:
---------------------------------------

bq.  does that imply that we might want a different timestamp scheme on different column families?

Currently each tablets timestamp is stored in the metadata table.  It tablets had to persist
and indeterminate number of timestamps, then I do not think we could safely store that in
the metadata table.   Would need to store it somewhere else.  Its nice storing the info in
the metadata table because you can atomically update the timestamp on minor compaction and
bulkimport by putting it in the same mutation.  So where would this info be stored and how
would it be atomically updated after minor compaction and bulk import?

Would also have to be careful not to blow out memory on tservers.  e.g. If each tablet on
a tserver is keeping track of timestamps for many columns in memory.  Would need to cache
timestamp info from persisted store to avoid this problem.
                
> Add Reverse Logical Time as a Time Type
> ---------------------------------------
>
>                 Key: ACCUMULO-803
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-803
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>    Affects Versions: 1.4.2
>            Reporter: Drew Farris
>            Assignee: Drew Farris
>            Priority: Minor
>         Attachments: ACCUMULO-803.patch
>
>
> In a context where we are doing aggregation/combination of multiple values for a given
key it may be useful to iterate over the values associated with that key in the order in which
the mutations were applied (FIFO), instead of the FILO order that seems to occur when using
{{TimeType.LOGICAL}}. 
> I encountered when implemeting a checkAndPut operation that would ensure that the previous
value was expected before putting a new value. In this case, if the previous value was not
as expected, the mutation would be ignored. 
> Perhaps it is useful in a general case?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message