[
https://issues.apache.org/jira/browse/KUDU-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384166#comment-16384166
]
Todd Lipcon commented on KUDU-1945:
-----------------------------------
[~granthenke] I noticed you assigned this to yourself. Would be good to publish
some sort of short design doc or blurb on your intended approach if you're
working on it. I had a few thoughts as well.
> 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
> Assignee: Grant Henke
> Priority: Major
>
> 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
(v7.6.3#76005)
