[
https://issues.apache.org/jira/browse/KUDU-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745370#comment-17745370
]
ASF subversion and git services commented on KUDU-1945:
-------------------------------------------------------
Commit 6527f4a0fdccaddbee58cb66c2255f25eff29ddc in kudu's branch
refs/heads/branch-1.17.x from Abhishek Chennaka
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=6527f4a0f ]
KUDU-1945 Update default range partition key
The default range partition key includes all the columns of the
primary key. We should not include auto incrementing column as
this is not expected to be a part of the partition key by design.
Change-Id: I89818ceb261064369a63712f6c093f41e57ca5cc
Reviewed-on: http://gerrit.cloudera.org:8080/20219
Tested-by: Kudu Jenkins
Reviewed-by: Alexey Serbin <[email protected]>
(cherry picked from commit 4d0a654024981b78e36912aaf7838705e4ca0e78)
Reviewed-on: http://gerrit.cloudera.org:8080/20234
Reviewed-by: Yingchun Lai <[email protected]>
Tested-by: Yingchun Lai <[email protected]>
> 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)
