You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Venkata Harikrishna Nukala (Jira)" <ji...@apache.org> on 2020/03/16 14:11:00 UTC

[jira] [Commented] (CASSANDRA-15644) Schema/Query analyzer

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

Venkata Harikrishna Nukala commented on CASSANDRA-15644:
--------------------------------------------------------

As it is a new feature, I am not expecting it to be picked up for 4.0 release.

> Schema/Query analyzer
> ---------------------
>
>                 Key: CASSANDRA-15644
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15644
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Venkata Harikrishna Nukala
>            Assignee: Venkata Harikrishna Nukala
>            Priority: Normal
>
> This proposal is to build schema/cql analyser which can help users to analyze their queries before it is too late.
>  
> User may create stability issues by
> - Running expensive queries against cluster like , SELECT * or query without where clause or IN clause with many values etc.
> - Creating not so optimal schemas
> - Leaving scope for data loss (keyspace with durable writes set to false or table with many secondary indexes etc...).
>  
> Most of the times these Dos & Don'ts go into some knowledge base/documentation as best practices. Having rules for best practices (which user can execute against statements) can help to avoid bad schema/queries getting executed in cluster. The main idea is to enable the users to take corrective actions, by
> 1) Allowing a user to validate a DDL/DML statements before it is applied/executed.
> 2) Allowing a user to validate existing schema/queries.
>  
> Imo, a validation result should:
> 1. Have severity
> 2. Tell where it hurts like instance/replica set/cluster.
> 3. Tell if it causes data loss.
> 4. Tell the strategy to recover.
>  
> Few approaches I can think of:
> 1. Write validation rules at server side + have a new type of statement to run validations (something like MySQL's EXPLAIN) and return validation results/errors.
> 2. Keep validation rules in sidecar + expose a service to run validations. In this case user can submit his statements to this API and get validation results.
> 3. Expose a UI in sidecar which accepts statements and run validations. Validation rules can be with UI or UI can make either of above options.
>  
> Open for any other approach.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org