[jira] [Commented] (ACCUMULO-1495) Host multiple read-only versions of tablets for query performance
[ https://issues.apache.org/jira/browse/ACCUMULO-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15484933#comment-15484933 ] Josh Elser commented on ACCUMULO-1495: -- Ok, just wanted to make sure we kept relevant discussions on the appropriate issue. Thanks for making 4452. Definitely acknowledge that they can be related to one another at a broad level. > Host multiple read-only versions of tablets for query performance > - > > Key: ACCUMULO-1495 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1495 > Project: Accumulo > Issue Type: New Feature >Reporter: Christopher Tubbs > > It might be worth providing read-only views of tablets on multiple servers, > while writes go to a single authoritative server. This could improve query > performance in some cases. > Some things to consider: > # Consistency: can I read what I've just written? > # Configuration: how many copies? > # Configuration: how long between syncs? > # Performance: locality, number of file replicas > Variation: > Permit multiple hosting only on tables that have been locked for writes > (useful with a strictly enforced clone-and-lock feature). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-1495) Host multiple read-only versions of tablets for query performance
[ https://issues.apache.org/jira/browse/ACCUMULO-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478205#comment-15478205 ] Christopher Tubbs commented on ACCUMULO-1495: - Yes, it's a completely separate solution for the same basic problem of query performance. It's probably worth mentioning such alternatives here, because I think other solutions should be considered first before multiple-hosting. Multiple-hosting is so complex and error-prone, I'd hate to consider it as a primary option. Although I think it's probably worth mentioning them here, if other ideas can be fleshed out to the point where they are sufficiently articulable as a proposal (or area of investigation), then yes, they deserve their own JIRA. (I've created ACCUMULO-4452 for this one.) > Host multiple read-only versions of tablets for query performance > - > > Key: ACCUMULO-1495 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1495 > Project: Accumulo > Issue Type: New Feature >Reporter: Christopher Tubbs > > It might be worth providing read-only views of tablets on multiple servers, > while writes go to a single authoritative server. This could improve query > performance in some cases. > Some things to consider: > # Consistency: can I read what I've just written? > # Configuration: how many copies? > # Configuration: how long between syncs? > # Performance: locality, number of file replicas > Variation: > Permit multiple hosting only on tables that have been locked for writes > (useful with a strictly enforced clone-and-lock feature). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-1495) Host multiple read-only versions of tablets for query performance
[ https://issues.apache.org/jira/browse/ACCUMULO-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478177#comment-15478177 ] Josh Elser commented on ACCUMULO-1495: -- Isn't that a completely separate way to just make the tabletserver "do less"? (sounds like its own JIRA issue if it's something you want to pursue..) > Host multiple read-only versions of tablets for query performance > - > > Key: ACCUMULO-1495 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1495 > Project: Accumulo > Issue Type: New Feature >Reporter: Christopher Tubbs > > It might be worth providing read-only views of tablets on multiple servers, > while writes go to a single authoritative server. This could improve query > performance in some cases. > Some things to consider: > # Consistency: can I read what I've just written? > # Configuration: how many copies? > # Configuration: how long between syncs? > # Performance: locality, number of file replicas > Variation: > Permit multiple hosting only on tables that have been locked for writes > (useful with a strictly enforced clone-and-lock feature). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-1495) Host multiple read-only versions of tablets for query performance
[ https://issues.apache.org/jira/browse/ACCUMULO-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478167#comment-15478167 ] Christopher Tubbs commented on ACCUMULO-1495: - It would probably be less complex of a change than multiple hosting. > Host multiple read-only versions of tablets for query performance > - > > Key: ACCUMULO-1495 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1495 > Project: Accumulo > Issue Type: New Feature >Reporter: Christopher Tubbs > > It might be worth providing read-only views of tablets on multiple servers, > while writes go to a single authoritative server. This could improve query > performance in some cases. > Some things to consider: > # Consistency: can I read what I've just written? > # Configuration: how many copies? > # Configuration: how long between syncs? > # Performance: locality, number of file replicas > Variation: > Permit multiple hosting only on tables that have been locked for writes > (useful with a strictly enforced clone-and-lock feature). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-1495) Host multiple read-only versions of tablets for query performance
[ https://issues.apache.org/jira/browse/ACCUMULO-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15478120#comment-15478120 ] Dave Marion commented on ACCUMULO-1495: --- Hey [~ctubbsii] : What about moving the major compactor process outside of the tablet server as an initial step? > Host multiple read-only versions of tablets for query performance > - > > Key: ACCUMULO-1495 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1495 > Project: Accumulo > Issue Type: New Feature >Reporter: Christopher Tubbs > > It might be worth providing read-only views of tablets on multiple servers, > while writes go to a single authoritative server. This could improve query > performance in some cases. > Some things to consider: > # Consistency: can I read what I've just written? > # Configuration: how many copies? > # Configuration: how long between syncs? > # Performance: locality, number of file replicas > Variation: > Permit multiple hosting only on tables that have been locked for writes > (useful with a strictly enforced clone-and-lock feature). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-1495) Host multiple read-only versions of tablets for query performance
[ https://issues.apache.org/jira/browse/ACCUMULO-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026622#comment-14026622 ] Josh Elser commented on ACCUMULO-1495: -- I think over query performance, this would be more noticeable in improving MTTR. If we have multiple tservers that are hosting a tablet for reads, you still have ways to get that data that don't involve waiting for recovery to complete. HBase has been doing a lot of work in this department as of late to be able to provide better SLAs. https://issues.apache.org/jira/browse/HBASE-10070 http://www.slideshare.net/enissoz/hbase-high-availability-for-reads-with-time Host multiple read-only versions of tablets for query performance - Key: ACCUMULO-1495 URL: https://issues.apache.org/jira/browse/ACCUMULO-1495 Project: Accumulo Issue Type: New Feature Reporter: Christopher Tubbs It might be worth providing read-only views of tablets on multiple servers, while writes go to a single authoritative server. This could improve query performance in some cases. Some things to consider: # Consistency: can I read what I've just written? # Configuration: how many copies? # Configuration: how long between syncs? # Performance: locality, number of file replicas Variation: Permit multiple hosting only on tables that have been locked for writes (useful with a strictly enforced clone-and-lock feature). -- This message was sent by Atlassian JIRA (v6.2#6252)
