phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4344) MapReduce Delete Support
Date Wed, 14 Feb 2018 07:55:00 GMT

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

James Taylor commented on PHOENIX-4344:
---------------------------------------

Phoenix will do a point delete (i.e. the Phoenix client will issue an HBase Delete with the
full row key) because it thinks it has values for all the columns that make up the primary
key of the base table. In this case, it doesn't need to issue a scan at all. The problem is,
Phoenix doesn't know that there are derived views that have extended the PK.

One solution would be to have a declaration on the base table that it would never be used
to upsert data directly. Something like declaring it ABSTRACT. In that case, if you deleted
from it, Phoenix could know to issue a scan instead of trying to optimize it as a point delete.

Another solution would be to issue the delete statement against the view in the MR job. Since
the view has extended the PK, Phoenix wouldn't issue a point delete, but would issue a scan.
That might not be feasible, though, as it'd be tricky to know all the views.

> MapReduce Delete Support
> ------------------------
>
>                 Key: PHOENIX-4344
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4344
>             Project: Phoenix
>          Issue Type: New Feature
>    Affects Versions: 4.12.0
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>            Priority: Major
>
> Phoenix already has the ability to use MapReduce for asynchronous handling of long-running
SELECTs. It would be really useful to have this capability for long-running DELETEs, particularly
of tables with indexes where using HBase's own MapReduce integration would be prohibitively
complicated. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message