[jira] [Comment Edited] (KUDU-2494) KuduScannerBuilder OR operator for predicates

["Ricardo Gaspar (JIRA)" <ji...@apache.org>]

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

Ricardo Gaspar edited comment on KUDU-2494 at 7/12/18 5:43 PM:
---------------------------------------------------------------

Thanks for the comment [~tlipcon]. ;)

You have all rights to have your opinion and disagree with mine. I just point out that as a database system Kudu should offer such methods, otherwise is just like HBase. If I want to use a key-value store I use HBase not Kudu.
 As I'm working with Kudu, for some operations I must relly on Impala, which is a bit "stupid", as for "basic" operations that I mentioned before the API could provide them. It knows more about the nodes and how the data is organized than the developer.

As programmer, my personal opinion is that Kudu should distinguish itself from a Key-Value store paradigm and offer RDBMS-like search/query methods (not all, but at least the sorting and join). 
 Otherwise the programmer has to  use a SQL engine like Impala or code the sorting and merging (that are already well implemented in other RDBMS or SQL engines) himself.

 

 


was (Author: rikg):
Thanks for the comment [~tlipcon]. ;)

You have all rights to have your opinion and disagree with mine. I just point out that as a database system Kudu should offer such methods, otherwise is just like HBase. If I want to use a key-value store I use HBase not Kudu.
As I'm working with Kudu, for some operations I must relly on Impala, which is a bit "stupid", as for "basic" operations that I mentioned before the API could provide them. It knows more about the nodes and how the data is organized than the developer.

As programmer, my personal opinion is that Kudu should distinguish itself from a Key-Value store paradigm and offer RDBMS-like search/query methods (not all, but at least the sorting and join). 
Otherwise the programmer has to  use a SQL engine like Impala or code the sorting and merging that are already well implemented in other RDBMS or SQL engines himself.

 

 

> KuduScannerBuilder OR operator for predicates
> ---------------------------------------------
>
>                 Key: KUDU-2494
>                 URL: https://issues.apache.org/jira/browse/KUDU-2494
>             Project: Kudu
>          Issue Type: Improvement
>          Components: api
>    Affects Versions: 1.7.1
>            Reporter: Ricardo Gaspar
>            Priority: Major
>
> KuduScannerBuild API only supports the build of a scan using predicates in a conjuctive operation.
>  Meaning that when using more than one predicate (p1,p2), the scan will be done using a statement similar to:
> {code:java}
> WHERE p1 AND p2;{code}
>  
> In Java code:
>   
> {code:java}
> kc = new KuduClient.KuduClientBuilder(kuduMasters).build();
> session = kc.newSession();
> KuduScanner ks = kc.newScannerBuilder(table).addPredicate(p1).addPredicate(p2).build();
> {code}
>   
> *There is no possibility to specify a OR operation that applies an disjunction between all/some predicates*. E.g.
> {code:java}
> WHERE p1 OR p2;{code}
>  
>  
> The only way to do this using the current API (1.7.1) is to use two (or more) scanners and iterate them separately:
>  
> {code:java}
> KuduScanner scanner1 = kc.newScannerBuilder(table).addPredicate(p1).build();
> KuduScanner scanner2 = kc.newScannerBuilder(table).addPredicate(p2).build();
> while (scanner1.hasMoreRows()) {
>     RowResultIterator results = scanner1.nextRows();
>     while (results.hasNext()) {
>         RowResult rowData = results.next();
>         
>         //Do stuff with rowData
>     }
> }
> while (scanner2.hasMoreRows()) {
>     RowResultIterator results = scanner2.nextRows();
>     while (results.hasNext()) {
>         RowResult rowData = results.next();
>         //Do stuff with rowData
>     }
> }
> {code}
>  
> Kudu API should provide "almost" the same query processing power as IMPALA or an SQL engine.
> Programmers should rely on Kudu API to operations like these and others like: sorting, table joins, etc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)