[
https://issues.apache.org/jira/browse/PHOENIX-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982237#comment-15982237
]
James Taylor commented on PHOENIX-3173:
---------------------------------------
The valid point was raised on PHOENIX-2431, that we may not want to have a hard
dependency on transactions for Phoenix since it raises the operational
complexity. An alternate approach, PHOENIX-3534, is a kind of lazy cleanup when
operations that span regions fail. Part of that JIRA is to do cleanup on major
compaction, as well as at read time. By having a separate table for views,
you'd lose the efficiency of the reads across views + base table being local
most of the time. These reads happen on the server side when view meta data is
retrieved (query compilation and meta data APIs) and when compaction is
performed.
One primary driver for this JIRA is to be able to turn off replication for
SYSTEM.CATALOG while turning it on for this new SYSTEM.VIEW table. Another
solution for the replication issue is PHOENIX-3639 which is easy in HBase 1.4
(or even HBase 1.3 if the required HBase patch could be back ported).
Another factor is that this would require union queries to retrieve metadata
across views and tables during meta data API calls. We'd also need to query
both tables when a view or table is created as it's not legal to have a view
with the same name as a table when the tenant ID is the same.
Net-net, I don't see a big enough advantage to implement this fairly large task
given the limited benefit we'd see.
> Store views in a separate hbase table from physical tables
> ----------------------------------------------------------
>
> Key: PHOENIX-3173
> URL: https://issues.apache.org/jira/browse/PHOENIX-3173
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
>
> To more easily support disaster recovery, we should store views in a separate
> hbase table from physical tables. We currently store them together in
> SYSTEM.CATALOG so that they can be updated in an all or none behavior.
> However, with transaction support, we can make these system tables
> transactional no longer requiring them to be stored together.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
