[ https://issues.apache.org/jira/browse/PHOENIX-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822545#comment-15822545 ]
Josh Elser commented on PHOENIX-3218: ------------------------------------- (will leave a few comments as I work my way through. don't want JIRA to eat my comments while editing) {code} # Phoenix Tuning Guide {code} "Apache Phoenix" for the first reference in the doc, please. {code} *This guide was written by [Peter Conrad](https://github.com/pconrad-fb) in September 2016 to help Phoenix users understand how to tune performance.* {code} This feels a little self-serving to me. Curious what others think. {code} When designing a schema, determine the likely access patterns for the data. {code} This doesn't flow with the rest of the paragraph. Maybe "it is important to determine the..."? {code} Major latency contributors: {code} "In addition to schema design, some major.." {code} Major latency contributors: * Excessive work needed per query * Request queuing * JVM garbage collection * Network Server outages * OS pagecache / VMM / IO {code} At second glance, these almost seem a bit abstract. "Excessive work" isn't really something I can look for to understand. Nor is "Network Server outages". Maybe convert this list into a statement that general system tuning is not covered by this document? The focus you have on Phoenix (with a little bit of HBase) tweaking is very nice without getting into the weeds on how Linux works. I think this list doesn't do the rest of your document justice as an introduction. {code} to get it right at design time because you can't patch it later {code} How about.. "because you cannot change it later without re-writing the data and index tables." {code} The primary keys should be chosen and concatenated in an order that makes it fast {code} "The columns for the primary key constraint should be chosen and ordered in such a way that aligns with the common query patterns." {code} To sum up, design primary keys {code} How about... "It is a best practice to design primary keys..." {code} When choosing primary keys, lead with the PK column you {code} Strike "PK". You're adding columns to the primary key constraint. I think "PK column" encourages bad "verbage" which makes it harder for everyone to communicate. > First draft of Phoenix Tuning Guide > ----------------------------------- > > Key: PHOENIX-3218 > URL: https://issues.apache.org/jira/browse/PHOENIX-3218 > Project: Phoenix > Issue Type: Improvement > Reporter: Peter Conrad > Attachments: Phoenix-Tuning-Guide-20170110.md, > Phoenix-Tuning-Guide.md, Phoenix-Tuning-Guide.md > > > Here's a first draft of a Tuning Guide for Phoenix performance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)