[
https://issues.apache.org/jira/browse/PHOENIX-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290920#comment-14290920
]
James Taylor commented on PHOENIX-1590:
---------------------------------------
Another option for determining when it's ok to remove the VIEW metadata row
would be to do it if/when another view with the same name is attempted to be
created. That way we could do it from the client. I think the downside may be
that each region on a major compaction would still think it needs to filter out
the deferred deleted data. Or maybe the per region compaction time would help
here?
> Add an Asynchronous/Deferred Delete Option
> ------------------------------------------
>
> Key: PHOENIX-1590
> URL: https://issues.apache.org/jira/browse/PHOENIX-1590
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Jan Fernando
>
> For use cases where we need to delete very large amounts of data from Phoenix
> tables running a synchronous delete can be problematic. In order to guarantee
> that the delete completes, handle failure scenarios, and ensure it doesn't
> put too much load on the HBase cluster and crowd out other queries running we
> need to build tooling around the longer running delete operations to chunk
> them up, provide retries in the event of failures, and have ways to throttle
> delete load if the Region Servers get hot.
> It would be really great if Phoenix offered a way to invoke a resilient
> delete that was processed asynchronously and had minimal load on the cluster.
> An idea mentioned to implement this is to introduce a DEFERRED keyword to the
> DELETE operation and for such a delete to remove the data at compaction time.
> For our use cases, ideally, we would like to set delete filters that are
> based on the first 2 elements of the row key (a multi-tenant id and the next
> item).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
