[jira] [Assigned] (PHOENIX-6978) Redesign Phoenix TTL for Views
[ https://issues.apache.org/jira/browse/PHOENIX-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Isaac reassigned PHOENIX-6978: Assignee: Lokesh Khurana > Redesign Phoenix TTL for Views > -- > > Key: PHOENIX-6978 > URL: https://issues.apache.org/jira/browse/PHOENIX-6978 > Project: Phoenix > Issue Type: Improvement >Reporter: Jacob Isaac >Assignee: Lokesh Khurana >Priority: Major > > With Phoenix TTL for views (PHOENIX-3725), the basic gist was the TTL should > be a Phoenix view level setting instead of being at the table level as > implemented in HBase. More details on the old design are here ([Phoenix TTL > design > doc|https://docs.google.com/document/d/1aZWhJQCARBVt9VIXNgINCB8O0fk2GucxXeu7472SVL8/edit#heading=h.kpf13qig3vdl]). > Both HBase TTL and Phoenix TTL rely on applying expiration logic during the > scanning phase when serving query results and apply deletion logic when > pruning the rows from the store. In HBase, the pruning is achieved during the > compaction phase. > The initial design and implementation of Phoenix TTL for views used the MR > framework to run delete jobs to prune away the expired rows. We knew this was > a sub-optimal solution since it required managing and monitoring MR jobs. It > would also have introduced additional delete markers which would have > temporarily added more rows (delete markers) have made the scans less > performant. > Using the HBase compaction framework instead to prune away the expired rows > would fit nicely into the existing architecture and would be efficient like > pruning the HBase TTL rows. > This jira proposes a redesign of Phoenix TTL for Views using PHOENIX-6888 and > PHOENIX-4555 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (PHOENIX-6996) Provide an upgrade path for Phoenix tables with HBase TTL to move their TTL spec to SYSTEM.CATALOG
Jacob Isaac created PHOENIX-6996: Summary: Provide an upgrade path for Phoenix tables with HBase TTL to move their TTL spec to SYSTEM.CATALOG Key: PHOENIX-6996 URL: https://issues.apache.org/jira/browse/PHOENIX-6996 Project: Phoenix Issue Type: Sub-task Reporter: Jacob Isaac -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-6978) Redesign Phoenix TTL for Views
[ https://issues.apache.org/jira/browse/PHOENIX-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Isaac updated PHOENIX-6978: - Description: With Phoenix TTL for views (PHOENIX-3725), the basic gist was the TTL should be a Phoenix view level setting instead of being at the table level as implemented in HBase. More details on the old design are here ([Phoenix TTL design doc|https://docs.google.com/document/d/1aZWhJQCARBVt9VIXNgINCB8O0fk2GucxXeu7472SVL8/edit#heading=h.kpf13qig3vdl]). Both HBase TTL and Phoenix TTL rely on applying expiration logic during the scanning phase when serving query results and apply deletion logic when pruning the rows from the store. In HBase, the pruning is achieved during the compaction phase. The initial design and implementation of Phoenix TTL for views used the MR framework to run delete jobs to prune away the expired rows. We knew this was a sub-optimal solution since it required managing and monitoring MR jobs. It would also have introduced additional delete markers which would have temporarily added more rows (delete markers) have made the scans less performant. Using the HBase compaction framework instead to prune away the expired rows would fit nicely into the existing architecture and would be efficient like pruning the HBase TTL rows. This jira proposes a redesign of Phoenix TTL for Views using PHOENIX-6888 and PHOENIX-4555 was: With Phoenix TTL for views (PHOENIX-3725), the basic gist was the TTL should be a Phoenix view level setting instead of being at the table level as implemented in HBase. More details on the design are here ([Phoenix TTL design doc|https://docs.google.com/document/d/1aZWhJQCARBVt9VIXNgINCB8O0fk2GucxXeu7472SVL8/edit#heading=h.kpf13qig3vdl]). Both HBase TTL and Phoenix TTL rely on applying expiration logic during the scanning phase when serving query results and apply deletion logic when pruning the rows from the store. In HBase, the pruning is achieved during the compaction phase. The initial design and implementation of Phoenix TTL for views used the MR framework to run delete jobs to prune away the expired rows. We knew this was a sub-optimal solution since it required managing and monitoring MR jobs. It would also have introduced additional delete markers which would have temporarily added more rows (delete markers) have made the scans less performant. Using the HBase compaction framework instead to prune away the expired rows would fit nicely into the existing architecture and would be efficient like pruning the HBase TTL rows. This jira proposes a redesign of Phoenix TTL for Views using PHOENIX-6888 and PHOENIX-4555 > Redesign Phoenix TTL for Views > -- > > Key: PHOENIX-6978 > URL: https://issues.apache.org/jira/browse/PHOENIX-6978 > Project: Phoenix > Issue Type: Improvement >Reporter: Jacob Isaac >Priority: Major > > With Phoenix TTL for views (PHOENIX-3725), the basic gist was the TTL should > be a Phoenix view level setting instead of being at the table level as > implemented in HBase. More details on the old design are here ([Phoenix TTL > design > doc|https://docs.google.com/document/d/1aZWhJQCARBVt9VIXNgINCB8O0fk2GucxXeu7472SVL8/edit#heading=h.kpf13qig3vdl]). > Both HBase TTL and Phoenix TTL rely on applying expiration logic during the > scanning phase when serving query results and apply deletion logic when > pruning the rows from the store. In HBase, the pruning is achieved during the > compaction phase. > The initial design and implementation of Phoenix TTL for views used the MR > framework to run delete jobs to prune away the expired rows. We knew this was > a sub-optimal solution since it required managing and monitoring MR jobs. It > would also have introduced additional delete markers which would have > temporarily added more rows (delete markers) have made the scans less > performant. > Using the HBase compaction framework instead to prune away the expired rows > would fit nicely into the existing architecture and would be efficient like > pruning the HBase TTL rows. > This jira proposes a redesign of Phoenix TTL for Views using PHOENIX-6888 and > PHOENIX-4555 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OMID-245) Add dependency management for Guava to use 32.1.1
[ https://issues.apache.org/jira/browse/OMID-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richárd Antal resolved OMID-245. Fix Version/s: 1.1.1 Resolution: Fixed > Add dependency management for Guava to use 32.1.1 > - > > Key: OMID-245 > URL: https://issues.apache.org/jira/browse/OMID-245 > Project: Phoenix Omid > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Richárd Antal >Assignee: Richárd Antal >Priority: Major > Fix For: 1.1.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OMID-245) Add dependency management for Guava to use 32.1.1
[ https://issues.apache.org/jira/browse/OMID-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742695#comment-17742695 ] ASF GitHub Bot commented on OMID-245: - richardantal merged PR #137: URL: https://github.com/apache/phoenix-omid/pull/137 > Add dependency management for Guava to use 32.1.1 > - > > Key: OMID-245 > URL: https://issues.apache.org/jira/browse/OMID-245 > Project: Phoenix Omid > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Richárd Antal >Assignee: Richárd Antal >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OMID-245) Add dependency management for Guava to use 32.1.1
[ https://issues.apache.org/jira/browse/OMID-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742693#comment-17742693 ] ASF GitHub Bot commented on OMID-245: - richardantal commented on PR #137: URL: https://github.com/apache/phoenix-omid/pull/137#issuecomment-1633762127 Thank you Istvan for the review tests are OK apart from a known flaky one. > Add dependency management for Guava to use 32.1.1 > - > > Key: OMID-245 > URL: https://issues.apache.org/jira/browse/OMID-245 > Project: Phoenix Omid > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Richárd Antal >Assignee: Richárd Antal >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
