cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Alves (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-1123) Allow tracing query details
Date Sat, 21 Jul 2012 10:50:35 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419741#comment-13419741
] 

David Alves edited comment on CASSANDRA-1123 at 7/21/12 10:49 AM:
------------------------------------------------------------------

i get the point, the original paper mentioned that that was the case because the data was
stored outside of the cluster. 

Still there is the question of authentication, even though access control is not very thorough
AFAIK, the principle behind it is per keyspace access correct? this would mean that we're
storing data belonging to a keyspace (that might have access control) in another keyspace
(that must be outside accessible).

I'm happy to do it either way, but maybe we could instead store the number and length of the
arguments. additionally this would decrease tracing network bandwidth usage.



                
      was (Author: dr-alves):
    i get the point, the original paper mentioned that that was the case because the data
was stored outside of the cluster. 

Still there is the question of authentication, even though access control is not completely
implemented, the principle behind it is per keyspace access correct? this would meant that
we're storing data belonging to a keyspace (that might have access control) in another keyspace
(that must be outside accessible). am I wrong?



                  
> Allow tracing query details
> ---------------------------
>
>                 Key: CASSANDRA-1123
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1123
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: David Alves
>             Fix For: 1.2
>
>         Attachments: 1123-3.patch.gz, 1123.patch
>
>
> In the spirit of CASSANDRA-511, it would be useful to tracing on queries to see where
latency is coming from: how long did row cache lookup take?  key search in the index?  merging
the data from the sstables?  etc.
> The main difference vs setting debug logging is that debug logging is too big of a hammer;
by turning on the flood of logging for everyone, you actually distort the information you're
looking for.  This would be something you could set per-query (or more likely per connection).
> We don't need to be as sophisticated as the techniques discussed in the following papers
but they are interesting reading:
> http://research.google.com/pubs/pub36356.html
> http://www.usenix.org/events/osdi04/tech/full_papers/barham/barham_html/
> http://www.usenix.org/event/nsdi07/tech/fonseca.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message