[
https://issues.apache.org/jira/browse/KUDU-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100333#comment-16100333
]
Jean-Daniel Cryans commented on KUDU-2076:
------------------------------------------
bq. So do you mean that the this bug exist only in the using of one column as a
primary key?
Yup, as you can see from the last paragraph in the jira's description, more
data in the key makes it go faster :)
A single string column should also perform ok I think.
bq. And how can we use a composite key if in real case we don't need it in
schema?
To be honest, having a single INT row key isn't a common Kudu use case so we
haven't paid it a lot of attention to it (as you can tell now). You can't even
have that many rows. Maybe it's a valid use case for side tables? But a small,
single row key table that undergoes a lot of updates or deletes isn't really
Kudu's forte.
Doesn't mean we shouldn't make this better though, just giving you context.
> Deleting/updating is slow on single numeric row key tables
> ----------------------------------------------------------
>
> Key: KUDU-2076
> URL: https://issues.apache.org/jira/browse/KUDU-2076
> Project: Kudu
> Issue Type: Bug
> Components: tablet
> Affects Versions: 1.4.0
> Reporter: Jean-Daniel Cryans
>
> A user reported that deleting 50M rows on the simplest of tables, (id INT,
> text STRING, PRIMARY KEY (id)), doesn't complete.
> It reproduces locally and I was able to see that we're deleting 1.4 rows / ms
> which is awful considering that everything is cached.
> Todd found that we're spending most of our time decoding big blocks of
> bit-shuffled keys. Intuitively he though that having a composite row key
> would perform better and indeed adding a column set to 0 in front makes it
> 10x faster.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
