[
https://issues.apache.org/jira/browse/PHOENIX-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Fernando updated PHOENIX-1590:
----------------------------------
Description:
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).
was:
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 such a delete have been introducing a DEFERRED
keyword to the DELETE and for such a delete to remove the data at compaction
time.
For our use cases, ideally, we would like to work set delete filters that are
based on the first 2 elements of the row key (a multi-tenant id and the next
item).
> 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)
