[jira] [Commented] (PHOENIX-3218) First draft of Phoenix Tuning Guide

["Josh Elser (JIRA)" <ji...@apache.org>]

    [ 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)