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 Fri, 26 Oct 2012 18:55:11 GMT

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

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

Thinking about setting the order in the mutation, I realized it gives users rope to hang themselves
with.  A user could write two sets of code.  One program sets the order of column foo to FIFO
while another program sets it to LIFO.  The user did not intend to do this, but after running
both the data is in the system and they have to deal with it.  Below shows a table of what
been proposed so far and what I see as the pros and cons.

|Timestamp ordering method|Pros|Cons| 
|Set order at table level| simple and works w/ bulk import | may force user to store data
they want commingled in separate tables |
|Set order per column in table config | Ordering for a column is always consistent.  Can provide
granularity w/ bulk import. | Complex to set order in complex ways (i.e. plugin). Introduces
some server side computation overhead |
|Set order per column in mutation | Easy to set order in complex ways | Can easily write code
that inconsistently sets per column order. Do not have same granularity w/ bulk import, user
can specify if an entire file is FIFO or LIFO |

The table above assumes the order decision method in the table config is immutable.  If the
config were mutable it would suffer from the same problem as setting the order in the mutation.
 The issue of complexity with per table order config can be avoided if a really simple config
is used.  For example no plugins, at table creation time the user just specifies which column
families are FIFO.  This does not give the user the same flexibility as a plugin or setting
it on the mutation, but its better than setting FIFO for a whole table.

So I am now thinking a simple, immutable config at table creation time may be best.  Could
add the following to table operations. 

{code:java}
  public void create(String tableName, boolean versioningIter, TimeType timeType, Set<Text>
fifoColumnFamilies);
{code}

                
> 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.5.0
>            Reporter: Drew Farris
>            Assignee: Drew Farris
>            Priority: Minor
>         Attachments: ACCUMULO-803.patch, 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