Hi All, On the explain plan to show which part of the code is run where a graph is shown[1]. Default chart will be a Pie chart and I'm planing to use few more chat types so user can pick his choice. If any node responding slowly. Phoenix database administrator can exam the node and examin what are queries run on a particular time.
I have run few examples on secondary indexes[4] and I got sample data and it can be used for the milestone1(end of this week). It is shown with timesliding capabilities. Trace segments are shown in a timeline.[2] Does filters mean 'where' like logic statements? The database admin can track the duration for a particular trace from timeline visualization so he can use the filters effectively (best order of the filters) in a query to get a quick respond. I tried the join query and it didn't give any results or corresponding traces. This is the reference I followed [3]. Is there any more steps to follow? To visualize the tracing details I looked through few charting libraries and I will give the comparison details over them. Please feel free to give the feedback on the mock uis. Thanks. [1] https://issues.apache.org/jira/secure/attachment/12739498/m1-mockUI-tracedistribution.png [2] https://issues.apache.org/jira/secure/attachment/12739499/m1-mockUI-tracetimeline.png [3] https://phoenix.apache.org/joins.html [4] http://ayolajayamaha.blogspot.com/2015/06/tracing-data-secondary-indixes.html On Thu, Jun 11, 2015 at 11:39 AM, Ayola Jayamaha <raphaelan...@gmail.com> wrote: > 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/ > > > -- Best Regards, Nishani Jayamaha http://ayolajayamaha.blogspot.com/
