[
https://issues.apache.org/jira/browse/PHOENIX-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Palash Chauhan updated PHOENIX-7795:
------------------------------------
Description:
Applications running on multi-tenant Phoenix tables often need different data
retention policies per tenant. For example, Tenant A may require 30-day
retention while Tenant B requires 90-day retention. Today, per-tenant TTL can
be achieved using Conditional TTL PHOENIX-7170 but it would require enumerating
all tenants and their TTL values in the TTL Expression and for a large number
of tenants, this expression would be very hard to maintain.
This JIRA instead aims to leverage existing View TTL implementation to enable
Tenant TTL. This approach would require creating global views on a multi tenant
table with where clause on the tenant_id column.
Read masking should work but CompactionScanner might need changes
1) to handle the Row Key Matcher created by such views
2) trie pruning to reduce the memory taken up by GLOBAL_VIEWS trie since all
global views are loaded upfront and one view per tenant could mean a large
number of global views
More details in
[document|https://docs.google.com/document/d/1A3TikNN_XwV6pQBqgpb6U0pj_LtBWf_1Q-Cdc_P0Bmo/edit?tab=t.0].
was:
Applications running on multi-tenant Phoenix tables often need different data
retention policies per tenant. For example, Tenant A may require 30-day
retention while Tenant B requires 90-day retention. Today, per-tenant TTL can
be achieved using Conditional TTL PHOENIX-7170 but it would require enumerating
all tenants and their TTL values in the TTL Expression and for a large number
of tenants, this expression would be very hard to maintain.
This JIRA instead aims to leverage existing View TTL implementation to enable
Tenant TTL. This approach would require creating global views on a multi tenant
table with where clause on the tenant_id column.
Read masking should work but CompactionScanner might need changes
1) to handle the Row Key Matcher created by such views
2) trie pruning to reduce the memory taken up by GLOBAL_VIEWS trie since all
global views are loaded upfront and one view per tenant could mean a large
number of global views
> Tenant TTL
> ----------
>
> Key: PHOENIX-7795
> URL: https://issues.apache.org/jira/browse/PHOENIX-7795
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Palash Chauhan
> Assignee: Palash Chauhan
> Priority: Major
> Fix For: 5.4.0, 5.3.1
>
>
> Applications running on multi-tenant Phoenix tables often need different data
> retention policies per tenant. For example, Tenant A may require 30-day
> retention while Tenant B requires 90-day retention. Today, per-tenant TTL can
> be achieved using Conditional TTL PHOENIX-7170 but it would require
> enumerating all tenants and their TTL values in the TTL Expression and for a
> large number of tenants, this expression would be very hard to maintain.
> This JIRA instead aims to leverage existing View TTL implementation to enable
> Tenant TTL. This approach would require creating global views on a multi
> tenant table with where clause on the tenant_id column.
> Read masking should work but CompactionScanner might need changes
> 1) to handle the Row Key Matcher created by such views
> 2) trie pruning to reduce the memory taken up by GLOBAL_VIEWS trie since all
> global views are loaded upfront and one view per tenant could mean a large
> number of global views
> More details in
> [document|https://docs.google.com/document/d/1A3TikNN_XwV6pQBqgpb6U0pj_LtBWf_1Q-Cdc_P0Bmo/edit?tab=t.0].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
