Yes. It was a bit confusing :-). But it was useful to get a good idea on the use cases. Thanks.
On Wed, Jun 10, 2015 at 11:57 PM, James Taylor <jamestay...@apache.org> wrote: > Excellent, Nishani (and you forgot to say "rambling" :-), but I'm glad > it helped). > > On Wed, Jun 10, 2015 at 11:16 AM, Ayola Jayamaha <raphaelan...@gmail.com> > wrote: > > Hi James, > > > > Thanks a lot for the lengthy and descriptive reply. I am currently > looking > > through UI components and charting libraries that can be used for the > UI. I > > refered [1] with regard to your explaination and came up with some mock > ups > > which I will share soon. > > > > Thanks, > > Nishani > > > > [1] https://phoenix.apache.org/language/#index_hint > > [2] > > > https://phoenix.apache.org/faq.html#How_do_I_create_Secondary_Index_on_a_table > > > > On Tue, Jun 9, 2015 at 11:39 PM, James Taylor <jamestay...@apache.org> > > wrote: > > > >> Hi Nishani, > >> I'd recommend focusing on higher level use cases. From the user's > >> point of view, they're executing a query and for some reason it's > >> slower than they expect. How do they figure out why? > >> > >> They might first do an EXPLAIN on their query to see how Phoenix is > >> executing it. Which parts are run where? Are secondary indexes being > >> used as expected? Are filters being pushed down as expected? A better > >> way to visualize the explain plan might be a good thing for you to > >> start with. > >> > >> Second, assuming the explain plan looks good, they'll want to turn on > >> tracing so that they can get runtime information on which parts of > >> their query are taking the longest. > >> > >> Maybe more than one Phoenix table is involved - how will you display > >> the tracing information across multiple tables for a query that does a > >> join? Maybe you can punt on this first pass, and focus on single table > >> queries. A related use case would be a DML statement that's executed > >> and taking longer than expected. Let's say that the table being > >> updated has one or more secondary indexes that are also updating the > >> index tables. Seeing the entire picture of both the table writes plus > >> the index writes on the same graph would be great. > >> > >> For the single-table query user case, what does the distribution of > >> time look like across all the region servers participating in the > >> query? Maybe some kind of graph that shows quickly if one region > >> server is taking much more time than the others. Perhaps that's an > >> indication that the table statistics need to be re-run, as there may > >> be skew that's developed such that one of the threads is handling more > >> data than it should. Or perhaps there's an issue with that particular > >> region server. Was there something else going on at the same time on > >> that region server, like a background compaction/split process? If > >> that information is available in the trace table (not sure), it would > >> be very cool to be able to superimpose that on top of the query trace > >> graph. > >> > >> Another test might be to run a query over a different table and see if > >> the same region server shows up again as being slow. So superimposing > >> the query trace graphs of multiple queries might give the user some > >> insight. > >> > >> IMHO, this is the kind of angle you should come at this from. > >> > >> Thanks, > >> James > >> > >> On Mon, Jun 8, 2015 at 4:12 AM, Ayola Jayamaha <raphaelan...@gmail.com> > >> wrote: > >> > Hi All, > >> > > >> > Basically what type of use cases are you expecting or performing at > the > >> > moment with regard to tracing? For example these are the use cases I'm > >> > planing. > >> > 1. Searching by parent id / trace id / description (regx search) > >> > 2. Grouping and ordering the tracing information by time period. > >> > 3. Counting the trace count per day / hour. > >> > 4. Comparing and distinguishing two sets of tracing. > >> > Thanks. > >> > > >> > > >> > On Mon, Jun 8, 2015 at 4:00 PM, Nishani (JIRA) <j...@apache.org> > wrote: > >> > > >> >> > >> >> [ > >> >> > >> > https://issues.apache.org/jira/browse/PHOENIX-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > >> >> ] > >> >> > >> >> Nishani updated PHOENIX-1118: > >> >> ------------------------------ > >> >> Attachment: Screenshot of dependency tree.png > >> >> > >> >> Attaching the dependency tree on tracing. > >> >> Pull request can be found here. > >> >> https://github.com/AyolaJayamaha/TracingWebApp/pull/1 > >> >> > >> >> > Provide a tool for visualizing Phoenix tracing information > >> >> > ---------------------------------------------------------- > >> >> > > >> >> > Key: PHOENIX-1118 > >> >> > URL: > >> https://issues.apache.org/jira/browse/PHOENIX-1118 > >> >> > Project: Phoenix > >> >> > Issue Type: Sub-task > >> >> > Reporter: James Taylor > >> >> > Assignee: Nishani > >> >> > Labels: Java, SQL, Visualization, gsoc2015, mentor > >> >> > Attachments: MockUp1-TimeSlider.png, > >> MockUp2-AdvanceSearch.png, > >> >> MockUp3-PatternDetector.png, MockUp4-FlameGraph.png, Screenshot of > >> >> dependency tree.png, screenshot of tracing web app.png > >> >> > > >> >> > > >> >> > Currently there's no means of visualizing the trace information > >> provided > >> >> by Phoenix. We should provide some simple charting over our metrics > >> tables. > >> >> Take a look at the following JIRA for sample queries: > >> >> > >> > https://issues.apache.org/jira/browse/PHOENIX-1115?focusedCommentId=14323151&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14323151 > >> >> > >> >> > >> >> > >> >> -- > >> >> This message was sent by Atlassian JIRA > >> >> (v6.3.4#6332) > >> >> > >> > > >> > > >> > > >> > -- > >> > Best Regards, > >> > Nishani Jayamaha > >> > http://ayolajayamaha.blogspot.com/ > >> > > > > > > > > -- > > Best Regards, > > Nishani Jayamaha > > http://ayolajayamaha.blogspot.com/ > -- Best Regards, Nishani Jayamaha http://ayolajayamaha.blogspot.com/
