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

ASF subversion and git services commented on KUDU-1945:
-------------------------------------------------------

Commit 14fd43ef9611e940e0fa59328183b3cf09506ca8 in kudu's branch 
refs/heads/branch-1.17.x from Abhishek Chennaka
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=14fd43ef9 ]

[client] KUDU-1945 Add UPSERT support

This patch adds UPSERT support to Kudu C++ and Java clients by removing
the previously added checks to discard UPSERT operations. The functionality
added is only supported if the entire primary key is provided including
the auto-incrementing column.

Also added verification to reject INSERT operations with
auto-incrementing column set on the client side.

Thanks to Marton Greber for diagnosing the python client side issue.

Change-Id: I27a95e3a6b1d1b584cad849978313b3c8222cd3d
Reviewed-on: http://gerrit.cloudera.org:8080/20083
Tested-by: Kudu Jenkins
Reviewed-by: Marton Greber <greber...@gmail.com>
Reviewed-by: Alexey Serbin <ale...@apache.org>
(cherry picked from commit 39302dfa8edc1fd1268f78f3ddd3f34ca26cc43f)
Reviewed-on: http://gerrit.cloudera.org:8080/20228
Reviewed-by: Yifan Zhang <chinazhangyi...@163.com>
Tested-by: Yingchun Lai <laiyingc...@apache.org>


> Support generation of surrogate primary keys (or tables with no PK)
> -------------------------------------------------------------------
>
>                 Key: KUDU-1945
>                 URL: https://issues.apache.org/jira/browse/KUDU-1945
>             Project: Kudu
>          Issue Type: New Feature
>          Components: client, master, tablet
>            Reporter: Todd Lipcon
>            Priority: Major
>              Labels: roadmap-candidate
>
> Many use cases have data where there is no "natural" primary key. For 
> example, a web log use case mostly cares about partitioning and not about 
> precise sorting by timestamp, and timestamps themselves are not necessarily 
> unique. Rather than forcing users to come up with their own surrogate primary 
> keys, Kudu should support some kind of "auto_increment" equivalent which 
> generates primary keys on insertion. Alternatively, Kudu could support tables 
> which are partitioned but not internally sorted.
> The advantages would be:
> - Kudu can pick primary keys on insertion to guarantee that there is no 
> compaction required on the table (eg always assign a new key higher than any 
> existing key in the local tablet). This can improve write throughput 
> substantially, especially compared to naive PK generation schemes that a user 
> might pick such as UUID, which would generate a uniform random-insert 
> workload (worst case for performance)
> - Make Kudu easier to use for such use cases (no extra client code necessary)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to