accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3236) Clone table into an existing table
Date Thu, 16 Oct 2014 12:01:33 GMT

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

Christopher Tubbs commented on ACCUMULO-3236:
---------------------------------------------

Right, we've identified two options to get what you want (union + delete + rename OR clone-ish/merge
thing described here) and two options to get what I'd want (union OR clone + clone-ish/merge
thing). For the irreversible merge you describe, it's one step your way, and a few primitive
steps in my suggestion. For the reversible merge I describe, it's one step my way, or a few
steps with what you describe. Both would be implemented using the optimized copy metadata
file references, like clone does (plus your suggestion to insert extra split points to avoid
chop).

I'm not arguing against any of the requirements you've described, or the proposed internal
implementation using the same clone mechanisms. The question I'm asking is: which makes the
most sense as the API primitives? Personally, I'd go with the well-defined semantics of union
and delete. I'm also pointing out that, from a user-facing perspective, this is not an improvement
over a clone function... it's a brand new feature, with very different behavior from the clone
operation.

> Clone table into an existing table
> ----------------------------------
>
>                 Key: ACCUMULO-3236
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3236
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client, tserver
>            Reporter: John Vines
>             Fix For: 1.7.0
>
>
> Currently we have the ability to clone a table, which takes all files belonging to an
existing table and then makes them owned by a second, brand new table. I think there is a
logic extension to this where you can add the files to an already existing table.
> One point of concern is if data is unused in existing files due to major compactions
of the shared files in the source table. This can be mitigated by either chopping the files
(which sorta goes against the idea of cloning) or ensuring that at source table splits exist
in the destination table.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message