[
https://issues.apache.org/jira/browse/KUDU-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15285080#comment-15285080
]
Todd Lipcon commented on KUDU-1440:
-----------------------------------
Well, I think we need separate APIs - one is about fault tolerance, the other
is about ordering, and while we happen to use the same backend implementation
for both right now, there are actually some optimizations that could apply to
one without applying to the other, so I dont think we should conflate the two
in the API.
> Wrong result ordering for scanning a table with millions of rows
> ----------------------------------------------------------------
>
> Key: KUDU-1440
> URL: https://issues.apache.org/jira/browse/KUDU-1440
> Project: Kudu
> Issue Type: Bug
> Components: client, master, tablet
> Affects Versions: 0.8.0
> Environment: CentOS 7
> Reporter: Martin Weindel
> Priority: Critical
> Attachments: CreateTableTimeSeriesBug.java
>
>
> I have following simple table with two columns:
> {code}
> time TIMESTAMP,
> value FLOAT
> {code}
> The time column is used as range partition key.
> If I have understand the architecture of Kudu correctly, the rows should then
> be returned in ascending order for the time column.
> This works as long as not more than about 600000 rows are inserted.
> If the number of inserted rows is above 1 mio, the order is messed up
> globally. On a microlevel it is still correct 99.9% if you look on successive
> rows.
> My setup is single master / single tablet server on a linux server. The table
> is created, filled and read with the Kudu Java client version 0.8.0.
> See attached Java code to reproduce the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
