[ 
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

Reply via email to